Multipurpose Internet Mail Extensions

（多目的インターネットメール拡張）は、規格上US-ASCIIのテキストしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格である。通常はMIME（マイム）と略される。RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289、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パートヘッダはマルチパートメッセージの各部分に適用される。マルチパートにより、1つのメールに複数の種類のファイルを扱うことができるようになった。
また、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"は大分類となるデータの種類を指定する。"subtype"にはより詳細な形式を指定する。"parameter"は追加の情報を指定するもので、複数指定できる。電子メールメッセージにおいて使われる例を以下に示す。
"type"毎に未知の"subtype"の扱いが規定されており、受信側は自分の扱えない"subtype"であっても最低限の取り扱いが可能となる。codice_4 の場合は codice_5、codice_6、codice_7 の場合は codice_8 である。codice_9、codice_10、codice_11、codice_12などは、未知の"subtype"についてcodice_6として扱うよう規定している。
codice_14.
MIMEではUS-ASCIIだけでなくデータのさまざまな符号化方法の指定がこのヘッダで可能になっている。
書式は以下の通り。
 Content-Transfer-Encoding: "mechanism"
"mechanism"として、codice_15、codice_16、codice_17、codice_18、codice_19 が指定できる。一般的に利用できるのは codice_15、codice_18、codice_19 であり、codice_16、codice_17 は一定の条件を満たす場合しか利用できない。
codice_15.
デフォルト値。7 ビットのテキストを表す。codice_14 ヘッダフィールドを省略した場合は、この codice_15 を指定したのと同じ意味となる。US-ASCIIやISO-2022-JPは確実に7 ビットのテキストであるため、これにあたる。
codice_16.
8 ビットのテキストを表す。
RFC 5322 (旧RFC 822、RFC 2822)は7 ビットのテキストを前提としており、この8bitは意図的に違反するものである。メールを転送するためのSMTPは基本的に7 ビットのテキストしか転送できないため、このエンコーディングを用いることはできない。RFC 1652で定義されるSMTPの拡張(ESMTP)の8BITMIMEを用いるか、8 ビットを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
codice_17.
データがテキストではなくバイナリであることを表す。RFC 5322 (旧RFC 822、RFC 2822)はテキストを前提としており、このbinaryは意図的に違反するものである。SMTPは基本的に行単位でデータを扱うため、行の概念すらないバイナリは転送できない。RFC 3030で定義されるESMTPの1つであるBINARYMIMEを用いるか、バイナリを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
codice_18.
US-ASCIIに存在する文字はそのまま使い、存在しない文字などを codice_31"HH"のような形で符号化する。ここで、"HH" には文字のコードを大文字の16進数で指定する。その他、以下のような規則がある。
ヨーロッパ系の言語では、多くの文字がUS-ASCIIと同一で一部に独自の文字を使っているものが多い。
この場合に codice_18 を用いると、US-ASCIIはそのままの文字を使用しているので、データがほとんど大きくならず、codice_37 対応プログラムを使わなくても、大体の内容が読めるという利点がある。
しかし通常のバイナリデータや、Shift_JISやEUC-JPといった仮名漢字などの非ヨーロッパ系の文字のテキストデータに codice_18 を適用した場合は、base64を使用した場合よりも大幅にデータが大きくなる。
codice_19.
3オクテット（24 ビット）を6 ビットずつ4つに分割し、各6 ビットの値に対してそれぞれUS-ASCIIの64 文字（英字52 文字、数字10 文字、「+」、「/」）を割り当てる符号化方式。
この符号化によって、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"は codice_40 における codice_41 パラメータで指定するのと同じ、IANAに登録された文字列を用いる。"encoding" は codice_42 または codice_43（大文字でも小文字でもよい）であり、前者はほぼ codice_18 と同じ符号化方法、後者は codice_19を用いることを表す。