ここでは、非 ASCII 文字をメールで使うために人々が奮闘してきた歴史を漢字 を例に取って振り返ります。
1982年、互換性を保証するために、メールの規格 RFC822 が記述されました。メー ルはアメリカ育ちであったため、残念ながら本文やヘッダには、ASCII 文字列し か格納できない規格でした。
しかし、英語以外の言語を母国語としている人達にはとても不便です。そこで、 配送に関わるヘッダはともかく、本文に母国語を格納するため RFC822 はさまざ まな国で拡張されました。
ヨーロッパ諸国では、ウムラウト(アクセント)文字を表す8ビット1文字のコード Latin 1 がよく使われるようになりました。Latin 1 は ISO 8859 1 と呼ばれる ことがあります。
日本では、7ビット2文字の JIS コード、UNIX でよく使われる 8ビット2文字の EUC コード、パソコンで使われている 8ビット2文字の SJIS コードが存在しま した。日本のインターネットの前身である JUNET の先駆者達は、配送のための コードとして JIS コードを ESC シーケンスで切り替える、いわゆる JUNET コー ドを選びました。
JUNET コードは ISO 2022 JP と呼ばれることがあります。JUNET コードを使え ば、複数の文字コードを切り替えるだけでなく、使われている文字コードが何か という情報を得られます。
Latin 1 や JUNET コードに見られる本文の拡張は、あくまで地域に限定された 紳士協定です。RFC822 を使う限り、地域間を越えてメールをやりとりするには、 結局英語を使うしかないのです。
RFC822 は記述が曖昧なので、ヘッダや本文に 7 ビット文字である JUNET コー ドを入れてもよいように読めます。たぶん、この説明を読めば誤解が解けるでしょ う。「RFC822 は、ヘッダと本文のシンタックス(構文)を7ビット、それらのセマ ンティックス(意味)を US-ASCII と定めています。JUNET コードのシンタックス は RFC822 に従っていますが、セマンティックスは RFC822 に違反しています。」
絵や音声などを配送したい、地域化されたメールの架け橋となる規格が欲しいな どの要望を満たすために、1992年に MIME が規定されました。MIME では、テキ ストの文字コードを charset というパラメータに指定できます。たとえば、 JUNET コードは、ISO 2022 JP と呼びますから、以下のようになります。
Content-Type: Text/Plain; charset=iso-2022-jp 日本語のテキスト
この charset は役に立つのでしょうか？ もちろんです。charset は、インター フェイスに正しくテキストの文字コードを伝える役割を果たします。ノルウェー の人が ISO 8859 1 で日本にメールを送ってきたとしましょう。ISO 8859 1 に 対応しているインターフェイスなら、対応するフォントで表示すればいいし、対 応していないなら無視すればいいのです。Mew では、Mule の内部コードに変換 する関数の引数に charset を利用しています。
「ISO 2022 JP の上位互換規格であり、さまざまな文字コードを格納できる ISO 2022 JP2 などを使えば charset など要らない。なぜなら ISO 2022 JP2 自体に 文字コードの情報が含まれているから」という人がいます。しかし、これらの人 は MIME を理解できているとは思えません。
確かに理想的にいえば、この主張は正しいのです。しかし、MIME は現実主義で す。MIME はユーザが明日から ISO 2022 JP2 を使うようになるという大胆な仮 定はしていません。また、世の中に存在する脆弱な配送プログラムでも安定して 動くように考慮されていいます。世の中は、そんなにお行儀のよいプログラムば かりではないし、たくさんの資源を使えるほど豊かでもないのです。「明日から UNICODE を使え」と言われたらいやでしょう？
MIME は、さまざまに地域化されたメールの架け橋として charset を用意しまし た。MIME で増えた作業は、charset の挿入だけであり、今まで通り我々は ISO 2022 JP を使えます。ISO 2022 JP2 を標準にしたいなら、ISO 2022 JP2 をデフォ ルトで使う地域を広げていけばよいのです。この意味で、ISO 2022 JP2 と MIME は相反してはなく、逆に、ISO 2022 JP2 の普及のために MIME を利用できると 言えます。もちろん文字コードの符号化方式である ISO 2022 xx に charset と いう単語が相応しくないのは、MIME の開発者も認めているところです。
MIME を使えば、非 ASCII 文字を ASCII 文字列に符号化し、ヘッダに挿入できま す。このような枠組で、メールの配送プログラムの誤動作を防止し、また、ヘッ ダに英語以外の言語を書くことを実現しているのです。もう、Subject: に「日 本語を書いてはいけません」なんて言わなくてよくなりました。:)
MIME は地域化された RFC 822 を禁止する規格ではありません。よって、MIME のインターフェイスは、以下のような動作が望まれています。
読むとき
書くとき
スプールやフォルダに ISO 2022 JP を EUC Japan に変更して格納する場合は、 無条件に変換してはいけません。きちんと charset を確かめ、ISO 2022 JP だ けを EUC Japan に変換するようにして下さい。
ヘッダに非 ASCII 文字を挿入する機能は MIME の一機能ですが、実際には、 MIME-Version: フィールドは必要ありません。
残念ながら、世の中のコンピュータは、データをさまざまな方法で表現します。 以下によく利用されている OS とその行末を示します。
よって、行末に関して取り決めがないと、これらの OS 間では安全にテキストが 交換できません。RFC822 では、メールの再送の際に行末を CRLF に変換するこ とになっています。このように、共通の書式への変換を「正規化」といいます。 SJIS や EUC Japan を JUNET コードに直すのも正規化の一種です。
さて、PGP の暗号化や署名ついて考えてみましょう。たとえば、Mac のユーザが 行末が CR である文章に署名し UNIX ユーザに送ったとします。UNIX ユーザが 行末を LF に変換し署名を確認したとしたら、検証が失敗するのは明らかでしょ う。そこで、PGP への入力はあらかじめ正規化されている必要があるのがお分か りになると思います。
PGP で暗号化したり署名したりする場合は、まずテキストを ISO 2022 JP に変 換し、行末を CRLF に直して下さい。
Go to the first, previous, next, last section, table of contents.