Mac OS Xの文字コード問題に関するメモ

■EUC-JPのページにおけるWindows外字がめんどくさいことになっている件

• EUC-JPのページにおけるWindows外字の扱いが、ややこしいことになっている。まあ、もともと外字なので化けることがあるのは当然とも言えるのだけれど、化け方のバリエーションが豊富で、どういう理屈で化けているのかがわかりにくい。以下、はてなとmixiで目に付いた文字化けについて、ざっとまとめてみようと思う。

• はてなダイアリーの詳細編集画面で、FirefoxまたはChromeから「﨑」という字を入力して「確認する」ボタンを押すと、「粼」に化ける（下図）。

• これは、はてなのサーバがCP51932のNEC選定IBM拡張文字領域をJIS X 0213と見なした上で補助漢字に変換しているためだが、へんな仕様だと思う（下図）。たぶんPerlのEncodeモジュールでEUC-JPをUnicodeに変換した上でEUC-JPに戻しているのだろう*1。

• mixiの日記でMac OS XのSafariから「﨑」を入力すると、豆腐に化ける。Safariで豆腐に見えているこの字は、Firefoxでは「凬」と表示される（下図）。

• 前回のエントリで述べたように、SafariにおけるIBM拡張文字の扱いは謎の独自仕様だが、mixiのサーバはこれをeucJP-msのIBM拡張文字と見なした上でCP51932のNEC選定IBM拡張文字に変換しているようだ（下図）。

• はてなダイアリーの詳細編集画面でSafariから「﨑」を入力して「確認する」ボタンを押すと、「紾」に化ける（下図）。

• これは、Safariの謎仕様とはてなの謎仕様、2つの原因が重なった文字化け（下図）。

• はてなダイアリーの「その場編集」画面でSafariから「﨑」を入力して「保存」ボタンを押すと豆腐に化けるが、これはFirefoxからは「﨑」に見える（下図）。

• この場面では、はてなのサーバは、Safari独自のIBM拡張文字を理解した上でCP51932のNEC選定IBM拡張文字に変換しているように見える（下図）。（括弧内追記。コメント欄でえむけいさんより『「その場編集」モードで化けないのははてながIBM-eucJPを解釈しているからではなく、ブラウザがUTF-8で送信しているからのようです』とのご指摘がありました）

• しかし、Firefoxで正しく「﨑」に見えているはてなダイアリーをブックマークすると、（はてなブックマークのページはEUC-JPではなくUTF-8であるため）たぶんPerlのEncodeでUnicodeに変換されることにより、「粼」に化ける（下図）。

• ちょっと前にkoikekaishoさんから「﨑がSafariで豆腐になるんだよね」という話を聞いたのをきっかけとして、検証したりしているうちに話がふくらんでしまったエントリ。結論としては、EUC-JPのページにおけるWindows外字は数値文字参照で表現するのが安全だと思う。

Permalink | コメント(5) | トラックバック(0) | 18:20

■SafariのEUC-JPがわからない

• Safariの「EUC（日本語）」が、わからない。CP51932でもeucJP-msでもないし、JIS X 0208の国際基準版・漢字用8ビット符号でもない。

• IBM拡張文字の扱いはeucJP-msに似ているのだが、互換性はまったくない（下図）。

• eucJP-msは補助漢字をサポートしているので、「補助漢字と重複しないIBM拡張文字」を上図の符号位置に収録しているわけだが、補助漢字をサポートせずに「補助漢字と重複しないIBM拡張文字」のみをサポートする意味が不明。（以下追記）Safariは補助漢字をサポートせず、「補助漢字と重複するIBM拡張文字」を補助漢字の領域でサポートしている（下図）。

• 補助漢字をサポートしているFirefoxの画面を、比較用に載せておく（下図）。

Permalink | コメント(3) | トラックバック(0) | 13:40

■Mac OS X 10.5のMailでドコモ発のメール本文が表示されないトラブル

• ドコモからyahooアカウント宛に送られてきたiモード絵文字入りのデコメを、Mac OS X 10.5（Leopard）のMailで見ると、本文が表示されない。というトラブルに遭遇したのでメモ。

• ドコモからケータイ以外にメールを送る場合、原則として、iモード絵文字は「〓」に変換される。しかし、ウェブメールの「Yahoo!メール」は絵文字に対応しているため、ドコモ発yahooアカウント宛のメールでは、iモード絵文字はISO-2022-JPの未定義領域を使って符号化される。

• この「yahooアカウント宛に送られたiモード絵文字」がウェブメール以外で化けるのは当然なのだけれど、Mac OS X 10.5のMailでは、これが他の文字にも影響をおよぼすようだ。

• 以下の図はいずれも、「メール」を表すiモード絵文字（キャリア外字）と「マジ!?」のデコメ絵文字（添付画像）を含むドコモ発のメッセージ。まず、下図はYahooアカウント宛のメッセージをウェブの「Yahoo!メール」で受信し表示したもの。

• 下図は、同じくyahooアカウント宛のメッセージをMac OS X 10.6（Snow Leopard）のMailで表示したもの。iモード絵文字は化けているが、それ以外の文字は読める。

• 下図は、（yahoo以外のアカウントの例として）MobileMeアカウント宛に送ったメッセージをMac OS X 10.6のMailで表示したもの。上と似ているが、この「〓」は、Mailで表示する際に化けているわけではなく、ドコモのサーバで変換済みの文字。

• で、下図は、yahooアカウント宛のメッセージをMac OS X 10.5（Leopard）のMailで表示したもの。本文がまったく表示されていない。

• とりあえずの対策は「Mac OS X 10.5のMailでyahooアカウントを使っている人は、ドコモから本文なしのメールが届いたらウェブで確認してみましょう」ってことかな。

Permalink | コメント(0) | トラックバック(0) | 17:07

■InDesign CS5でフォントを変えようとすると

• 2011年4月27日追記。このバグはInDesign CS5 7.0.4で修正されたようです。

• InDesign CS5でaalt属性を持つ文字のフォントを変更しようとすると、ロックされて変更できない、あるいは変更後に化けることがある。このトラブルは、「変更前のフォント」が、モリサワPro、ヒラギノPro/ProNなどの場合に発生する*1。

• 下図はCS4とCS5の比較。CS5、モリサワPro（またはヒラギノなど）、aaltという条件が重なると、フォントを変更しようとしても、ほとんど場合、ロックされる。下図青字は、フォントの変更の際に（文字化けを防ぐために）異体字属性が調整されているケース。

• このようなロックは「不要なはずのロック」だが、Cmd+Optionで強制的にフォントを変更（オーバーライド）すると、異体字属性の調整が行われないので、文字化けする可能性がある（下図）。オーバーライドというのは、基本的に「文字化け覚悟の手段」であると考えるべきだろう。

• InDesign CS5でaalt属性を持つ文字をモリサワProやヒラギノPro/ProNなどから変更しても、ロックされないことが、まれにある。そのような場合は、文字化けする（下図）*2。つまり、ロックされるか化けるか以外に道はない。

• より複雑な化け方もある。たとえば、リュウミンPr6NからProに変更し、またPr6Nに戻すと化ける、というパターン（下図）*3。こうなると、もう何が何だかわからない。

Permalink | コメント(3) | トラックバック(0) | 16:28

■InDesign CS4でヒラギノの矢印が文字化け

• InDesign CS4。ヒラギノの右矢印のうちaaltで表現されているものを選択し、（ヒラギノtoヒラギノで）ウエイトなどを変更すると、文字化けする。右以外の矢印では化けないようだ（下図）。

• 以前に書いた「IInDesignにおけるJIS04基準フォントのウマヤ化け問題」と似ているが、条件が異なる。化ける理屈については深追いせずに、とりあえず現象だけメモ。

Permalink | コメント(0) | トラックバック(0) | 17:13