なぜ円記号はメールで化けるのか


  • Shift-JIS（CP932やMacJapanese）の時代には、バックスラッシュと円記号の違いを制御するのは困難だったため、「1B 28 42」と「1B 28 4A」の使い分けは一般化しなかった。しかし、現在使われているメーラーのほとんどは（携帯電話などを除けば）内部的にUnicodeで動作しており、（やろうと思えば）両者の使い分けが可能である。Mac OS XのMail（Apple Mail）は以前から、この使い分けを行っている。


  • では、他のメーラーはどうだろう？　手元にあるThunderbird（Mac版）とWindowsメール（Windows Vista）、Outlookについて調べてみた。結果は、下図のとおり（図中のバックスラッシュおよび円記号のグリフは、規格上期待されるグリフを表現したものであり、後述するように、実際の見え方とは一致しない）。


  • これらのいずれでも、受信したメールの解釈において「1B 28 4A」は「1B 28 42」と同一視される。また、送信するメールでは、円記号（U+00A5）はバックスラッシュに置き換えられた上で、ISO-2022-JPで符号化される。つまり、送り手が意図的に（解釈にブレのありうるU+005Cではなく）U+00A5の円記号を入力しても、（ISO-2022-JPで送信する限り）それが受け手に届くことはない。
  • もちろん、よく知られているように、MS書体やメイリオなどWindowsに付属する日本語フォントでは、U+005C REVERSE SOLIDUSのグリフが円記号となっており、見た目ではU+00A5 YEN SIGNと区別できない（下図）。このため、Windowsの世界で完結している限り、メーラーが「1B 28 42」と「1B 28 4A」を区別してもしなくても（そして、U+005CとU+00A5を区別しなくても）、見た目の上では同じである*2。


  • 一方、Windowsの世界の「外」が介在する場合、問題は顕在化する。Windowsメール、Outlook、Thunderbirdからcharset=ISO-2022-JPで送信された円記号は、（エスケープ・シーケンスを正しく解釈する）Apple Mailでバックスラッシュに化ける。また、Mac版のThunderbirdでは、自分で出したメールを自分で受信した場合も円記号がバックスラッシュに化けることとなる*3。

*1:他には7Eが違って、こちらにもややこしい話があるのだが、今回はスルーする。

*2:このような仕様の背景については、安岡さんの「YEN SIGN問題縁起」を参照されたい。

*3:Thunderbirdの仕様は見直してほしい。「1B 28 42」と「1B 28 4A」を区別することによるデメリットは特にないと思う。