Multipurpose Internet Mail Extensions
出典: フリー百科事典『ウィキペディア（Wikipedia）』
Multipurpose Internet Mail Extension (MIME、マイム) は、規格上US ASCIIしか使用できないインターネットの電子メールでさまざまなフォーマット（書式）を扱えるようにする規格。 RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049 で規定されている。
インターネットでメールの書式を定めているRFC 2822のもとになったRFC 822ではUS ASCIIと呼ばれる7bitで表現できる英数字といくつかの記号の利用しか許していない。そのため、アルファベットより多くの文字数を必要とするアジア系の言語を使用したり、バイナリファイル、画像、音声などの非文字データの利用もできなかった。
MIMEはこれらのデータを取り扱うために新しくいくつかのヘッダを定義し、かつUS ASCII上でさまざまなデータタイプを表現するための符号化方法を規定している。
また、HTTPにおけるデータの伝送に関しても、MIMEの枠組みが援用されている。
目次 |
[編集] MIMEで導入されたヘッダ
[編集] MIME-Version
従来のRFC 822(RFC 2822)準拠のメッセージとの区別、あるいは将来MIMEが拡張されたときにバージョンを区別するためのヘッダ。現在は1.0が規定されている。
Mime-Version: 1.0
[編集] Content-Type
このメッセージ中のデータのタイプを指定する。 一般的な書式は次の通り。
Content-Type: [type]/[subtype]; parameter
typeには、"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とプレーンテキストのように、同じ情報を異なる形式で表したマルチパート）
- multipart/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
[編集] 8bit
[編集] binary
[編集] quoted-printable
ヨーロッパ系の言語では、多くの文字がUS ASCIIと同一で一部に独自の文字を使っているものが多い。 このような言語では、US ASCIIと重なっている文字はそのまま使い、存在しない文字だけ'=??'のような形でコード化する。ここで、??には特殊文字のコードを16進数で指定する。その他、以下のような規則がある。
- '='自体は'=3D'となる。
- 行末に空白がある場合、伝送の過程で失われるおそれがあるため、'=20'としてこれを保存する。
- エンコードの過程で行を折り返す（改行を挿入する）場合、'='と改行の組み合わせを挿入し、もともとあった改行と区別できるようにする。
quoted-printableを用いると、特殊文字以外はそのままの文字を使用しているので、データがほとんど大きくならず、quoted-pritable対応プログラムを使わなくても、大体の内容が読めると言う利点がある。
[編集] 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の作者も、それに対応することを余儀なくされている。
[編集] 関連項目
- MHTML (MIME Encapsulation of Aggregate HTML Documents)
 |
この「Multipurpose Internet Mail Extensions」は、コンピュータに関連した書きかけです。この記事を加筆して下さる人を求めています。（Portal:コンピュータ） |
