読み込み中...Multipurpose Internet Mail Extensions
Multipurpose Internet Mail Extension（多目的インターネットメール拡張?）は、規格上US-ASCIIのテキストしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格。通常はMIME（マイム）と略される。RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 で規定されている。
インターネットでメールの書式を定めているRFC 822とそれを更新するRFC 2822では、英数字といくつかの記号を7bitで表現する「US-ASCII」と呼ばれる文字コードの利用したテキストデータしか許していない。そのため、US-ASCIIだけで表現出来ない言語や、バイナリデータ、画像、音声などの非文字データを利用することができなかった。
MIMEはこれらのデータを取り扱うために新しくいくつかのヘッダを定義し、かつUS-ASCII上でさまざまなデータタイプを表現するための符号化方法を規定している。
RFC 822及びRFC 2822では一通のメールで一つの本文しか扱う事が出来ないが、MIMEでは本文を分割して複数のコンテンツを扱う事が出来るようにした。これをマルチパートと呼ぶ。
また、HTTPにおけるデータの伝送に関しても、MIMEの枠組みが援用されている。
MIMEで導入されたヘッダ
MIME-Version
従来のRFC 822 (RFC 2822) 準拠のメッセージとの区別、あるいは将来MIMEが拡張されたときにバージョンを区別するためのヘッダ。現在は1.0が規定されている。 Mime-Version: 1.0Content-Type
このメッセージ中のデータのタイプを指定する。一般的な書式は次の通り。
Content-Type: [type]/[subtype]; parametertypeには、"text"（テキスト）, "image"（画像）, "audio"（音声）, "video"（動画）, "application"（アプリケーションプログラム固有のフォーマット）などを指定して、データそのものの型を指定できる他、"message", "multipart"を指定することで、一つのMIME messageの中にさらに別のMIME messageを指定することもできる。
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（同上、主にファイルアップロードを伴う場合）
また、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
デフォルト値。7bitのテキストを表す。 Content-Transfer-Encodingヘッダフィールドを省略した場合は、この7bitを指定したのと同じ意味となる。US-ASCIIやISO-2022-JPは7bitのテキストであるため、これにあたる。
8bit
8bitのテキストを表す。RFC 822やRFC 2822は7bitのテキストを前提としており、この8bitは意図的に違反するものである。メールを転送するためのプロトコルSMTPは基本的に7bitテキストしか転送できないため、このエンコーディングを用いることは出来ない。RFC 1652で定義されるSMTPの拡張(ESMTP)の8BITMIMEを用いるか、8bitを許容するような全く別のプロトコルを用いた場合のみ利用が可能である。
binary
データがテキストではなくバイナリであることを表す。RFC 822やRFC 2822はテキストを前提としており、このbinaryは意図的に違反するものである。SMTPは基本的に行単位でデータを扱うため、行の概念すらないバイナリは転送できない。RFC 3030で定義されるESMTPの一つであるBINARYMIMEを用いるか、バイナリを許容するような全く別のプロトコルを用いた場合のみ利用が可能である。
quoted-printable
US-ASCIIに存在する文字はそのまま使い、存在しない文字だけ'=??'のような形でコード化する。ここで、??には特殊文字のコードを16進数で指定する。その他、以下のような規則がある。- '='自体は'=3D'となる。
- 行末に空白がある場合、伝送の過程で失われるおそれがあるため、'=20'としてこれを保存する。
- エンコードの過程で行を折り返す（改行を挿入する）場合、'='と改行の組み合わせを挿入し、もともとあった改行と区別できるようにする。
しかし通常のバイナリデータや、Shift_JISやEUC-JPといった日本語などの非ヨーロッパ系の言語のテキストデータにquoted-printableを適用した場合はBase64を使用した場合よりも大幅にデータが大きくなる。
Base64
3オクテット (24bit) を6bitずつ4つに分割し、各6bitの値に対してそれぞれUS-ASCIIの64文字（英字52文字、数字10文字、「+」、「/」）を割り当てる符号化方式。詳細は「Base64」の項を参照。
この符号化によって、SMTPなどUS-ASCIIしか許されていない通信路でもバイナリデータを交換できるメリットはあるが、データ容量は33%増加する。
ヘッダでのnon US-ASCII 文字の扱い
上記のヘッダの導入によって、body部のデータタイプや符号化方式は指定できるようになったが、このままではヘッダ部は相変わらずUS-ASCIIしか利用できない。MIMEではRFC 2047によって、ヘッダ部分でのnon US-ASCII文字の扱いを規定している。これによれば、 =?charset?encoding?encoded-text?=という形式により、文字コード系がcharset、符号化方法がencodingで、encoded-textと符号化された単語を表現できる。charsetはContent-Type:Text/Plainにおけるcharsetパラメータで指定するのと同じ、IANAに登録された文字列を用いる。encodingはQまたはB（大文字でも小文字でもよい）であり、前者はほぼQuoted-Printableと同じ符号化方法、後者はBASE64を用いることを表す。
- RFC2047では「"」で囲まれた中でこのような符号化された単語を用いることはできないとされており、したがって「"日本語"」のような表記は（「"」も含めて符号化するのでない限り）規格違反となる。しかしMicrosoft Outlook Expressなど一部のMUAがこのような誤った符号化を実装してそれが普及してしまったため、それを規格違反と知っているMUAの作者も、それに対応することを余儀なくされている。
関連項目
読み込み中...
