Macの"Mail" 「波ダッシュ」への対応（その4 追加）

これはMailの実装ミスと言っていいのではないかと思う事が判明。MacのMailは、自分が書いた「波ダッシュ」はそのままiso-2022-jpで「波ダッシュ」として送信するくせに、受信したメールに「波ダッシュ」が含まれていると、フォント指定の有無にかかわらず、返信・転送時にわざわざ必ずuft-8の「全角チルダ」に変換して、全体をquoted-printableかbase64にエンコードして送る。

この実装はあきらかに間違っている。iso-2022-jpの「波ダッシュ」は、どこに返信しようが転送しようが「波ダッシュ」と解釈され、正しく表示されるからだ。

参照：
Macの"Mail" 「波ダッシュ」への対応（その1　背景）
Macの"Mail" 「波ダッシュ」への対応（その2　本編）
Macの"Mail" 「波ダッシュ」への対応（その3　その他）

Macの"Mail" 「波ダッシュ」への対応（その3 その他）

OS間での「波ダッシュ」の混乱を回避する意味でも、普段のメールには「リッチ・テキスト形式」を避け、「プレーン・テキスト形式」を使うべきだと思う。なによりそれが標準であり、互換性の考慮などという通信の本来の目的以外のことにとらわれなくて済むからだ。

面倒なことにOutloook Expressなどは、インストールしてそのままの状態だとリッチ・テキスト形式が標準に設定されている。こういうところがWindowsの嫌いな部分だ。友人がリッチ・テキストでメールしている場合、「プレーンを標準にしてね」と頼むしかない。

ところで、Jeditというエディターを使っていて、この「波ダッシュ」について面白い処理をしているのに気がついた。「全角チルダ」として表示されている字をカット＆ペーストしてUTF-8形式で保存すると、EF BD 9Eとなる。だが、これを一度開いて上書き保存するとE3 80 9Cになるのだ。これは、Jeditがファイルを開く際に「全角チルダ」を「波ダッシュ」に読み替えているからに他ならない。

一度間違って実装されたものは、なかなかなかったことにはできない。Windowsのように広く普及した製品ではなおさらだ。（電流の方向が実は電子の流れと逆だったっていうことと似ている。）こういう混乱はユーザーにとって迷惑な話である上、プログラマー泣かせだなと思う。間違っていても、戻れない道というのはあって、その場合遠回りを強いられてしまうのだ。

Macの"Mail" 「波ダッシュ」への対応（その2 本編）

さて、メールの話である。インターネットのメールには、「[8bit]に透過的でない」通信路に日本語を通すために[7bit+parity bit]+[7bit+parity bit]のJISコードが使われたことで、今でもこれが標準的になっている。WindowsのメーラーもMacのメーラーもLinuxのメーラーも、基本的にプレーン・テキストのメールのやりとりには、ISO-2022JP、すなわちJISコードを使っている。JISコードが使われている限り、Windowsで入力された「波ダッシュ」も、0x2141で表されるため、Macで読み違えることはない。

実際にWindowsのメーラーから送られた「波ダッシュ」を、MacのMailでソース表示させると「$B!A(B」となっている。ここで、「$B」は[16bit]文字の始まりを表す記号で「(B」は終わりを示す記号、ASCII文字で21にあたるのが「!」、41にあたるのが「A」、この一連のコードで、単独の「波ダッシュ」を表す。このことで受け取った文字はMacでも無事に「波ダッシュ」と表示することになる。

逆の場合も同様、Macのメーラーが「$B!A(B」というコードを送れば、Windowsでもそれは「波ダッシュ」と解釈され表示される。た・だ・し、Windowsは受け取ったメッセージを表示する場合、内部的にこの「波ダッシュ」を「全角チルダ」にわざわざ変換していることに注意してほしい。つまり、Windowsのフォントでは、「波ダッシュ」を「波ダッシュ」と解釈すると、正しく表示できない場合があるからだ。（註：「場合」と言うのはVistaのフォント・セットで一部修正されているものがあるらしいからである。）

さあここからがややこしい話。メールではリッチ・テキスト形式、つまりHTML形式を使うことができるのだが、その場合、表示フォントの指定ができる。Windowsの場合、何も指定しなくても英字には「Arial」、日本語には「MS　ゴシック」が表示フォントとして指定される。このように表示フォントが指定されていると、MacのMailは「$B!A(B」をわざわざ「全角チルダ」に変換して表示するらしい。Macのフォント・セットでは「波ダッシュ」と「全角チルダ」は同じ形状をしているため、ユーザーは気がつかない。（11/10/2009追記：その後、「全角チルダへの読み替え」はフォントの指定によらないことがわかった。こちら参照。）

さて、一度「波ダッシュ」を「全角チルダ」として解釈したMailは、これに本文を引用して返信したり転送したりしようとするとJISには「全角チルダ」に相当するコードがないため、Unicodeのメッセージとして送ろうとする。Unicodeは[8bit]に透過的でないと送ることができないので、さらに全体をbase64でエンコードして送るのである。

一度「全角チルダ」と読んでしまったものを「波ダッシュ」に戻してJISに変換できないのはどうかとも思うが、プログラムを書く側にとってみれば、一番簡単に表示上の問題を解決する手段だったのだろう。「全角チルダ」を「波ダッシュ」に戻すルーチンを作るには、その「全角チルダ」が元々「全角チルダ」だったのか「波ダッシュ」を一時的に「全角チルダ」に読み直したものなのか判断するルーチンを加えなければならず、プログラムが複雑化する。

このように、つまらないミスがさらにおかしな判断ミスを誘い、結果的にプログラムの実装を複雑化させ、バグの発生を誘発するという、なさけない事情がMacのMailの「波ダッシュ」への対応には見られるのだ。

Macの"Mail" 「波ダッシュ」への対応（その1 背景）

「～」と「〜」。同じに見えるだろうか。Macからは同じに見えるが、Windowsからは違って見えるかもしれない。前者のは全角チルダ、後者は波ダッシュ、Unicodeでは異なる文字として扱われている。UTF-8でEF BD 9EとE3 80 9Cだ。そもそも使う目的の違うこのふたつはの文字は、その形状が似ているがゆえにとんでもない混乱をもたらしている。

なぜこんな話を切り出したかというと、友人からリッチテキストで送られてきたメールをMacのメーラーで保存したり返信したりすると、なにやらおかしな動作をするのだ。返信時にはメールの文字コードをわざわざUTF-8にした上、quoted-printableやbase64で変換して送るのである。送信前のメッセージを保存しようとするとエラーが出たりする。おかしな動作の原因がこの「波ダッシュ」のせいだということがわかり、少し調べてみた。

現在ののパソコン用OSは、文字の取扱にUnicodeを使っている。ならば、テキストのエンコードにはすべてUTF-8を用いれば簡単な話だが、パソコンで使われる文字コードにはその歴史ゆえにそう単純にいってない。複雑な事情をはしょって説明すると、Windows NTやMac OS Xが登場する以前、パソコンのスタンダードな文字コードはShift-JISだった。Shift-JISは[8bit]+[8bit]=[16bit]で漢字コードを表現し、アルファベットのASCIIコードとも親和性があった。（ASCIIコードは[7bit+parity bit]=[8bit]というコード体系である。）

一方、初期のインターネットではもともと[8bit]をベースにした文字コードを透過的に通すことができないネットワークだったため、[8bit]+[8bit]=[16bit]のShift-JISはそのままでは通信路に流せなかった。これは8bitの空間でASCIIの7bit目までで定義されていない領域を通信の制御用の文字として割り振っていたためである。通信制御用の機器間で送受されるASCIIコードは8ビット目を見なくても大丈夫だが、8bit目まできっちり定義されている文字コードについては、通信制御文字と誤認識されたり、8bit目が読まれずに文字化けしてしまうのだ。そのような事情から、インターネットで日本語を扱う時には[7bit] JIS（ISO-2022JP）という文字コードを使ってきた。

名前から察することができるように、Shift-JISの文字コードは、JISの文字コードをベースに、通信制御文字と重なることがないように「シフト」させた文字コードだ。文字自体はふたつのコード体系間で1対1で対応させることができる。

インターネットはその後、国際化と同時に通信設備も進化した物と入れ替わり、[8bit]トランスペアレントとなっていくのだが、文字コードについてはUnicodeによって世界中の文字を統一的なコード体系にまとめようという方向に向かう。国際化したパソコンOSの文字システムがUnicodeなのはこの流れだ。しかし、この過程で「波ダッシュ」混乱の火種がまかれる。Unicodeの仕様書において、「波ダッシュ」がこれまでShift-JISで使われていたのとは鏡対象の形状を誤ってサンプルに載せてしまったのだ。その一方で、「全角チルダ」を従来の「波ダッシュ」の形状で載せた。JISで「全角チルダ」の文字コードは定義がない。

ここで我らがMSの登場。WindowsのUnicode採用にあたって、Shift-JISの「波ダッシュ」を本来のUnicodeの「波ダッシュ」は形状が逆であるため、「全角チルダ」に対応するようにしてしまったのだ。こうして、UTF-8で本来の「波ダッシュ」として書かれた文字をWindowsは正しく表示できなかったりするという症状が出始めることとなる。

つづく