マイム

MIME ( Multipurpose Internet Mail Extensions ) は、電子メールメッセージの形式を拡張して、ASCII以外の文字セットのテキスト、およびオーディオ、ビデオ、画像、アプリケーション プログラムの添付ファイルをサポートする標準です。メッセージ本文は複数の部分で構成され、ヘッダー情報は非 ASCII 文字セットで指定できます。MIME 形式の電子メール メッセージは通常、Simple Mail Transfer Protocol (SMTP)、Post Office Protocol (POP)、およびInternet Message Access Protocol (IMAP) などの標準プロトコルを使用して送信されます。

MIME はインターネット標準です。これは、RFC 2045、 RFC 2046、 RFC 2047、 RFC 4288、 RFC 4289 、および RFC 2049の一連のRCFで規定されています。SMTP 電子メールとの統合は、 RFC 1521および RFC 1522で規定されています。

MIME 形式は主に SMTP 用に設計されましたが、そのコンテンツ タイプは他の通信プロトコルでも重要です。World Wide Webのハイパーテキスト転送プロトコル(HTTP)では、サーバーは Web 送信の先頭に MIME ヘッダー フィールドを挿入します。クライアントはコンテンツ タイプまたはメディア タイプヘッダーを使用して、指定されたデータの種類に適したビューア アプリケーションを選択します。

MIMEは、カーネギーメロン大学（CMU）で開発されたAndrewプロジェクトの一部であるAndrewメッセージングシステムに由来し、Andrew固有のデータ形式のクロスプラットフォームの代替として登場しました。^[1]

このヘッダー フィールドが存在する場合、メッセージが MIME 形式であることを示します。値は通常「1.0」です。フィールドは次のように表示されます。

MIME バージョン: 1.0

MIME の共同作成者であるNathaniel Borensteinによると、バージョン番号は、MIME プロトコルの今後のバージョンでの変更を可能にするために導入されました。しかし、Borenstein は、この機能の実装を妨げた仕様の欠陥を認めました。「将来の MIME バージョンの処理方法を適切に指定していませんでした。... つまり、1.0 を認識するものを書いた場合、2.0 または 1.1 に遭遇したらどうすればよいのでしょうか。私はそれが明白だと思っていましたが、誰もがそれをさまざまな方法で実装していることがわかりました。その結果、インターネットで 2.0 または 1.1 を定義することはほぼ不可能です。」^[2]

このヘッダーフィールドは、メッセージコンテンツのメディアタイプを示し、タイプとサブタイプで構成されます。たとえば、

コンテンツタイプ: text/plain

MIME では、マルチパートタイプを使用することで、メール メッセージの部分をツリー構造に配置できます。このツリー構造では、リーフ ノードは任意の非マルチパート コンテンツ タイプであり、非リーフ ノードはさまざまなマルチパート タイプのいずれかです。このメカニズムは以下をサポートします。

• text/plain を使用したシンプルなテキスト メッセージ(「Content-Type:」の既定値)
• テキストと添付ファイル（text/plain部分とその他の非テキスト部分が混在する multipart/mixed）。添付ファイルを含む MIME メッセージでは、通常、ファイルの元の名前が "Content-Disposition" ヘッダーで示されるため、ファイルの種類は MIME コンテンツ タイプと（通常はOS固有の）ファイル名拡張子の両方で示されます。
• オリジナルを添付した返信（text/plain部分とmessage/rfc822部分としてのオリジナルメッセージを含むmultipart/mixed ）
• 代替コンテンツ、たとえばプレーンテキストとHTMLなどの別の形式の両方で送信されるメッセージ( text/plainとtext/html形式で同じコンテンツを持つmultipart/alternative )
• 画像、音声、ビデオ、アプリケーション (例: image/jpeg、audio/mp3、video/mp4、application/mswordなど)
• 他の多くのメッセージ構成

元の MIME 仕様では、メール メッセージの構造のみが記述されていました。プレゼンテーション スタイルの問題は扱われていませんでした。プレゼンテーション スタイルを指定するために、RFC 2183 で content-disposition ヘッダー フィールドが追加されました。MIME パーツには次のものが含まれます。

• インラインコンテンツ配置。メッセージが表示されるときに自動的に表示されることを意味します。
• 添付ファイルのコンテンツ処理。この場合、添付ファイルは自動的には表示されず、ユーザーが何らかのアクションを実行して開く必要があります。

プレゼンテーション スタイルに加えて、Content-Dispositionフィールドには、ファイル名、作成日、および変更日を指定するためのパラメータも用意されており、リーダーのメール ユーザー エージェントが添付ファイルを保存するために使用できます。

次の例は、ヘッダー フィールドが定義されている RFC 2183 から抜粋したものです。

コンテンツ配置: 添付ファイル; ファイル名=genome.jpeg;
  modification-date="水曜日、1997 年 2 月 12 日 16:29:51 -0500";

ファイル名は、RFC 2231 で定義されているとおりにエンコードできます。

2010 年時点で、メール ユーザー エージェントの大多数はこの規定に完全に従っていませんでした。広く使用されているMozilla Thunderbirdメール クライアントは、メッセージ内のcontent-dispositionフィールドを無視し、自動的に表示する MIME パーツを選択するための独立したアルゴリズムを使用します。バージョン 3 より前の Thunderbird も、すべての 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 つの意味があります。

• これは、Content-Type ヘッダー内で指定された元のエンコードに加えて、バイナリからテキストへのエンコードスキームが使用されているかどうかを示します。

1. このようなバイナリからテキストへのエンコード方法が使用されている場合は、どの方法であるかが示されます。
2. そうでない場合は、8 ビットまたはバイナリ コンテンツの存在に関して、コンテンツの形式を説明するラベルを提供します。

RFC および IANA の転送エンコーディングのリストでは、大文字と小文字を区別しない以下の値が定義されています。「7bit」、「8bit」、および「binary」は、元のエンコーディングに加えてバイナリからテキストへのエンコーディングが使用されていないことを意味します。これらの場合、ヘッダー フィールドは実際には電子メール クライアントがメッセージ本文をデコードするのに冗長ですが、送信されるオブジェクトの種類を示す指標として役立つ場合があります。値「quoted-printable」および「base64」は、電子メール クライアントに、バイナリからテキストへのエンコーディング スキームが使用され、メッセージを元のエンコーディング (UTF-8 など) で読み取る前に適切な初期デコードが必要であることを伝えます。

• 通常の SMTP での使用に適しています:
  • 7 ビット- コード範囲 1..127 の行あたり最大 998オクテット。CR と LF (それぞれコード 13 と 10) は、CRLF 行末の一部としてのみ表示できます。これがデフォルト値です。
  • quoted-printable – 任意のオクテット シーケンスを 7 ビットの規則を満たす形式にエンコードするために使用されます。主に US-ASCII 文字で構成され、その範囲外の値を持つバイトが少量含まれるテキスト データに使用すると、効率的でほぼ人間が判読できるように設計されています。
  • base64 – 任意のオクテット シーケンスを 7 ビットのルールを満たす形式にエンコードするために使用されます。非テキスト 8 ビットおよびバイナリ データに効率的になるように設計されています。US-ASCII 以外の文字を頻繁に使用するテキスト データに使用されることもあります。
• 8BITMIME SMTP 拡張 (RFC 6152) を サポートする SMTP サーバーでの使用に適しています。
  • 8 ビット- 1 行あたり最大 998 オクテット。CR と LF (それぞれコード 13 と 10) は、CRLF 行末の一部としてのみ表示できます。
• BINARYMIME SMTP 拡張 (RFC 3030) をサポートする SMTP サーバーでの使用に適しています。
  • バイナリ– 任意のオクテットのシーケンス。

8BITMIME 拡張を持つ SMTP トランスポートを介して任意のバイナリ データを送信するように明示的に設計されたエンコードは定義されていません。したがって、BINARYMIME がサポートされていない場合は、base64 または quoted-printable (それに伴う非効率性) が依然として役立つ場合があります。この制限は、MIME 添付ファイルやMTOMを含む Web サービスなどの MIME の他の用途には適用されません。

RFC 2822 以降、準拠メッセージ ヘッダー フィールド名と値には ASCII 文字が使用されています。非 ASCII データを含む値には、リテラル文字列ではなく、MIMEエンコード ワード構文 (RFC 2047) を使用する必要があります。この構文では、元の文字エンコード (" charset ") と、charset のバイトを ASCII 文字にマップするために使用されるコンテンツ転送エンコードの両方を示す ASCII 文字の文字列が使用されます。

形式は「文字=?セット?エンコーディング エンコードされたテキスト」 です。??=

• charset は、 IANAに登録されている任意の文字セットにすることができます。通常は、メッセージ本文と同じ文字セットになります。
• エンコーディングは、quoted-printableQエンコーディングに類似した Q エンコーディングを表す " "か、base64エンコーディングを表す " "のいずれかになります。B
• エンコードされたテキストは、 Q エンコードまたは base64 エンコードされたテキストです。
• エンコードされた単語は、文字セット、エンコーディング、エンコードされたテキスト、および区切り文字を含めて 75 文字を超えることはできません。75文字のエンコードされた単語に収まらないテキストをエンコードする必要がある場合は、複数のエンコードされた単語(CRLF SPACE で区切る) を使用できます。

疑問符 ("?") と等号 ("=") の ASCII コードは、エンコードされた単語を区切るために使用されるため、直接表現できない場合があります。スペースの ASCII コードは、古いパーサーがエンコードされた単語を不適切に分割する可能性があるため、直接表現できない場合があります。エンコードを小さくして読みやすくするために、スペースの ASCII コードを表すためにアンダースコアが使用されていますが、その副作用として、アンダースコアは直接表現できないという問題があります。ヘッダー フィールドの特定の部分でエンコードされた単語を使用すると、直接表現できる文字にさらなる制限が課せられます。

例えば、

Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

「件名: ¡Hola, señor! 」と解釈されます。

ヘッダー フィールドの名前 (たとえば、Subject ) には、エンコードされた単語形式は使用されません。これらの名前は通常、英語の用語であり、生のメッセージでは常に ASCII です。英語以外の電子メール クライアントでメッセージを表示する場合、ヘッダー フィールド名はクライアントによって翻訳されることがあります。

MIME マルチパート メッセージには、ヘッダー フィールドに境界Content-Type:が含まれます。この境界は、どのパーツにも出現してはならず、パーツ間、およびメッセージ本文の先頭と末尾に次のように配置されます。

MIME バージョン: 1.0
コンテンツ タイプ: multipart / mixed ; boundary = frontier  

これは MIME 形式の複数の部分を含むメッセージです。
--frontier
コンテンツタイプ:テキスト/プレーン 

これはメッセージの本文です。
--frontier
コンテンツタイプ:アプリケーション/オクテットストリームコンテンツ転送エンコーディング: base64 
 

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg 
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --
フロンティア--

各パートは、独自のコンテンツ ヘッダー (0 個以上のContent-ヘッダー フィールド) と本体で構成されます。マルチパート コンテンツはネストできます。Content-Transfer-Encodingマルチパート タイプの は、複数のレベルのデコードによって生じる複雑さを回避するために、常に「7 ビット」、「8 ビット」、または「バイナリ」である必要があります。マルチパート ブロック全体には文字セットがありません。パート ヘッダー内の非 ASCII 文字は、Encoded-Word システムによって処理され、パート本体には、コンテンツ タイプに適切な場合は文字セットを指定できます。

注:

• 最初の境界の前は、MIME 準拠のクライアントによって無視される領域です。この領域は通常、古い非 MIME クライアントのユーザーへのメッセージを配置するために使用されます。
• 本文と衝突しない境界文字列を選択するのは、送信メール クライアント次第です。通常、これは長いランダム文字列を挿入することによって行われます。
• 最後の境界の末尾には 2 つのハイフンが必要です。

MIME 標準では、メッセージの各部分の性質と相互の関係を指定するさまざまなマルチパート メッセージ サブタイプが定義されています。サブタイプは、Content-Typeメッセージ全体のヘッダー フィールドで指定されます。たとえば、ダイジェスト サブタイプを使用するマルチパート MIME メッセージでは、サブタイプはContent-Type"multipart/digest" として設定されます。

RFC では当初、mixed、digest、alternative、parallel の 4 つのサブタイプを定義しました。最低限の準拠性を備えたアプリケーションは、mixed と digest をサポートする必要があります。その他のサブタイプはオプションです。アプリケーションは、認識されないサブタイプを「multipart/mixed」として扱う必要があります。signed や form-data などの追加のサブタイプは、その後、他の RFC で個別に定義されました。

multipart/mixed は、異なるContent-Typeヘッダー フィールドを持つファイルをインラインで (または添付ファイルとして) 送信するために使用されます。画像やその他の読み取りやすいファイルを送信する場合、ほとんどのメール クライアントはそれらをインラインで表示します ( 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によって参照されます。参照の構文は指定されておらず、部分で使用されるエンコードまたはプロトコルによって決まります。

このサブタイプの一般的な使用法の 1 つは、画像を含む Web ページを 1 つのメッセージで送信することです。ルート部分には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 2388 に代わる RFC 7578 で指定されています。例

コンテンツ タイプ multipart/x-mixed-replace は、HTTP 経由のサーバー プッシュとストリーミングをエミュレートするテクノロジの一部として開発されました。

混合置換メッセージのすべての部分は、同じ意味を持ちます。ただし、各部分は、完全に受信されるとすぐに、前の部分を無効 (「置換」) にします。クライアントは、個々の部分が到着するとすぐに処理する必要があり、メッセージ全体が完了するまで待つべきではありません。

もともとNetscapeによって開発されましたが、^{[12]現在でも}Mozilla、Firefox、Safari、Operaでサポートされています。IPカメラではMJPEGストリームのMIMEタイプとしてよく使用されています。 ^[13] 2013年までChromeではメインリソースでサポートされていました（このコンテンツタイプを使用して画像を表示できます）。^[14]

multipart/byterange は、単一メッセージの連続しないバイト範囲を表すために使用され、サーバーが複数のバイト範囲を返すときに HTTP によって使用され、RFC 2616 で定義されています。

• RFC 1426、8ビット MIME トランスポートの SMTP サービス拡張。J . Klensin、N. Freed、M. Rose、E. Stefferud、D. Crocker。1993 年 2 月。
• RFC 1847、MIME のセキュリティ マルチパート: Multipart/Signed および Multipart/Encrypted
• RFC 3156、OpenPGP による MIME セキュリティ
• RFC 2045、MIME パート 1: インターネット メッセージ本文の形式
• RFC 2046、MIME パート 2: メディア タイプ。N. Freed、Nathaniel Borenstein。1996年 11 月。
• RFC 2047、MIME パート 3: 非 ASCII テキストのメッセージ ヘッダー拡張。Keith Moore。1996年 11 月。
• RFC 4288、MIME パート 4: メディア タイプの仕様と登録手順。
• RFC 4289、MIME パート 4: 登録手順。N. Freed、J. Klensin。2005 年 12 月。
• RFC 2049、MIME パート 5: 適合基準と例。N. Freed、N. Borenstein。1996 年 11 月。
• RFC 2183、インターネット メッセージでのプレゼンテーション情報の伝達: Content-Disposition ヘッダー フィールド。Troost、R.、Dorner、S.、および K. Moore。1997 年 8 月。
• RFC 2231、MIME パラメータ値およびエンコードされた単語拡張: 文字セット、言語、および継続。N. Freed、K. Moore。1997 年 11 月。
• RFC 2387、MIME マルチパート/関連コンテンツタイプ
• RFC 1521、インターネット メッセージ本文の形式を指定および記述するためのメカニズム
• RFC 7578、フォームからの値を返す: multipart/form-data

• 8ビット
• バイナリからテキストへのエンコード
• Direct Internet Message Encapsulation (DIME) – 現在は廃止されたMicrosoft が提案したプロトコルで、主にWeb サービスで使用するための合理化された MIME として設計されています。
• メディアタイプ
• オブジェクトのリンクと埋め込み(OLE)
• SMIME
• 簡易メール転送プロトコル(SMTP)
• 添付ファイル付きSOAP
• Unicodeと電子メール
• Uuエンコード
• VPIM

• ヒューズ、L (1998)。インターネット電子メールプロトコル、標準、実装。Artech House Publishers。ISBN 978-0-89006-939-4。
• Johnson, K (2000)。インターネット電子メールプロトコル: 開発者ガイド。Addison -Wesley Professional。ISBN 978-0-201-43288-6。
• Loshin, P (1999)。Eメールの基本標準: 実用的な RFC とプロトコル。John Wiley & Sons。ISBN 978-0-471-34597-8。
• Rhoton, J (1999)。インターネットメールプログラマガイド: SMTP、POP、IMAP、 LDAP。Elsevier。ISBN 978-1-55558-212-8。
• Wood, D (1999)。インターネットメールのプログラミング。O'Reilly。ISBN 978-1-56592-479-6。

• MIME メディア タイプ - Internet Assigned Numbers Authorityによって管理されるコンテンツ タイプとサブタイプのディレクトリのリストで構成されます。
• 文字セットの一覧
• サーバーのMIMEタイプを適切に設定する
• MH と nmh からのマルチパートメッセージのわかりやすい説明
• 「MIME の達人: 2 人のインターネットの達人が電子メールを永遠に変えた方法」。2011 年 2 月 1 日。
• 無料のオンライン PHP MIME チェッカー
• 無料のオンライン MIME メール検証ツール