Loading article…
MIME（Multipurpose Internet Mail Extensions ）は、電子メールメッセージのフォーマットを拡張し、 ASCII以外の文字セットによるテキスト、および音声、動画、画像、アプリケーションプログラムの添付ファイルをサポートする標準規格です。メッセージ本文は複数の部分で構成され、ヘッダー情報はASCII以外の文字セットで指定できます。MIME形式の電子メールメッセージは通常、 SMTP（ Simple Mail Transfer Protocol）、 POP（ Post Office Protocol）、 IMAP（ Internet Message Access Protocol）などの標準プロトコルを使用して送信されます。
MIMEはインターネット標準であり、以下のRFC（ Request for Comments）文書で規定されています：RFC 2045、 RFC 2046、 RFC 2047、 RFC 4288、 RFC 4289、 RFC 2049。SMTPメールとの統合については、 RFC 1521および RFC 1522で規定されています。
MIME形式は主にSMTP向けに設計されましたが、そのコンテンツタイプは他の通信プロトコルでも重要です。ワールドワイドウェブのハイパーテキスト転送プロトコル（HTTP）では、サーバーはWeb送信の先頭にMIMEヘッダーフィールドを挿入します。クライアントはコンテンツタイプヘッダーを使用して、指定されたデータタイプに適したビューアアプリケーションを選択します。
MIMEは、カーネギーメロン大学（CMU）で開発されたAndrewプロジェクトの一部であるAndrewメッセージングシステムから派生したもので、Andrew固有のデータフォーマットに代わるクロスプラットフォームの代替手段として開発されました。[ 1 ]
このヘッダーフィールドが存在する場合、メッセージはMIME形式であることを示します。値は通常「1.0」です。フィールドは次のように表示されます。
MIMEバージョン: 1.0
MIMEの共同開発者であるナサニエル・ボレンスタイン氏によると、バージョン番号は、後続バージョンでMIMEプロトコルに変更を加えることを可能にするために導入された。しかし、ボレンスタイン氏は、この機能の実装を妨げる仕様上の欠陥を認めている。
将来のMIMEバージョンをどのように処理するかについては、十分に規定していませんでした。…つまり、1.0を認識するコードを書いた場合、2.0や1.1に遭遇したらどうすればよいのでしょうか？私は自明のことだと思っていましたが、実際には皆それぞれ異なる方法で実装していました。その結果、インターネットが2.0や1.1を定義することはほぼ不可能になりました。[ 2 ]
元のMIME仕様では、メールメッセージの構造のみが記述されていました。表示スタイルについては触れられていませんでした。表示スタイルを指定するために、RFC 2183でcontent-dispositionヘッダーフィールドが追加されました。MIMEパートには以下の要素を含めることができます。
Content-Dispositionフィールドは、表示スタイルに加えて、ファイル名、作成日、更新日を指定するためのパラメータも提供しており、これらは受信者のメールユーザーエージェントが添付ファイルを保存するために使用できます。
以下の例はRFC 2183から引用したもので、ヘッダーフィールドが定義されています。
Content-Disposition: attachment; filename=genome.jpeg; 変更日時="1997年2月12日(水) 16:29:51 -0500";
ファイル名はRFC 2231で定義されているようにエンコードすることができます。
2010 年時点では、大多数のメール ユーザー エージェントはこの規定に完全に従っていませんでした。広く使用されているMozilla Thunderbirdメール クライアントは、メッセージのcontent-dispositionフィールドを無視し、表示する MIME パーツを自動的に選択するために独立したアルゴリズムを使用しています。Thunderbird はバージョン 3 より前のバージョンでは、新しく作成されたメッセージもすべての MIME パーツに対してインラインのcontent-disposition で送信します。ほとんどのユーザーは、content-disposition をattachmentに設定する方法を知りません。[ 3 ]また、多くのメール ユーザー エージェントは、 Content-Dispositionヘッダー フィールドのfilename パラメーターではなく、content-typeヘッダーのnameパラメーターにファイル名を指定してメッセージを送信します。ファイル名はfilenameパラメーター、またはfilenameとnameの両方のパラメーターで指定する必要があるため、この方法は推奨されません。[ 4 ]
HTTPでは、レスポンスヘッダーのContent-Disposition: attachmentフィールドは、通常、クライアントに対しレスポンスボディをダウンロード可能なファイルとして提示するよう指示するために使用されます。一般的に、このようなレスポンスを受信すると、Webブラウザはブラウザウィンドウにページとして表示するのではなく、ユーザーにコンテンツをファイルとして保存するよう促し、filenameにはデフォルトのファイル名が示されます。
1992年6月、MIME（RFC 1341、現在はRFC 2045により廃止）は、バイナリデータをASCIIテキスト形式以外の形式で表現するための一連の方法を定義しました。content -transfer-encoding: MIMEヘッダーフィールドは、2つの意味を持ちます。
RFC およびIANA の転送エンコーディングのリストでは、大文字と小文字を区別しない以下の値が定義されています。「7bit」、「8bit」、「binary」は、元のエンコーディングの上にバイナリからテキストへのエンコーディングが使用されていないことを意味します。これらの場合、ヘッダー フィールドは電子メール クライアントがメッセージ本文をデコードするには実際には冗長ですが、送信されているオブジェクトの種類を示す指標として役立つ場合があります。「quoted-printable」および「base64」の値は、バイナリからテキストへのエンコーディング スキームが使用され、メッセージを元のエンコーディング (UTF-8 など) で読み取る前に適切な初期デコードが必要であることを電子メール クライアントに伝えます。
SMTPトランスポートを介して任意のバイナリデータを8BITMIME拡張機能で送信するために明示的に設計されたエンコーディングは定義されていません。そのため、BINARYMIMEがサポートされていない場合は、base64またはquoted-printable（ただし、これらは非効率的です）が依然として役立つ場合があります。この制限は、MIME添付ファイルを使用するWebサービスやMTOMなど、MIMEの他の用途には適用されません。
RFC 2822以降、準拠するメッセージヘッダーのフィールド名と値はASCII文字を使用します。ASCII以外のデータを含む値は、リテラル文字列の代わりにMIMEエンコードワード構文（RFC 2047）を使用する必要があります。この構文では、元の文字エンコーディング（「 charset」）と、charsetのバイトをASCII文字にマッピングするために使用されるコンテンツ転送エンコーディングの両方を示すASCII文字の文字列を使用します。
形式は次のとおりです。「文字=?セット?エンコード エンコードされたテキスト」。??=
Qエンコーディングに似た Q エンコーディングを示す " " 、またはbase64エンコーディングを示す " "のいずれかになります。B疑問符（"?"）と等号（"="）のASCIIコードは、エンコードされた単語を区切るために使用されるため、直接表現することはできません。スペースのASCIIコードも、古いパーサーがエンコードされた単語を意図せず分割してしまう可能性があるため、直接表現することはできません。エンコードを小さくして読みやすくするために、スペースのASCIIコードにはアンダースコアが使用されますが、その副作用としてアンダースコアを直接表現することはできません。ヘッダーフィールドの特定の部分でエンコードされた単語を使用すると、直接表現できる文字にさらに制限が生じます。
例えば、
Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=
「件名: ¡Hola, señor!」と解釈されます。
ヘッダーフィールド名（例：件名）には、エンコードされた単語形式は使用されません。これらの名前は通常英語の用語であり、生メッセージでは常にASCII文字で表示されます。英語以外のメールクライアントでメッセージを表示する場合、ヘッダーフィールド名はクライアントによって翻訳される可能性があります。
MIMEマルチパートメッセージには、ヘッダーフィールドに境界Content-Type:が含まれます。この境界は、どのパートにも存在してはならず、パート間、およびメッセージ本文の先頭と末尾に次のように配置されます。
MIME-Version: 1.0 Content-Type: multipart / mixed ; boundary = frontier これはMIME形式の複数パートからなるメッセージです。 --frontier Content-Type: text / plain これがメッセージ本文です。 --frontier Content-Type: application / octet-stream Content-Transfer-Encoding: base64PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --frontier--各パートは、独自のコンテンツ ヘッダー (0 個以上のContent-ヘッダー フィールド) と本文で構成されます。マルチパート コンテンツはネストできます。Content-Transfer-Encodingマルチパート タイプの文字セットは、複数のレベルのデコードによって生じる複雑さを避けるため、常に「7bit」、「8bit」、または「binary」である必要があります。マルチパート ブロック全体には文字セットはありません。パート ヘッダー内の非 ASCII 文字はエンコード ワードシステムによって処理され、パート本文には、コンテンツ タイプに適した文字セットを指定できます。
注記:
MIME規格では、マルチパートメッセージのさまざまなサブタイプが定義されており、メッセージの各パートの性質とそれらの相互関係が規定されています。サブタイプは、Content-Typeメッセージ全体のヘッダーフィールドで指定されます。たとえば、ダイジェストサブタイプを使用するマルチパートMIMEメッセージの場合、ヘッダーフィールドはContent-Type「multipart/digest」と設定されます。
RFCでは当初、mixed、digest、alternative、parallelの4つのサブタイプが定義されていました。最低限準拠するアプリケーションはmixedとdigestをサポートする必要がありますが、その他のサブタイプはオプションです。アプリケーションは認識されないサブタイプを「multipart/mixed」として扱う必要があります。署名付きやフォームデータなどの追加のサブタイプは、その後、他のRFCで個別に定義されています。
Content-Typemultipart/mixed は、異なるヘッダーフィールドを持つファイルをインライン（または添付ファイル）で送信する場合に使用されます。画像やその他の読みやすいファイルを送信する場合、ほとんどのメールクライアントはそれらをインラインで表示します（ Content-Disposition: attachmentで明示的に指定されている場合は添付ファイルとして表示されます）。各パートのデフォルトのコンテンツタイプは「text/plain」です。
この型はRFC 2046で定義されています。[ 5 ]
multipart/digestは、複数のテキストメッセージを送信する簡単な方法です。各パートのデフォルトのコンテンツタイプは「message/rfc822」です。
MIMEタイプはRFC 2046で定義されています。[ 6 ]
multipart/alternative サブタイプは、各パートが同じ (または類似の) コンテンツの「代替」バージョンであり、それぞれが「Content-Type」ヘッダーで示される異なる形式であることを示します。パートの順序は重要です。RFC1341 では、次のように述べられています。一般に、multipart/alternative エンティティを構成するユーザーエージェントは、本文パートを優先順位の高い順に、つまり、優先される形式を最後に配置する必要があります。[ 7 ]
システムは、処理可能な「最適な」表現を選択することができます。一般的に、これはシステムが理解できる最後の部分になりますが、他の要因によって影響を受ける場合もあります。
クライアントはプレーンテキスト版よりも忠実度の低いバージョンを送信したがらない可能性が高いため、この構造ではプレーンテキスト版（存在する場合）を最初に配置します。これにより、マルチパートメッセージを理解できないクライアントのユーザーにとって使いやすくなります。
一般的に、multipart/alternative は、プレーンテキスト (text/plain) とHTML (text/html) の2 つの部分からなる電子メールに使用されます。プレーンテキスト部分は下位互換性を提供し、HTML 部分は書式設定やハイパーリンクの使用を可能にします。ほとんどの電子メールクライアントでは、ユーザーが HTML よりもプレーンテキストを優先するオプションを提供しています。これは、アプリケーションがメッセージのどの「最適な」部分を表示するかを選択する際に、ローカルな要因がどのように影響するかを示す一例です。
メッセージの各部分が同じ内容を表すことが意図されていますが、標準ではこれを強制する義務はありません。かつては、スパム対策フィルターはメッセージの text/plain 部分のみを調べていました。[ 8 ]これは text/html 部分よりも解析が容易だったためです。しかし、スパマーは最終的にこのことを利用し、無害に見える text/plain 部分を持つメッセージを作成し、text/html 部分に広告を掲載しました。スパム対策ソフトウェアは最終的にこのトリックに気づき、multipart/alternative メッセージ内のテキストが大きく異なるメッセージをペナルティの対象としました。[ 8 ]
この型はRFC 2046で定義されています。[ 9 ]
multipart/related は、各メッセージ部分が集合体全体の構成要素であることを示すために使用されます。これは、相互に関連する複数の構成要素からなる複合オブジェクトに使用されます。構成要素を個別に表示しても、適切に表示することはできません。メッセージは、ルート部分（デフォルトでは最初の部分）で構成され、ルート部分はインラインで他の部分を参照し、さらに他の部分を参照する場合があります。メッセージ部分は一般的にContent-IDで参照されます。参照の構文は規定されておらず、部分で使用されるエンコーディングまたはプロトコルによって決まります。
このサブタイプの一般的な用途の一つは、画像を含むウェブページ全体を単一のメッセージで送信することです。ルート部分にはHTMLドキュメントが含まれ、画像タグを使用して後続部分に格納されている画像を参照します。
この型はRFC 2387で定義されています。
multipart/report は、メールサーバーが読み取れるようにフォーマットされたデータを含むメッセージタイプです。これは、text/plain (または読みやすい他の content/type) と message/delivery-status に分割されており、message/delivery-status にはメールサーバーが読み取れるようにフォーマットされたデータが含まれています。
この型はRFC 6522で定義されています。
multipart/signed メッセージは、メッセージにデジタル署名を添付するために使用されます。これは、本文部分と署名部分の 2 つの部分から構成されます。MIME フィールドを含む本文部分全体が、署名部分の作成に使用されます。署名の種類は多数あり、例えば「application/pgp-signature」（RFC 3156）や「application/pkcs7-signature」（S/MIME）などがあります。
この型はRFC 1847で定義されています。[ 10 ]
multipart/encrypted メッセージは 2 つの部分から構成されます。最初の部分には、application/octet-stream という 2 番目の部分を復号するために必要な制御情報が含まれています。署名付きメッセージと同様に、制御部分のコンテンツ タイプが異なるため、さまざまな実装が存在します。最も一般的なタイプは、「application/pgp-encrypted」（RFC 3156）と「application/pkcs7-mime」（S/MIME）です。
RFC 1847で定義されているMIMEタイプ。[ 11 ]
MIMEタイプmultipart/form-dataは、フォームを通じて送信される値を表現するために使用されます。元々はHTML 4.0の一部として定義され、 HTTPを使用してファイルを送信する場合によく使用されます。RFC 7578で規定されており、RFC 2388に取って代わるものです。例
コンテンツタイプ multipart/x-mixed-replace は、HTTP 上でのサーバープッシュとストリーミングをエミュレートする技術の一部として開発されました。
混合置換メッセージのすべての部分は、同じ意味を持ちます。ただし、各部分は受信されるとすぐに、前の部分を無効化（置換）します。クライアントは、個々の部分が到着次第処理し、メッセージ全体が完了するのを待つべきではありません。
元々はNetscapeによって開発された[ 12 ]が、現在もMozilla、Firefox、Safari、Operaでサポートされている。IPカメラではMJPEGストリームのMIMEタイプとしてよく使用される[ 13 ] 。Chromeでは2013年までメインリソースとしてサポートされていた（このコンテンツタイプを使用して画像を表示することは今でも可能）[ 14 ] 。
multipart/byterange は、単一メッセージの連続しないバイト範囲を表すために使用され、サーバーが複数のバイト範囲を返す場合に HTTP で使用され、RFC 2616 で定義されています。