Multipurpose Internet Mail Extensions

Multipurpose Internet Mail Extension（多目的インターネットメール拡張‎）は、規格上US-ASCIIのテキストしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格である。通常はMIME（マイム）と略される。RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289^[1]、RFC 2049 で規定されている。

概要

インターネットでメールの書式を定めているRFC 5322 (旧RFC 822、RFC 2822)では、英数字といくつかの記号を7 ビットで表現する「US-ASCII」と呼ばれる文字コードを利用し、1行あたり1000 バイト(改行を含む)のテキストデータしか許していない。そのため、規格に不適合になるような長い行、US-ASCIIだけで表現できない文字や、バイナリデータ、画像、音声などの非文字データを利用することができなかった。

MIMEはこれらのデータを取り扱うために新しくいくつかのヘッダを定義し、かつUS-ASCII上でさまざまなデータタイプを表現するための符号化方式を規定している。

RFC 5322 (旧RFC 822、RFC 2822)では1 通のメールで1つの本文しか扱うことができないが、MIMEでは本文を分割して複数のコンテンツを扱うことができるようにした。これをマルチパートと呼ぶ。MIMEヘッダには、MIMEメッセージヘッダとMIMEパートヘッダの二つがある。MIMEメッセージヘッダはメッセージ全体に適用され、MIMEパートヘッダはマルチパートメッセージの各部分に適用される。

また、HTTPにおけるデータの伝送に関しても、MIMEの枠組みが援用されている。

MIMEで導入されたヘッダ

MIME-Version

従来のRFC 5322 (RFC 822, RFC 2822) 準拠のメッセージとの区別、あるいは将来MIMEが拡張されたときにバージョンを区別するためのヘッダ。現在は1.0のみが規定されている。

Mime-Version: 1.0

Content-Type

このメッセージ中のデータのタイプを指定する。一般的な書式は次の通り。

Content-Type: type/subtype; parameter

typeには、text（テキスト）、image（画像）、audio（音声）、video<code>（動画）、<code>application（アプリケーションプログラム固有のフォーマット）などを指定して、データそのものの型を指定できる他、message、multipart を指定することで、ひとつのMIMEメッセージの中にさらに別のMIMEメッセージを指定することもできる。

subtypeには、typeの詳細な形式を指定する。以下のようなものがよく使われる。

text/plain（プレーンテキスト）
text/html（HTMLテキスト）
application/xhtml+xml（XHTMLテキスト）
image/gif（GIF画像）
image/jpeg（JPEG画像）
image/png（PNG画像）
video/mpeg（MPEG動画）
application/octet-stream（任意のバイナリデータ）
application/pdf（PDF文書）
message/rfc822（RFC 822形式）
multipart/alternative（HTMLメールのHTMLとプレーンテキストのように、同じ情報を異なる形式で表したマルチパート）
application/x-www-form-urlencoded（HTTPのPOSTメソッドによるフォームデータの送信）
multipart/form-data（同上、主にファイルアップロードを伴う場合）

なお、正式なsubtypeが与えられていないデータ形式には、x-で始まる独自の名称を使うことができる（例: application/x-gzip）。また、vnd. で始まるベンダー固有の名称を使うこともできる（例: application/vnd.ms-excel）。

parameterは追加の情報を指定する。よく使われるものに、text/plain や text/html の文字コード系を明記する charset パラメータがある。

typeによってはデフォルトのsubtypeが規定されており、受信側は自分の扱えないsubtypeであってもデフォルトのsubtypeとして扱うことにより最低限の取り扱いが可能となる。text のデフォルトは text/plain、application のデフォルトは application/octet-stream、multipart のデフォルトは multipart/mixed である。

`Content-Transfer-Encoding`

MIMEではUS-ASCIIだけでなくデータのさまざまな符号化方法の指定がこのヘッダで可能になっている。書式は以下の通り。

Content-Transfer-Encoding: mechanism

mechanismとして、7bit、8bit、binary、quoted-printable、base64 が指定できる。一般的に利用できるのは 7bit、quoted-printable、base64 であり、8bit、binary は一定の条件を満たす場合しか利用できない。

`7bit`

デフォルト値。7 ビットのテキストを表す。Content-Transfer-Encoding ヘッダフィールドを省略した場合は、この 7bit を指定したのと同じ意味となる。US-ASCIIやISO-2022-JPは確実に7 ビットのテキストであるため、これにあたる。

`8bit`

8 ビットのテキストを表す。 RFC 5322 (旧RFC 822、RFC 2822)は7 ビットのテキストを前提としており、この8bitは意図的に違反するものである。メールを転送するためのSMTPは基本的に7 ビットのテキストしか転送できないため、このエンコーディングを用いることはできない。RFC 1652で定義されるSMTPの拡張(ESMTP)の8BITMIMEを用いるか、8 ビットを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。

`binary`

データがテキストではなくバイナリであることを表す。RFC 5322 (旧RFC 822、RFC 2822)はテキストを前提としており、このbinaryは意図的に違反するものである。SMTPは基本的に行単位でデータを扱うため、行の概念すらないバイナリは転送できない。RFC 3030で定義されるESMTPの1つであるBINARYMIMEを用いるか、バイナリを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。

`quoted-printable`

US-ASCIIに存在する文字はそのまま使い、存在しない文字などを =HHのような形で符号化する。ここで、HH には文字のコードを大文字の16進数で指定する。その他、以下のような規則がある。

= 自体は =3D となる。
行末に空白がある場合、伝送の過程で失われるおそれがあるため、=20 としてこれを保存する。
エンコードの過程で行を折り返す（改行を挿入する）場合、= と改行の組み合わせを挿入し、もともとあった改行と区別できるようにする。

ヨーロッパ系の言語では、多くの文字がUS-ASCIIと同一で一部に独自の文字を使っているものが多い。この場合に quoted-printable を用いると、US-ASCIIはそのままの文字を使用しているので、データがほとんど大きくならず、quoted-pritable 対応プログラムを使わなくても、大体の内容が読めるという利点がある。しかし通常のバイナリデータや、Shift_JISやEUC-JPといった仮名漢字などの非ヨーロッパ系の文字のテキストデータに quoted-printable を適用した場合は、base64を使用した場合よりも大幅にデータが大きくなる。「Quoted-printable」を参照。

`base64`

3オクテット（24 ビット）を6 ビットずつ4つに分割し、各6 ビットの値に対してそれぞれUS-ASCIIの64 文字（英字52 文字、数字10 文字、「+」、「/」）を割り当てる符号化方式。詳細は「Base64」の項を参照。

この符号化によって、SMTPなどUS-ASCIIしか許されていない通信路でもバイナリデータを交換できるメリットはあるが、データ容量は約33%増加する。

ヘッダでの非US-ASCII 文字の扱い

上記のヘッダの導入によって、body部のデータタイプや符号化方式は指定できるようになったが、このままではヘッダ部は相変わらずUS-ASCIIしか利用できない。MIMEではRFC 2047やRFC 2231によって、ヘッダ部分での非US-ASCII文字の扱いを規定している。RFC 2047によれば、

=?charset?encoding?encoded-text?=

という形式により、文字コード系がcharset、符号化方法がencodingで、encoded-textと符号化された単語を表現できる。charsetは Content-Type:text/plain における charset パラメータで指定するのと同じ、IANAに登録された文字列を用いる。encoding は Q または B（大文字でも小文字でもよい）であり、前者はほぼ quoted-printable と同じ符号化方法、後者は base64を用いることを表す。

RFC 2047では、「"」で囲まれた中でこのような符号化された単語を解釈することはできない、とされている。したがって、「"=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?="」は「=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?=」と解釈しなければならず、これを「日本語」と解釈することは、規格違反となる。しかし、Microsoft Outlook Expressなど、一部のMUAがこのような誤った符号化を実装してそれが普及してしまったため、それを規格違反と知っているMUAの作者も、それに対応することを余儀なくされている。

RFC 2231では、MIMEパラメータの値に非US-ASCII文字を指定する方法を規定している。これによれば、添付ファイル名など、MIMEパラメータの値としての「ISO-2022-JP''%1B$BF|K%5C8l%1B%28B」を「日本語」と解釈することができる^[2]。また、RFC 5322に適合しない長さの文字列を短く分割して指定する方法も規定している。

脚注

テンプレート:脚注ヘルプテンプレート:Reflist