インターネットでの日本語メール

インターネットでの電子メールのやりとりが標準化されたのは1982年ですが、この時の標準はASCII文字しかやりとりできないなど制約の多いものであったため、様々なローカル規格が生まれてしまいました。そこで、1992年に新しい標準規格であるMIME発表されます。これによって、インターネットのメールに新しい標準ヘッダ、バイナリのエンコードなどの新しい本文記述法などが加わりました。

さらに、MIMEの仕様に基づいて日本語を扱う方法が慶応大学の村井氏らによって発表されました。今日の日本語メールはこれらの仕組みに基づいてやりとりされています。

※インターネットメールの仕組みや文字化けの解読法を詳しく解説した『プロフェッショナル電子メール』を上梓しました。

SMTP

1982年のRFC821で定められた標準で、Simple Mail Transfer Protocolの略です。ここではSMTPのサーバーとクライアントが対話的にコマンドをやりとりし、メールを転送する方法が規定されています。
また、RFC822では基本的なメールヘッダに関する定義が行われました。メールは〔ヘッダ〕と〔本文〕からなり、両者は空白行で区切られます（最初の空白行が現れるまでがヘッダ）。ヘッダは

（例）〔フィールド名〕: 〔内容〕

という形式になっており、一つのフィールドは複数行にわたっても構いません。さらに、ここではメールアドレスの表記方法も定義されました。

これらを合わせてメールの1982標準ができあがりましたが、これには

などの制限があり、バイナリデータはもちろん、日本語を送ることもままなりませんでした。そのため、いろいろなローカル規格が生まれて混乱し、新しい標準が求められるようになります。

〔補足:2001-03-19〕

RFC822は、2001年3月に新しい規格RFC2822によって上書きされました。RFC2822では、歴史的な経緯で規格に取り込まれていた古い書式を廃棄し、いくつかの曖昧な定義を厳密にしています。たとえば、古いメールソフトが差出人アドレスとして使っていた

（例） (KANZAKI Masahide) webmaster@kanzaki.com

という書式は、廃止されたものの一つです。

〔以上補足〕

MIME

1992年6月、インターネットメールで多様な情報を交換するための新しい規格（Multipurpose Internet Mail Extensions）がRFC1341、RFC1342として定められました。1982標準に比べ

などの機能が追加されています。

最新版はメッセージ本文についてRFC 2045、メッセージ・ヘッダについてRFC 2046を参照してください（これらは次に述べているRFC 1521, 1522を置き換えるものです）。

MIMEメッセージ・ヘッダ

RFC1522では、メッセージ・ヘッダに非ASCII文字を埋め込む標準的な方法が定められました。インターネット上ではメッセージが運ばれる過程でヘッダの追加や再構成が行われるため、例えば[ESC]文字（0x1B）のようなコントロールコードを含めることができません。これでは、JISコードを使った日本語をヘッダに使えないということになってしまいます。
そこで、RFC1522では、Quoted-PrintableやBASE64というMIME標準のエンコード方法を使って、これらの文字をASCIIに変換し、ヘッダに埋め込む方法を規定しています。

ヘッダのエンコードのルールは

（例）=?<charset>?<method>?<エンコードされたヘッダ文字列>?=

というように、両端に=を置き、?記号を使って３つの要素を結合したものです。<charset>とは、日本語ならISO-2022-JP、<method>はエンコードのタイプをQuoted-PrintableならQ、BASE64ならBと指定し、<ヘッダ文字列>にはその方式でエンコードした文字列を入れます。たとえば

（例）=?ISO-2022-JP?B?GyRCJD8hIxsoQg==?=

のような具合になります。 （電子メールを受け取ったとき、Subjectがこのように文字化けして読めないのは、メーラーがMIMEに対応していないため、ヘッダを解読できないからです）

日本語メール

RFC1468では、JUNETでやりとりされていた方式に基づいて、日本語をインターネットメールで送受信するときの標準的な方法を示しています。

ここではまず、メッセージはASCII文字列で開始されると仮定し、文字コードが日本語に変更されるときは ESC $ B のようなエスケープ・シーケンスを使って示すものとしています。

       Esc Seq    Character Set                  ISOREG

       ESC ( B    ASCII                             6
       ESC ( J    JIS X 0201-1976 ("Roman" set)    14
       ESC $ @    JIS X 0208-1978                  42
       ESC $ B    JIS X 0208-1983                  87

X 0208はいわゆるJISの漢字コード（年度によって若干の違いがあります）です。X 0201はJISローマ字で、一部を除いてほとんどASCIIと同じものです。RFC1468では、通信状態によりデータの一部が破損しても被害を最小にとどめられるよう、行の終わりやメッセージの最後はASCII文字に戻しておくことも定められています。これらにより、JISメールの本文の1行は次のような形になります。

（例）ASCII text... ESC $ B 日本語文字列... ESC ( B ASCII... etc... [CRLF]

この方法はISO-2022-JPとして公式に登録され、MIMEヘッダのcharsetとして指定することにより、確実に日本語のメールをやりとりできるようになりつつあります。なお、ISO-2022-JPで送ることができるのは7ビットJISコードのメールであって、Shift-JISやEUCのメッセージは保証されません。第8ビットを使用するこれらのコードでメッセージを送信すると、第8ビットが削除されて文字化けを起こすことがあります。
また、いわゆる「半角カナ」を含んだメッセージも同様のトラブルを起こす可能性が高いので、インターネットでは使わないようにするべきでしょう。

半角カナとJIS

1バイトカナ（半角カナ）は、2バイトの漢字や仮名を定めたJIS X 0208とは別に、JIS X 0201において定義されています。この文字セットは、アルファベット（ASCII）と同居するときは8ビットを使って、シフトJISと同じ位置に割り当てられますが（JIS8）、カナのみで7ビットによるコード化も合わせて定められています（JIS7）。これに対しては、コード切換のためのISO 2375で終端文字も4/9（十進数の73、ASCIIでいえばIに相当）として登録されています。

RFC1468には記載されていませんが、定義からESC ( I が7ビットのカタカナを指示（designate）するエスケープシーケンスとなるので、これを使って半角カナを送り出すメールソフトもあります。たとえば、Outlook ExpressやEudoraで「1バイトカナ可」とか「JIS X 0201カナを通す」とした場合は、この方法を使っています。裏技的な方法ですが、少なくともこれならば8ビット目の問題は生じませんし、このメッセージを受け取るときちんと半角カナで表示してくれるメールソフトも結構あるようです。

だからといって半角カナを推奨するわけではありません。このエスケープシーケンスを理解しないソフトもあるからです。メールに半角カナを書いてもうまく行ったというのは、たまたま両方のソフトがこの方式に対応していたというケースかも知れません。いずれにしても、1998年のJIS改定で、半角カナは使わないことと明記されていることですし、見た目も違和感があるので、半角カナはやめておきましょうね。