Apple Mailのテキストエンコーディングの細かい話

• 先日のエントリ（Apple Mailにおけるテキストエンコーディングの優先順位）の続き。Apple Mailは、日本語環境においては、送信しようとしているメールに含まれる文字の種類によってcharsetを決定するが、やや複雑なのが、仮名や漢字が出現しないケースである。

• 話の前提として、ASCII（ISO/IEC 646 IRV）とJIS X 0201のラテン文字のレパートリとしての違いを示しておく。

• ASCIIとJIS X 0201のラテン文字集合のみの世界におけるApple Mailのテキストエンコーディングは、次の表のようにまとめることができる。ただし、オーバーライン（U+203E OVERLINE）を含む場合、実際には「Apple Mailでオーバーラインを送信しようとするとエラーになる」に書いた通りのアラートが表示される。この表では、オーバーラインは手動で指定して送信できるcharsetのグループ分類した。

• まず、JIS X 0201のラテン文字集合を符号化するために、なぜISO-2022-JPではなくSHIFT_JISを使うのかが謎である。「JIS X 0201のラテン文字集合に切り替えるエスケープ・シーケンスを正しく解釈してくれないメール・クライアントが存在するため」という可能性も考えられないではないが、仮名が1文字でも使われていればISO-2022-JPになるのだから、「仮名や漢字が出現しない」という非常に例外的なケースに限ってそのようなことを考慮しても意味があるとは思えない。とは言っても、SHIFT_JISを使うのが間違いだというわけではないし、以下、仕様と割り切って話を進める。

• バックスラッシュ（U+005C REVERSE SOLIDUS）が円記号（U+00A5 YEN SIGN）やオーバーラインと混在するケースでは、charset=SHIFT_JISとなり、バックスラッシュは0x815F（JIS X 0208の01-32）に変換される。確かに世の中にはそういう変換テーブルも存在するのだが、これだとUnicode対SHIFT_JISが2対1変換となり、往復の保全性を確保することができない。自分宛に送信したものを受信してみると、バックスラッシュ（U+005C REVERSE SOLIDUS）が全角（U+FF3C FULLWIDTH REVERSE SOLIDUS）に置き換わっているということになる。

• チルダ（U+007E TILDE）が円記号やオーバーラインと混在するケースでは、（なぜかISO-2022-JPを飛び越えて）charset=UTF-8となる。