MIME（Multipurpose Internet Mail Extensions）〜後編：インターネット・プロトコル詳説（4）

　まずヘッダ部で、マルチパートであることを宣言している。ボディ部は、複数の「MIMEヘッダ＋ボディ」から構成される「ミニ・メッセージ」、すなわち「パート」になっている。これが1つの添付ファイルやメール本文に該当する^＊1。多くのメーラでは、メール本文にテキストを記載してファイルを添付すると、このマルチパート形式となる。

　1つのパートの境界は、「バウンダリ：boundary」と呼ばれる任意の文字列の行で示される。これはContent-Typeのboundaryパラメータで、あらかじめヘッダに示されている。

　これで、1つのパートの開始を示す。また、次の文字列の場合、全体のマルチパートの終了を意味する。

　この境界ごとにパートは分割されると考える。また、マルチパートのパートとして、マルチパート・メッセージが含まれることがある。このような複雑な入れ子状態のメッセージも利用できる。

　マルチパートは、単に複数のファイルを送るという意味だけではなく、複数ファイルの組み合わせが変わることで、さまざまな意味をメッセージに持たせることができる。マルチパートのサブタイプとして、RFC2045とRFC2046では、次のような種類を定義している。

○multipart/mixed

　最も一般的なマルチパート。個々のパートはそれぞれ別のデータを示す。メーラはそれらすべてを個別に、かつ任意に表示できればよい

○multipart/alternative

　含まれるパートは同じ内容を示す。例えば、プレーンテキスト（text/plain）とHTML（text/html）に同じ本文が含まれる場合などに使用される。この場合、両方を同時に表示する必要がないため、HTML表示ができる場合にはHTMLを、そうでない場合にはテキストを表示するといった対応がメーラに求められる

○multipart/parallel

　含まれるパートを複合して同時に表示させる必要がある。例えば、音声ファイルと画像や動画ファイルとの組み合わせなどを想定している

○multipart/digest

　主にニュースやメール・メッセージを複数含めることを目的としている。例えば、メーリングリストなどで複数のメールをまとめて送りたい場合などに使用できる。そのため、含まれるパートは主にmessage/rfc822となる

日本語はテキストではない？〜テキストの送受信

　MIMEメールで注意する必要があるのは、テキストを送信するときである。この問題は、われわれが日本語を使用していることと関係している。

　すでに述べたように、インターネットメールは7ビットデータのみをテキストと見なし、それ以外のデータは、MIMEでのエンコードが必要となる。しかし、多くの日本語文字コードは8ビットコードである。例えば、シフトJIS、JIS、EUCがそうだ。

　ここでは詳細な文字コードの解説は省くが、唯一定義されている7ビットの日本語コードは、ISO-2022-JPと呼ばれるコードである。もともとは、JUNETと呼ぶ日本でのインターネット環境の前身であるネットワークで使用されていた文字コード体系である。

　このコード体系はJISとほぼ同じである。JISと異なるのは、半角カナなどに該当するコードが空けられている点だ。半角カナが該当するコードは、0x7f以上に該当するためだ。「メールで半角カナを使用してはいけない」というルールは、実はこれを反映している。

　ISO-2022-JPを使用してメールを表現すると、次のようになる。

　Content-Typeでは、コードがISO-2022-JPであることをcharsetによって示している。Content-Transfer-Encodingは、ISO-2022-JPが7ビットコードなので、当然7ビットである。ただし、この記述は省略してもよい（Content-Transfer-Encodingのデフォルト値が7ビットのため）。これで通常のテキストメールが完成する。

　多くの場合は、以上の方法で問題ない。しかし、シフトJISやほかのコードで表現したい場合もあるだろう。例えば、半角カナや機種依存コード（丸付き数字や単位記号など）を含んでいるため、ISO-2022-JPに変換できない場合や、正確に送信する必要のある原稿などを添付ファイルにする場合だ。

　こうした場合は、以下のように格納されることがある。

（中略）
MIME-Version: 1.0
Content-Type: text/plain; charset="SJIS"
Content-Transfer-Encoding: base64
（中略）

（中略）
MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
（中略）

　つまり、テキストファイルをバイナリファイルのように添付ファイルとして扱うのである。つまり、テキストファイルをMIME化すればよい（この方法は複数ある）。

　MIME化するメリットとしては、コードを変換することなく、そのまま相手に伝えることができる点にある。しかし、現在この方法に対応したメーラの中には、ユーザーが指定しない場合も日本語テキストを自動的にファイルにして添付できる製品が存在する。

　ややこしいのは、いずれも現在のMIMEの規格上、間違っていない点だ。つまり、さまざまな議論があるために明快な標準仕様がなく、その間にメーラでの実装が進んでしまったのである。さらに問題をさかのぼると、7ビットコードしか認めていなかったインターネットメール仕様に行き着いてしまう。

　こうした事情も、メールの歴史を考えると興味深いものがある。

ヘッダでの日本語の利用

　メール本文で日本語（非ASCII文字）を利用する場合は以上のとおりだ。これは、ボディのエンコードをヘッダで定義する考え方だと言い換えることもできるだろう。しかし、ヘッダでも日本語など、非ASCII文字を使用したい場合もあるはずだ。

一般的なヘッダでの利用

　主にSubjectやメールアドレスのコメント、フレーズ部分での非ASCIIテキストの利用方法は、RFC2047に定義されている。ここでは、前回で解説したエンコード方法のBase64やQuoted Printableを用いてエンコードして格納する。以下の例を見てほしい。

　これらは、「ヘッダ値」だけで行われるエンコード形式だと考えてほしい。

　エンコード部分は「=?」と「?=」で囲まれた部分になる。それが「?（クエスチョンマーク）」によって3つのブロックに分かれている。先頭のブロックは、エンコードされたデータの文字コードを示している。次のブロックは、元データのエンコード形式を示している。ここでは、Base64かQuoted Printable形式のいずれかが用いられる。最後のブロックは、エンコードされたデータだ。

　エンコードされたデータをエンコード方式に従ってデコードすると、文字コードで表現された非ASCII文字が現れる。

　また、エンコードする文字列が長すぎて複数行になることがある。こうした場合は、ほかのヘッダのように続く行は空白か水平タブで始めるとともに、同じ行内で「=?」と「?=」 で閉じなければならない。

添付ファイル名

　添付ファイル名は、通常Content-Dispositionヘッダのfilenameパラメータで表される。多くの場合、次の例のようにほかのヘッダ部分とまったく同じ表記になる。

　MIMEエンコードをそのまま適用した例

Content-Disposition: attachment; 
 filename="=?ISO-2022-JP?B?GyRCIXcjSSNUJW0lNCVeITwlLxsoQi5naQ==?=
 =?ISO-2022-JP?B?Zg==?="

　ところが、一般的に使用されているこの方式はMIME違反に当たる。RFC2047では、このようなエンコードされた文字列は、Content-Dispositionなどの「パラメータ」に現れてはいけないことになっている。実は、RFC2047での仕様は非ASCII文字を想定していないだけという可能性もあるが、このままでは大半の日本語対応メーラはMIME違反のままとなる。

　そこで、RFC2231では、以下のような方法で非ASCII文字の添付ファイル名を示すこととしている。上記の例をRFC2231形式で表してみよう。

　RFC2231を適用した例