ＭＩＭＥ（Multipurpose Internet Mail Extensions）については、そうそう簡単に説明しきれるものではない。こればっかりは迂闊なことも言えないのだが、基本的なところの「さわり」だけを紹介するにとどめる。最下段にあるＲＦＣのリストについても、代表的なもののみにとどめてある。なにしろ、網羅するのだけでも大変なのだ。
メールは当初「US-ASCII」のみで書かれるものであったが、これだけでは物足りず（？）、多様化のためにＭＩＭＥが出現してきたことになる。ＲＦＣから引用を行うと、
ＭＩＭＥを扱うためには、まずヘッダで確認を行う。バージョンとして、「MIME-Version: 1.0」というような記述があるはずだ。バージョンをチェックし、適切な処理を行うのが本来だ。筆者の場合は、厳密なところは勘弁してもらうことにした。更に、どうしても避けて通れないところだけをツマミ食いすることにすると、おおよそ次に並べたようなヘッダ情報に基づいてメールを扱えば良さそうだ。
| Content-type: | データのタイプをあらわす。スラッシュ「/」で区切られるが、前の部分は text, image, audio, video, application などで、後ろの部分はそのサブタイプ、また、セミコロン「;」があった場合、以降はパラメータとなる。Content-type: text/plain; charset=us-ascii であれば、文字列であり、平文であり、英字であるわけだ。 |
| Content-Type: multipart/mixed | これは、上であげたContent-Typeの一種であるが、ひとつのメールの中にいくつかの異なったパートがあることを示すものである。この後ろにはパラメータとして、 boundary="========"のように、パートを区切る目印が付いている。このメールは、区切り毎に分け、それぞれのパートのＭＩＭＥヘッダを参照しつつ処理して行くことになる。入れ子になることもあるので注意が必要。 |
| Content-Transfer-Encoding | もともとのデータがバイナリ（８ビット）であったとしても、メールに添付する際に変換が行われることが多い。従来のメールシステムでは７ビットキャラクタしか扱えないものも多いため、互換性を維持する必要があるからだ。こうした場合に、変換方法を示し、メール送付先での復元を可能とする。 |
| Content-Disposition: | 電子メールにファイル添付した場合の、表示方法を指定する。inline, attachment等があり、画像などを画面上に表示するか、添付ファイルとするかを指定する。添付ファイルの場合は、パラメータを付属させ、ファイル名称を指定する。 |
| Content-Description: | 含まれているデータに関する説明。例えば、画像であれば何の画像かを説明するようなもの。 |
| Content-ID: | これは、マルチパートにおける各パートを識別するためのＩＤである。 |
ＭＩＭＥそのものの基本的なルールは上記の通り、それほど難しいものではない。しかしながら、それぞれのデータを復元し、適切に処理するのは、インターネット情報を扱う能力だけでは済みそうも無い。メールリーダを作成する際には、目的に応じて、テキスト処理のみとか、添付ファイルを復元する機能だけを追加するとか、ある種割り切ったほうがよさそうだ。
| Protocol | Name | RFC |
|---|---|---|
| MIME | MIME Part 1:Format of Internt Message Bodies | 2045 |
| MIME-MEDIA | MIME Part 2:Media Types | 2046 |
| MIME-MSG | MIME Part 3:Message Header Extensions for Non-ASCII Text | 2047 |
| MIME | MIME Part 4:Registration Procedures | 2048 |
| MIME-Conf | MIME Part 5:MIME Conformance Criteria | 2049 |
| MIME-RELAT | MIME Multipart/Related Content-type | 2112 |
| ---- | Content-Disposition Header | 1806 |