MIME

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

MIME標準は、RFC 2045RFC 2046RFC 2047RFC 4288RFC 4289RFC2049の一連のコメント要求で指定されています。SMTP電子メールとの統合は、 RFC1521および RFC1522で指定されています。

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

歴史

MIMEは、カーネギーメロン大学(CMU)で開発されたAndrewProjectの一部であるAndrewMessaging Systemから、Andrew固有のデータ形式に代わるクロスプラットフォームとして開発されました。[2]

MIMEヘッダーフィールド

MIME-バージョン

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

MIME-バージョン:1.0

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

コンテンツタイプ

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

コンテンツタイプ:テキスト/プレーン

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

  • text / plainを使用した単純なテキストメッセージ(「Content-Type:」のデフォルト値)
  • テキストと添付ファイル(マルチパート/テキスト/プレーンパーツおよびその他の非テキストパーツとの混合) 。添付ファイルを含むMIMEメッセージは、通常、フィールド「Content-Disposition」でファイルの元の名前を示します。そのため、ファイルのタイプは、MIMEコンテンツタイプと(通常はOS固有の)ファイル名拡張子の両方で示されます。
  • 元のメッセージを添付して返信する(マルチパート/テキスト/プレーン部分と元のメッセージをメッセージ/ rfc822部分として混合
  • プレーンテキストとHTMLなどの別の形式の両方で送信されるメッセージなどの代替コンテンツテキスト/プレーンおよびテキスト/ html形式の同じコンテンツを持つマルチパート/代替
  • 画像、音声、動画、アプリケーション(たとえば、image / jpegaudio / mp3video / mp4application / mswordなど)
  • 他の多くのメッセージ構成

コンテンツ-処理

元のMIME仕様は、メールメッセージの構造のみを記述していました。彼らはプレゼンテーションスタイルの問題に取り組んでいませんでした。表示スタイルを指定するために、RFC2183でcontent-dispositionヘッダーフィールドが追加されました。MIME部分には次のものを含めることができます。

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

表示スタイルに加えて、フィールドContent-Dispositionは、ファイルの名前、作成日、および変更日を指定するためのパラメーターも提供します。これらは、読者のメールユーザーエージェントが添付ファイルを保存するために使用できます。

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

コンテンツ-処分:添付ファイル; filename = Genome.jpeg;
  modify-date = "Wed、12 Feb 1997 16:29:51 -0500";

ファイル名は、RFC2231で定義されているようにエンコードできます。

2010年の時点で、メールユーザーエージェントの大多数はこの処方箋に完全には従いませんでした。広く使用されているMozillaThunderbirdメールクライアントは、メッセージのコンテンツ処理フィールドを無視し、独立したアルゴリズムを使用して、自動的に表示するMIME部分を選択します。バージョン3より前のThunderbirdは、すべてのMIME部分のインラインコンテンツ処理を使用して、新しく作成されたメッセージも送信します。ほとんどのユーザーは、コンテンツの配置を添付ファイルに設定する方法を認識していません。[4]多くのメールユーザーエージェントは、ファイル名の代わりにcontent-typeヘッダーのnameパラメーターにファイル名を含むメッセージも送信しますヘッダーフィールドContent-Dispositionのパラメータ。ファイル名はパラメータfilenameで指定するか、パラメータfilenamenameの両方で指定する必要があるため、この方法はお勧めしません[5]

HTTPでは、応答ヘッダーフィールドContent-Disposition:attachmentは通常、クライアントへのヒントとして使用され、応答本文をダウンロード可能なファイルとして表示します。通常、このような応答を受信すると、Webブラウザは、ブラウザウィンドウにページとして表示するのではなく、コンテンツをファイルとして保存するようにユーザーに促します。ファイル名はデフォルトのファイル名を示します。

Content-Transfer-Encoding

1992年6月、MIME(RFC 1341、RFC 2045で廃止されたため)は、ASCIIテキスト形式以外の形式でバイナリデータを表現するための一連のメソッドを定義しました。content-transfer-encoding: MIMEヘッダーフィールドには両面の意味があります

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

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

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

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

エンコードされたWord

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

形式は次のとおりです。「エンコードされたテキストをエンコードする=?文字セット」。 ???=

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

Q-encodingとquoted-printableの違い

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

例えば、

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

「件名:¡ホラ、セニョール!」と解釈されます。

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

マルチパートメッセージ

MIMEマルチパートメッセージのヘッダーフィールドに境界が含まれています。この境界は、どの部分にも発生してはなりませんが、次のように、部分の間に配置され、メッセージの本文の最初と最後に配置されます。 Content-Type:

MIME-バージョン:1.0
コンテンツタイプ:マルチパート/混合; 境界=フロンティア  

これは、MIME形式の複数の部分からなるメッセージです。
-フロンティア
コンテンツ-タイプ:テキスト/プレーン 

これがメッセージの本文です。
-フロンティア
コンテンツ-タイプ:アプリケーション/オクテット-ストリーム 
Content-Transfer-Encoding:base64 

PGh0bWw + CiAgPGhlYWQ + CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA + VGhpcyBpcyB0aGUg 
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A + 
CiAgPC9ib2R5Pgo8

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

ノート:

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

マルチパートサブタイプ

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

RFCは当初、混合、ダイジェスト、代替、並列の4つのサブタイプを定義していました。最低限準拠しているアプリケーションは、混合とダイジェストをサポートする必要があります。他のサブタイプはオプションです。アプリケーションは、認識されないサブタイプを「マルチパート/混合」として扱う必要があります。その後、signedやform-dataなどの追加のサブタイプは、他のRFCで個別に定義されています。

混合

Content-Typemultipart / mixedは、異なるヘッダーフィールドを持つファイルをインラインで(または添付ファイルとして)送信するために使用されます。写真やその他の読みやすいファイルを送信する場合、ほとんどのメールクライアントはそれらをインラインで表示します( Content-Disposition:添付ファイルで明示的に指定されていない限り、添付ファイルとして提供されます)。各部分のデフォルトのコンテンツタイプは「text / plain」です。

タイプはRFC2046で定義されています。[6]

ダイジェスト

multipart / digestは、複数のテキストメッセージを送信する簡単な方法です。各部分のデフォルトのコンテンツタイプは「message / rfc822」です。

MIMEタイプはRFC2046で定義されています。[7]

代替

multipart / Alternativeサブタイプは、各パートが同じ(または類似の)コンテンツの「代替」バージョンであり、それぞれが「Content-Type」ヘッダーで示される異なる形式であることを示します。部品の順序は重要です。RFC1341は、次のように述べています。一般に、マルチパート/代替エンティティを構成するユーザーエージェントは、本体パーツを優先度の高い順に配置する必要があります。つまり、優先フォーマットが最後になります。[8]

その後、システムは処理可能な「最良の」表現を選択できます。一般に、これはシステムが理解できる最後の部分になりますが、他の要因がこれに影響を与える可能性があります。

クライアントがプレーンテキストバージョンよりも忠実度の低いバージョンを送信する可能性は低いため、この構造ではプレーンテキストバージョン(存在する場合)が最初に配置されます。これにより、マルチパートメッセージを理解していないクライアントのユーザーの生活が楽になります。

最も一般的には、multipart / Alternativeは、プレーンテキスト(text / plain)とHTML(text / html)の2つの部分からなる電子メールに使用されますプレーンテキスト部分は下位互換性を提供し、HTML部分はフォーマットとハイパーリンクの使用を許可します。ほとんどの電子メールクライアントは、HTMLよりもプレーンテキストを優先するユーザーオプションを提供しています。これは、ローカル要因が、表示するメッセージの「最良の」部分をアプリケーションが選択する方法にどのように影響するかを示す例です。

メッセージの各部分が同じコンテンツを表すことが意図されていますが、標準では、これを強制する必要はありません。かつて、スパム対策フィルターはメッセージのテキスト/プレーン部分のみを検査していました[9]。これは、テキスト/ html部分よりも解析が容易だからです。しかし、スパマーは最終的にこれを利用して、無害に見えるテキスト/プレーン部分を含むメッセージを作成し、テキスト/ html部分に広告を掲載しました。スパム対策ソフトウェアは最終的にこのトリックに追いつき、マルチパート/代替メッセージ内の非常に異なるテキストでメッセージにペナルティを科しました。[9]

タイプはRFC2046で定義されています。[10]

関連

multipart / relatedは、各メッセージ部分が集合体全体のコンポーネントであることを示すために使用されます。これは、いくつかの相互に関連するコンポーネントで構成される複合オブジェクト用です。構成パーツを個別に表示することによって適切な表示を実現することはできません。メッセージは、他の部分をインラインで参照するルート部分(デフォルトでは最初の部分)で構成され、ルート部分は他の部分を参照する場合があります。メッセージ部分は通常、Content-IDによって参照されます。参照の構文は指定されておらず、代わりに、パーツで使用されているエンコーディングまたはプロトコルによって決定されます。

このサブタイプの一般的な使用法の1つは、画像を含むWebページを1つのメッセージで送信することです。ルート部分にはHTMLドキュメントが含まれ、画像タグを使用して後の部分に保存されている画像を参照します。

タイプはRFC2387で定義されています。

レポート

multipart / reportは、メールサーバーが読み取るためにフォーマットされたデータを含むメッセージタイプです。これは、テキスト/プレーン(または読みやすい他のコンテンツ/タイプ)と、メールサーバーが読み取るためにフォーマットされたデータを含むメッセージ/配信ステータスに分割されます。

タイプはRFC6522で定義されています。

署名

マルチパート/署名付きメッセージは、メッセージにデジタル署名を添付するために使用されます。ボディパーツとシグネチャーパーツの2つのボディパーツがあります。mimeフィールドを含むボディ部分全体が、署名部分の作成に使用されます。「application / pgp-signature」(RFC 3156)や「application / pkcs7-signature」(S / MIME)など、多くの署名タイプが可能です。

タイプはRFC1847で定義されています。[11]

暗号化

マルチパート/暗号化されたメッセージには2つのパートがあります。最初の部分には、アプリケーション/オクテットストリームの2番目の部分を復号化するために必要な制御情報があります。署名されたメッセージと同様に、制御部分の個別のコンテンツタイプによって識別されるさまざまな実装があります。最も一般的なタイプは、「application / pgp-encrypted」(RFC 3156)および「application / pkcs7-mime」(S / MIME)です。

RFC1847で定義されているMIMEタイプ。[12]

フォームデータ

MIMEタイプmultipart / form-dataは、フォームを介して送信された値を表すために使用されます。元々はHTML4.0の一部として定義されていましたが、 HTTPを使用してファイルを送信するために最も一般的に使用されますこれはRFC7578で指定されており、RFC2388に取って代わります。

x-mixed-replace

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

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

もともとはNetscapeによって開発されましたが[13] 、 MozillaFirefoxSafariOperaで引き続きサポートされています。これは、 MJPEGストリームのMIMEタイプとしてIPカメラで一般的に使用されます。[14] 2013年までメインリソースとしてChromeでサポートされていました(画像はこのコンテンツタイプを使用して引き続き表示できます)。[15]

バイト範囲

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

RFCドキュメント

  • RFC  1426、8ビット用のSMTPサービス拡張-MIMEトランスポートJ.クレンシンN。フリードM。ローズE。ステフェルド、D。クロッカー。1993年2月。
  • RFC  1847MIMEのセキュリティマルチパート:マルチパート/署名付きおよびマルチパート/暗号化
  • RFC  3156OpenPGPによるMIMEセキュリティ
  • RFC  2045MIMEパート1:インターネットメッセージ本文の形式
  • RFC  2046MIMEパート2:メディアタイプN.フリード、ナサニエルボレンシュタイン1996年11月。
  • RFC  2047MIMEパート3:非ASCIIテキストのメッセージヘッダー拡張キース・ムーア1996年11月。
  • RFC  4288MIMEパート4:メディアタイプの仕様と登録手順
  • RFC  4289MIMEパート4:登録手順N.フリード、J。クレンシン。2005年12月。
  • RFC  2049MIMEパート5:適合基準と例N.フリード、N。ボレンシュタイン。1996年11月。
  • RFC  2183インターネットメッセージでのプレゼンテーション情報の伝達:Content-DispositionヘッダーフィールドTroost、R.、Dorner、S.、K。Moore 1997年8月。
  • RFC  2231MIMEパラメータ値およびエンコードされたWord拡張機能:文字セット、言語、および継続N.フリード、K。ムーア。1997年11月。
  • RFC  2387MIMEマルチパート/関連コンテンツタイプ
  • RFC  1521インターネットメッセージ本文の形式を指定および記述するためのメカニズム

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ Terry Gliedt(1996年5月27日)。「メッセージ-マルチメディアメーラー」
  3. ^ 「MIMEの歴史」networkworld.com。2011年2月。
  4. ^ Giles Turnbull(2005-12-14)。「Thunderbirdに送信添付ファイルを適切に処理させる」O'Reilly macdevcenter 2010年4月1日取得
  5. ^ ネッド・フリード(2008-06-22)。「名前とファイル名のパラメータ」2017年4月3日取得
  6. ^ RFC 2046、セクション5.1.3
  7. ^ RFC 2046、セクション5.1.5
  8. ^ 「RFC1341セクション7.2マルチパートコンテンツタイプ」2014年7月15日取得
  9. ^ a b 「スパム対策フィルタリング技術の概要」(PDF)2017年1月。S2CID2125969522020-02-20にオリジナル(PDF)からアーカイブされました2020年2月20日取得   {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  10. ^ RFC 2046、セクション5.1.4
  11. ^ RFC 1847、セクション2.1
  12. ^ RFC 1847、セクション2.2
  13. ^ 「動的ドキュメントの調査」Netscape。1998年12月3日にオリジナルからアーカイブされまし
  14. ^ 「WebCamモニターのセットアップドキュメント」DeskShare。2010年5月11日にオリジナルからアーカイブされました。
  15. ^ "249132-multipart / x-mixedのサポートを削除-メインリソースを置き換えます-クロム-モノレール"bugs.chromium.org 2017年10月10日取得

さらに読む

  • ヒューズ、L(1998)。インターネット電子メールプロトコル、標準および実装アーテックハウス出版社。ISBN 978-0-89006-939-4
  • ジョンソン、K(2000)。インターネット電子メールプロトコル:開発者ガイドアディソン-ウェスリープロフェッショナル。ISBN 978-0-201-43288-6
  • Loshin、P(1999)。重要な電子メール標準:RFCとプロトコルが実用化されました。ジョン・ワイリー&サンズ。ISBN 978-0-471-34597-8
  • Rhoton、J(1999)。インターネットメールのプログラマーズガイド:SMTP、POP、IMAP、およびLDAPエルゼビア。ISBN 978-1-55558-212-8
  • ウッド、D(1999)。インターネットメールのプログラミングオライリー。ISBN 978-1-56592-479-6

外部リンク