「Multipurpose Internet Mail Extensions」の版間の差分
削除された内容 追加された内容
えｄ タグ: サイズの大幅な増減 |
219.127.104.174 (会話) による ID:49868229 の版を取り消し タグ: サイズの大幅な増減 |
||
1行目:
{{lang|en|'''Multipurpose Internet Mail Extension'''}}（'''多目的インターネットメール拡張'''）は、規格上[[ASCII|US-ASCII]]の[[プレーンテキスト|テキスト]]しか使用できない[[インターネット]]の[[電子メール]]でさまざまなフォーマット（書式）を扱えるようにする規格である。通常は'''MIME'''（マイム）と略される。RFC 2045、RFC 2046、RFC 2047、RFC 4288、RFC 4289<ref>旧RFC 2048。</ref>、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パートヘッダはマルチパートメッセージの各部分に適用される。
また、[[Hypertext Transfer Protocol|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''には、<code>text</code>（テキスト）、<code>image</code>（画像）、<code>audio</code>（音声）、<code>video<code>（動画）、<code>application</code>（アプリケーションプログラム固有のフォーマット）などを指定して、データそのものの型を指定できる他、<code>message</code>、<code>multipart</code> を指定することで、ひとつのMIMEメッセージの中にさらに別のMIMEメッセージを指定することもできる。
''subtype''には、''type''の詳細な形式を指定する。以下のようなものがよく使われる。
*<code>text/plain</code>（[[プレーンテキスト]]）
*<code>text/html</code>（[[HyperText Markup Language|HTML]]テキスト）
*<code>application/xhtml+xml</code>（[[Extensible Hypertext Markup Language|XHTML]]テキスト）
*<code>image/gif</code>（[[Graphics Interchange Format|GIF]]画像）
*<code>image/jpeg</code>（[[JPEG]]画像）
*<code>image/png</code>（[[Portable Network Graphics|PNG]]画像）
*<code>video/mpeg</code>（[[Moving Picture Experts Group|MPEG]]動画）
*<code>application/octet-stream</code>（任意のバイナリデータ）
*<code>application/pdf</code>（[[Portable Document Format|PDF]]文書）
*<code>message/rfc822</code>（[[RFC 822]]形式）
*<code>multipart/alternative</code>（HTMLメールのHTMLとプレーンテキストのように、同じ情報を異なる形式で表したマルチパート）
*<code>application/x-www-form-urlencoded</code>（[[Hypertext Transfer Protocol|HTTP]]のPOSTメソッドによる[[フォーム]]データの送信）
*<code>multipart/form-data</code>（同上、主にファイルアップロードを伴う場合）
なお、正式な''subtype''が与えられていないデータ形式には、<code>x-</code>で始まる独自の名称を使うことができる（例: <code>application/x-gzip</code>）。また、<code>vnd.</code> で始まるベンダー固有の名称を使うこともできる（例: <code>application/vnd.ms-excel</code>）。
''parameter''は追加の情報を指定する。よく使われるものに、<code>text/plain</code> や <code>text/html</code> の[[文字コード]]系を明記する <code>charset</code> パラメータがある。
''type''によってはデフォルトの''subtype''が規定されており、受信側は自分の扱えない''subtype''であってもデフォルトの''subtype''として扱うことにより最低限の取り扱いが可能となる。<code>text</code> のデフォルトは <code>text/plain</code>、<code>application</code> のデフォルトは <code>application/octet-stream</code>、<code>multipart</code> のデフォルトは <code>multipart/mixed</code> である。
===<code>Content-Transfer-Encoding</code>===
MIMEではUS-ASCIIだけでなくデータのさまざまな符号化方法の指定がこのヘッダで可能になっている。
書式は以下の通り。
Content-Transfer-Encoding: ''mechanism''
''mechanism''として、<code>7bit</code>、<code>8bit</code>、<code>binary</code>、<code>quoted-printable</code>、<code>base64</code> が指定できる。一般的に利用できるのは <code>7bit</code>、<code>quoted-printable</code>、<code>base64</code> であり、<code>8bit</code>、<code>binary</code> は一定の条件を満たす場合しか利用できない。
====<code>7bit</code>====
デフォルト値。7 ビットのテキストを表す。<code>Content-Transfer-Encoding</code> ヘッダフィールドを省略した場合は、この <code>7bit</code> を指定したのと同じ意味となる。US-ASCIIや[[ISO-2022-JP]]は確実に7 ビットのテキストであるため、これにあたる。
====<code>8bit</code>====
8 ビットのテキストを表す。
RFC 5322 (旧RFC 822、RFC 2822)は7 ビットのテキストを前提としており、この8bitは意図的に違反するものである。メールを転送するための[[Simple Mail Transfer Protocol|SMTP]]は基本的に7 ビットのテキストしか転送できないため、このエンコーディングを用いることはできない。RFC 1652で定義されるSMTPの拡張(ESMTP)の'''8BITMIME'''を用いるか、8 ビットを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
====<code>binary</code>====
データがテキストではなくバイナリであることを表す。RFC 5322 (旧RFC 822、RFC 2822)はテキストを前提としており、このbinaryは意図的に違反するものである。SMTPは基本的に行単位でデータを扱うため、行の概念すらないバイナリは転送できない。RFC 3030で定義されるESMTPの1つである'''BINARYMIME'''を用いるか、バイナリを許容するような全く別のプロトコルを用いた場合のみ、利用が可能である。
====<code>quoted-printable</code>====
US-ASCIIに存在する文字はそのまま使い、存在しない文字などを <code>=</code>''HH''のような形で符号化する。ここで、''HH'' には文字のコードを大文字の16進数で指定する。その他、以下のような規則がある。
* <code>=</code> 自体は <code>=3D</code> となる。
* 行末に空白がある場合、伝送の過程で失われるおそれがあるため、<code>=20</code> としてこれを保存する。
* エンコードの過程で行を折り返す（改行を挿入する）場合、<code>=</code> と改行の組み合わせを挿入し、もともとあった改行と区別できるようにする。
ヨーロッパ系の言語では、多くの文字がUS-ASCIIと同一で一部に独自の文字を使っているものが多い。
この場合に <code>quoted-printable</code> を用いると、US-ASCIIはそのままの文字を使用しているので、データがほとんど大きくならず、<code>quoted-pritable</code> 対応プログラムを使わなくても、大体の内容が読めるという利点がある。
しかし通常のバイナリデータや、[[Shift_JIS]]や[[EUC-JP]]といった仮名漢字などの非ヨーロッパ系の文字のテキストデータに <code>quoted-printable</code> を適用した場合は、[[base64]]を使用した場合よりも大幅にデータが大きくなる。「<code>[[Quoted-printable]]</code>」を参照。
====<code>base64</code>====
3[[8ビット|オクテット]]（24 ビット）を6 ビットずつ4つに分割し、各6 ビットの値に対してそれぞれUS-ASCIIの64 文字（英字52 文字、数字10 文字、「+」、「/」）を割り当てる符号化方式。詳細は「[[Base64]]」の項を参照。
この符号化によって、[[Simple Mail Transfer Protocol|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''は <code>Content-Type:text/plain</code> における <code>charset</code> パラメータで指定するのと同じ、[[Internet Assigned Numbers Authority|IANA]]に登録された文字列を用いる。''encoding'' は <code>Q</code> または <code>B</code>（大文字でも小文字でもよい）であり、前者はほぼ <coe>quoted-printable</code> と同じ符号化方法、後者は <code>base64</code>を用いることを表す。
* RFC 2047では、「<code>"</code>」で囲まれた中でこのような符号化された単語を解釈することはできない、とされている。したがって、「<code>"=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?="</code>」は「<code>=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?=</code>」と解釈しなければならず、これを「日本語」と解釈することは、規格違反となる。しかし、[[Outlook Express|Microsoft Outlook Express]]など、一部の[[電子メールクライアント|MUA]]がこのような誤った符号化を実装してそれが普及してしまったため、それを規格違反と知っているMUAの作者も、それに対応することを余儀なくされている。
* RFC 2231では、MIMEパラメータの値に非US-ASCII文字を指定する方法を規定している。これによれば、[[添付ファイル]]名など、MIMEパラメータの値としての「<code>ISO-2022-JP''%1B$BF|K%5C8l%1B%28B</code>」を「日本語」と解釈することができる<ref>「<code>''</code>」は、二重引用符ではなく、2 個の単一引用符である。</ref>。また、RFC 5322に適合しない長さの文字列を短く分割して指定する方法も規定している。
== 脚注 ==
{{脚注ヘルプ}}{{Reflist}}
== 関連項目 ==
* [[拡張子]]
* [[電子メール]]
* [[Simple Mail Transfer Protocol|SMTP]] (Simple Mail Transfer Protocol)
* [[MHTML]] (MIME Encapsulation of Aggregate HTML Documents)
* [[S/MIME]] (Secure / Multipurpose Internet Mail Extensions)
{{internet-stub}}
{{DEFAULTSORT:まるちはあはすいんたあねつとめえるえくすてんしよんす}}
[[Category:電子メールのプロトコル]]
[[Category:Hypertext Transfer Protocol]]
[[Category:RFC]]
| |||