MIME Decode å� æ¸�å¤�é�¨ã�¸ã�®å®�å�¨ã�ªã��ã�¼ã�¿ã�®å�ºã��æ�¹å¦ç¿�
エンコードマニアックス
MIME Decode å� æ¸�å¤�é�¨ã�¸ã�®å®�å�¨ã�ªã��ã�¼ã�¿ã�®å�ºã��æ�¹å¦ç¿�
変な文字化け - にせねこメモ
奇妙な文字化けがあった(ことを思い出した)のでメモしておく。 きっかけはこのツイート。twitpicの画像をご覧いただきたい。 何なのこいつ何を入れさせるつもりなの http://t.co/dYFVynv— シェゴ (@syego) September 3, 2011 twitter.com 「悰しい悰惴が倩瀨僯能です」は「新しい更新が利用可能です」が化けた物ではないか。下表にUnicodeスカラ値を示す。 悰 し い 惴 悰 が 60B0 3057 3044 60F4 60B0 304C 新 し い 更 新 が 65B0 3057 3044 66F4 65B0 304C 倩 瀨 僯 能 で す 5029 7028 50EF 80FD 3067 3059 利 用 可 能 で す 5229 7528 53EF 80FD 3067 3059 Unicodeスカラ値を見ると、0x100の位が0に
メールの文字化け | numaの日記 | スラド
21世紀にもなって、メールの文字化けなんてものに悩まされるとは思わなかったよ。いい加減にしてくれ、AppleでiPhone Mailを作っているお馬鹿さん お利口さん。こっちは文字化けメールをもらって、状況の把握に手間がかかってしようがない。まったく。 問題：iPhone/iPadから送信された日本語メールが、受信側では文字化けする。送信者が自分で書き込んだ部分は読み取れ、別メッセージから引用された部分が文字化けすることもある。何をどうすれば、そんなことができるのか。わけがわからないよ。症状：メール本文の化け方を見る限り、シフトJISで送ってきている。しかし、ヘッダーを見るとContent-Type: text/plain; charset=cp932になっている。 cp932なるcharset名はIANAに登録されていない非標準のものである（登録されているのはShift_JISおよびWi
【DTPの勉強会 第3回】資料無償公開のお知らせ - DTPの勉強会（東京）
東京で開催している『DTPの勉強会（東京）』の告知用ブログです。開催告知やお知らせは本ブログを通じて案内いたします。 2011年2月19日に開催したDTPの勉強会 第3回の資料を無償公開しました。 普段何気なく使っている「文字コード」と「フォント」。 これらを日常業務できちんと使用できるよう、基本的な知識から内部情報までを「文字コード」「フォント」「アプリケーション」の3つのパートに分けて 「がっつり」解説していただき、全てのセッションが非常に濃く分かりやすい内容でした。 無償公開をご許可いただいたスピーカーの皆さま、本当にありがとうございます！ ■内容・オープニングセッション 「書体の研究・出張版～普通の人から見た書体の面白さ」 ［スピーカー］ 山王丸榊さん（ゆず屋・TwitterID：yuzuya_shotaken） ［内容］ 「書体の研究」を執筆されている山王丸榊さんが文字のどこに「
InDesignの異体字属性伝染と文字化け（深刻なバグ） – ものかの
InDesign の深刻なバグ。 CS4 まで正常に表示されていた文字が、CS5 以降で開くと別の文字に化けてしまうことがあります。 かならず化けるわけではありません。化けるのは、ある特定の条件が重なったときです。その条件のひとつが「異体字属性の伝染」です。 異体字属性の伝染 異体字属性には「等幅半角字形 hwid」「旧字体 trad」「欧文イタリック ital」など様々なものがあります。 （ここでいう異体字は記号も含みます） CS2〜4 では、異体字属性が付いた文字の前後に、書式スタイルがない文字をペーストすると(1、ペーストした文字にも同じ異体字属性が付きます。これを私たちは「異体字属性の伝染」と呼んでいます。CS5 以降ではまったく伝染しなくなりました。 異体字属性が伝染すると、ペーストした瞬間に字形が変わります。意図しないところで勝手に字形が変わるので、CS2〜4 では問題視されま
旧AiファイルをMac版CS以降で開く時に文字化けを防ぐ方法 – ものかの
更新：CC以降のマッピングファイルの場所を追記しました。 注１：ここで説明する方法は、くれぐれも自己責任で慎重に行ってください。 旧Aiファイル（＝シフトJISベースで保存されるv10までのAiファイル）をMac版CS以降で開くと、シフトJIS外字がすべて化けます。こんな具合に。 見て分かるように、化けるだけではありません。文字そのものが完全に消失している箇所まであります。（イラレ8の文字化け見本ファイル） OpenTypeが登場するまで、日本のMac DTPでは83pvの和文PostScriptフォントが使われていました。83pvはWindowsのシフトJISであるCP932とほとんど同じです。シフトJIS外字領域の13区にもCP932と同様に丸数字、ローマ数字、単位記号などがあり、外字フォントなしで使えたため、日本語のMac DTPで普通によく使われました。その外字領域の文字がMac版
本当は恐ろしいInDesignの話 〜文字化け問題 | 電書魂
前回のエントリーで書かせていただいたInDesignデータからの電子書籍化に伴う外字処理の問題について、文字コード・フォント関連について豊富な知識をお持ちの方々に関心を持っていただき、これをどうにかするための取り組みが始まりました。具体的にはものかのさん、moji_memoさん、市川せうぞーさんの面々で、ちょっととんでもないレベルの方々です。これに対して、publidge（出版デジタル機構）の深沢さんからも関心を寄せていただき、フォントメーカーの方にもアドバイスをいただく形で電子書籍の外字問題に対しての取り組みが始まりました。以下は現時点で判明している問題についての簡単なまとめです。いずれこれに関してはpublidgeから正式にどういった対策をとるべきかのアナウンスがあることと思われますが、すでにかなり「恐ろしい」事実が判明しているので、事前段階での告知の一翼を担う意味で書かせていただきま
iPhoneの文字化けを防ぐ魔法の呪文 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
昨日のエントリ（「iPhoneのMailから送ったメッセージ全体が文字化け」のまとめ）読みましたよー。iPhoneから送るメールの文字化け防止策は、署名に「♡」を入れておけばOKなんですよね？ うん。ただまあ、ちょっと気にする人はいるかもなあ。 男子に誤解されちゃう、と？ いや、そういうのじゃなくて、つまり、化けちゃうんだよね。 えっ？ 相手の環境によっては「♡」が化けるんだよ。 何ですかそれ。文字化け対策で入れた文字が化けたら意味ないじゃないですか。 意味はあるよ。iPhoneから送ったメールは相手先で全体が化けて読めなくなる可能性があるけど、「♡」でcharset=UTF-8にしておけば、この「全体化け」を防げるんだから。ただし、相手がケータイだったりすると、「♡」自体は「･」とか「?」とかになっちゃうってこと。 自らは捨て石となってメッセージ全体を救うということですか。UTF-8にな
SafariからEUC-JPのページに書き込むと「鷗」などが化ける - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
SafariからEUC-JPのページ（はてなダイアリーやmixiなど）に、「鷗」と書き込むと「鴎」に化けたりする。似たような文字化けには、Unicode正規化によるもの（MailやSafariで互換漢字が化ける）やWindows外字に関するもの（EUC-JPのページにおけるWindows外字がめんどくさいことになっている件）などがあるが、ややこしいことに、この例はそのどちらでもない。 原因は、Safariの採用しているEUC-JP用の変換テーブル（IBM-33722）のフォールバック。下図は、UnicodeをEUC-JPに変換する際の、IBM-33722における漢字のフォールバックをまとめたもの*1。単に「EUC-JPにない文字」であれば、EUC-JPのページへは数値文字参照で送信されるので化けることはないのだが、フォールバックが定義されているために字体が変わってしまう。 ところで、素朴な
Illustrator CS4におけるグリフ置換の文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
たとえばIllustrator CS4でCID+14281を入力し、その後フォントを変更したとき。下図、左がフォント変更前、右が変更後。フォントの違いによって、同じグリフが4種類もの異なる化け方をしている。 このような文字化けは、「親字の符号位置と異体字（aalt）番号」によってグリフを指定する仕組みに起因するもので、InDesignでは2.0の時代に見られたものである。 cmapテーブル、aaltテーブル、またはレパートリが異なるフォント間で化ける可能性があり、どのグリフが化けるのかをトータルに把握するのは難しい。たとえば上の図のいちばん下の例では、cmapもaaltも同系統であるモリサワのPr6とProの間で、レパートリの違いによって化けている。 化けるのは漢字とは限らず、aaltで表現されている記号類は、かなりの確率で化ける。下図は、適当に拾ったごく一部の例。 CS以降のInDesi
小塚ProのSING拡張がらみの文字化け - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
InD-Boardの「字形について」というスレッドで話題になっていた「SINGで拡張された小塚Pro」の文字化けについて、InDesign CS4と小塚明朝Pro Rで検証してみた。 再現性にあいまいさはあるが、次のように言えそうだ。SINGで拡張された小塚Pro書体において、グリフXがSING拡張分ではなく（CIDが15443以下）、なおかつグリフXの親字PがSING拡張分であり（CIDが15444以上）、なおかつ親字Pの符号位置が基本多言語面の範囲外（Unicodeスカラ値が5桁）である場合、ドキュメントを保存して閉じた後に再び開くと、グリフXが親字Pに化けることがある。 わたしの環境では、字形パネルからダブルクリックで入力して（コピー＆ペーストや書体の変更などをせずに）すぐに保存し開き直した場合、前項の条件を満たすものは100%化けた*1。 下図は、化ける文字のリスト*2。グレー枠の
ワケのわからない13区問題 【Win篇】 - 実験る～む
ある意味どうでもいいことや、役立つかどうかもわからないような中身を、日々脳内から適当に垂れ流しまくりつつ、今日をなんとか生き存えることを思案してます。 はい、てことで昨日の続きです。 昨日書いてから「しまったこのボリュームなら4回くらいの小出しにしてエントリ数稼げばよかった」という小賢しいことを思ったりしたんですが、NAOIさんにコード周りの推測をしてもらったりしたことで、出すだけ出しておいて正解だったと思いました。 Illustratorの文字化けにおける「生き残り」の件 言われてみればということでコード表見直して納得しつつというかそこまで頭まわらなかったので感謝です。本気で13区自体しか見てなかったので。 ともあれ、後半のWindowsバージョンについて。 前回と基本的には同じ（先日記載したとおり、もとはWindows側で作成したデータなので、こちらが厳密にはオリジナル）ですが、Mac
Illustratorの文字化けにおける「生き残り」の件 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
「ワケのわからない13区問題 【Mac篇】」（実験る〜む）に反応。Illustrator 10以前のデータをCS3以降で開いたときの文字化けが、基本的には「83pvのデータを90pvフォントで開いたときの文字化け」のパターンなのだけれど、若干の例外（83pv外字がそのまま残る）が存在する件。 83pv外字の源流であるNEC外字は「JIS78に対する外字」だった。このため83pvは、JIS83で2区に追加された記号の一部を重複して含んでいる。Shift-JISベースのIllustrator（10以前）は、これらの重複した記号を2区の側の符号位置に統一して保存するため、CS3以降のIllustratorがテキストを「90pv to Unicode」のテーブルで変換した後も、該当する記号は化けずに生き残っているのだろう。下図、上は13区相当の83pv外字、下は2区の文字、黄色地は重複。
ワケのわからない13区問題 【Mac篇】 - 実験る～む
以前に見つけたエントリで、最近はてブしておいたもの。もっと早くしておけって感じですが。 「Illustrator CS3」でテキストを更新すると文字が消える （STAFF_01 [KYS-LAB]） ※関連：記号（機種依存文字）がCS3で文字化けする。CS2は正常。 （Adobe Forum） 最近、これと同じことをどーしても検証せざるを得なくなったので、してみました。 今回はMac側のおはなしで、Windowsは次回予定でやります。 自分でデータ作ってやっていますが、やってる方がワケわからなくなってきました（ぉ なので、「これ絶対こんな風に消える・化ける」ではなく「これらが起きるかもしれん」程度に考えたうえで見てください。といっても起きたら厄介な話なのは事実なんですが。 そのうえで、まず大枠の結論から書いておきます。 Illustrator 10以前のデータをIllustrator CS
kys-lab.com - このウェブサイトは販売用です！ - リソースおよび情報
このウェブサイトは販売用です！ kys-lab.com は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、kys-lab.comが全てとなります。あなたがお探しの内容が見つかることを願っています！
83pvと90pvの違い - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
83pvと90pvという用語についてのややこしい話は別の機会に譲ることとして、今回はとりあえず「どちらもMacのShift-JISのバリエーション」と大ざっぱに定義しておく。83pvと90pvでは、下図のように外字の割り当てが異なる。16進数はShift-JISの符号位置。 83pv外字は、PC98外字のサブセットである。0x86A2から0x879C（水色地）は漢字Talk 7.5以降に付属する細明朝体と中ゴシック体のスクリーン・フォントに含まれているもの。このうち0x8740から0x879CはCP932とほぼ共通（CP932では0x877Eに「平成」が追加されている）。0x8540から0x8690（ピンク地）の半角文字は、PostScriptプリンタで出力することが可能であるが細明朝体と中ゴシック体のスクリーン・フォントに含まれないもの。 アクセス・ログで「83pv 90pv 違い」とい
OpenTypeフォントの字形管理
字形のタグ OpenTypeフォントの優れている点としてよく挙げられるのが異体字をはじめとする豊富な文字数のサポートです。これまでは外字フォントを用意しなければならなかった文字でも、OpenTypeフォントだと探せばたいてい見つかるというのはDTPユーザーにとって大変ありがたいことです。 ただし、どこかにあるはずといっても、それが簡単に探せないようではあまり使いやすいとは言えません。通常の文字であれば「読み」によって日本語入力システムからアクセスすることができますが、異体字だとそのままではなかなか入力はできません。 フォントに含まれる文字は、文字コードと関連付けされることで入力や表示が可能になります。入力システムも文字コードを元に作られているわけですから文字コードの仕組みから外れるような異体字（たとえば同じコード番号で字形が異なるような場合）は入力システムでもサポートできないのが当然と言
アプリケーション間のコピー＆ペーストで化ける文字 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ
昨日のエントリ（Mac OS Xのリッチテキストの扱いに関する問題）では「InDesignでコピーしたテキストをJedit Xにペーストしたときの文字化け」に触れなかったので、今回は件の14文字について、アプリケーション間のコピー＆ペーストにおける挙動をやや網羅的に調べてみた。その結果が、下の表。 表のタテがテキストをコピーした側、ヨコがペーストされる側のアプリケーション（とモード）。文字が化けることなくペーストできた場合、空欄とした。A、B、Cは異なる化け方のパターンを示す。 下図の4つのブロックのうち、いちばん上がオリジナルの（コピー元の）テキスト。A、B、Cでは、（見た目だけではわからないものもあるので）化けている文字を赤色で示した。 Aパターンが、昨日のエントリで言及したもの。「Mac側」の7文字が「Win側」の7文字に化ける。昨日はリッチテキストのみに見られる現象として扱ったが、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
IBM Developer
