MIME エンコーディングの概要 (オンライン情報と実際の経験から統合)

1. MIME: 多目的インターネットメール拡張

インペリアル カレッジ オブ コンピュータ オンライン ディクショナリ FOLDOC では、MIME を次のように説明しています。「グラフィックス、サウンド、ファックスなどの非テキスト データの送信に使用される、マルチパートのマルチメディア メールおよび WWW ハイパーテキストのエンコード標準です。MIME は RFC1341 で定義されており、MIMENCODE メソッドを使用してバイナリ データを BASE64 と呼ばれる ASCII サブセットの文字の組み合わせに変換します。」

インターネット上には、MIME について具体的に議論するニュースグループ comp.mail.mime があります。このニュースグループの FAQ は次の URL で参照できます。

http://www.cis.ohio-state.edu/hypertext/faq/usenet/mail/mime-faq/mime0/faq.html

MIMENCODE は、最初は MMENCODE と呼ばれていました。UUENCODE は、一部のメール ゲートウェイ (特に ASCII および EBCDIC コードを変換するもの) で送信障壁を引き起こす一部の文字を使用するため、MIMENCODE は UUENCODE の代替として提案されました。(一部のソフトウェアはすべての UUENCODE アルゴリズムを正しくデコードできず、メールの読み取りが困難になります。) そのため、MIME は UUENCODE の代替として設計されましたが、結果としてこれらのプロトコルは共存しています。

MIME が導入される前は、RFC 822 を使用して送信できるのは基本的な ASCII テキスト情報のみでした。電子メールの内容にバイナリ ファイル、サウンド、アニメーションなどを含めることは非常に困難でした。

MIME は、複数の異なるエンコードされたファイルを電子メールに添付する方法を提供し、元の情報形式の欠点を補います。実際、MIME は単なる電子メールのエンコードではなく、現在では HTTP プロトコル標準の一部となっています。

2. MIMEエンコーディングの概要

電子メールをエンコードする元々の理由は、インターネット上の多くのゲートウェイが、中国語の文字などの 8 ビットでコード化された文字を正しく送信できなかったためです。エンコードの原理は、8 ビットのコンテンツを 7 ビット形式に変換して正しく送信できるようにし、受信側で受信した後に 8 ビットのコンテンツに復元することです。

MIMEプロトコル以前は、電子メールのエンコードにはUUENCODEなどのエンコード方式が使用されていました。しかし、MIMEプロトコルのアルゴリズムはシンプルで拡張性も高いため、現在では電子メールのエンコード方式の主流となっています。8ビット文字の送信だけでなく、電子メールの添付ファイル内の画像、音声、その他の情報などのバイナリファイルの送信にも使用され、多くのMIMEベースのアプリケーションを拡張してきました。エンコードに関しては、MIME では Base64 と QP (Quote-Printable) の 2 つのエンコード方式が定義されています。

1. Base64エンコード

Base64 は汎用的な方式であり、その原理は非常に単純で、3 バイトのデータを 4 バイトで表現するものです。この 4 バイトのうち、実際に使用されるのは最初の 6 ビットだけなので、7 ビットの文字しか送信できないという問題はありません。 Base64 の略語は通常「B」です。

Base64 は、入力文字列またはデータの一部を、64 文字 {'A'-'Z'、'a'-'z'、'0'-'9'、'+'、'/'} のみを含む文字列にエンコードし、パディングには '=' を使用します。

エンコード方法は、入力データ ストリームの 6 ビットを毎回取得し、この 6 ビットの値 (0 ～ 63) をインデックスとして使用してテーブルを検索し、対応する文字を出力します。

この方法では、3 バイトごとに 4 文字 (3×8 → 4×6) としてエンコードされ、4 文字未満の文字は '=' で埋められます。

場合によっては、「=?charset?B?xxxxxxxx?=」は、xxxxxxxx が Base64 でエンコードされ、元のテキストの文字セットが charset であることを示すために使用されます。段落本文内で直接エンコードし、適切なタイミングで行を折り返します。MIME では、1 行あたり最大 76 文字を推奨しています。

Base64 アルゴリズムは非常にシンプルです。文字ストリームを 24 ビット バッファに順番に格納し、不足している文字をゼロで埋めます。

次に、バッファは上位ビットを先頭にして 4 つの部分に切り捨てられ、各部分は 6 ビットとなり、64 文字で再表現されます。入力が 1 バイトまたは 2 バイトのみで構成されている場合、出力には等号 "=" が埋め込まれます。これにより、追加情報によってエンコードが乱雑になるのを防ぐことができます。

Base64エンコードの方法
Base64はUS-ASCIIサブセットから65文字を使用し、各文字は6ビットで表されます。
テキスト文字列の場合、エンコード処理は次のようになります。たとえば、「男性」の場合:
まず US-ASCII 値に変換します。

「m」10進数109
「e」10進数101
「n」10進数110
バイナリ：
01101101 メートル
01100101 電子
01101110 電話番号

3つの8ビットの数字をつなげると24ビットになる
011011010110010101101110

次にそれを4つの6ビットに分割します
011011 010110 010101 101110

4つの値が得られ、小数値は
27 22 21 46

対応するBase64文字は次のとおりです: b WV u
エンコードは常に 3 文字に基づいて行われるため、結果として 4 つの Base64 文字が生成されます。

データが 2 文字だけの場合は、特殊文字「=」を使用して Base64 の 4 文字を完成させます。
たとえば、「me」をエンコードすると
01101101 01100101
0110110101100101
011011 010110 0101
111111 (AND、6桁になる)
011011 010110 010100
わ
b WU = ("=" で 4 文字を構成)
つまり、「bWU=」は「me」の Base64 値です。

コード「m」のように2文字のデータだけの場合
01101101
011011 01
111111
011011 010000
b Q = =
したがって、「bQ==」は「m」の Base64 値です。

2. QPコーディング

もう 1 つの方法は、QP (Quote-Printable) 方式で、通常は「Q」方式と略されます。その原理は、8 ビット文字を 2 つの 16 進数値で表し、その前に「=」を追加することです。したがって、QP エンコード後のファイルは通常、次のようになります: =B3=C2=BF=A1=C7=E5=A3= AC=C4=FA=BA=C3=A3=A1。

Quoted-printable は入力文字列またはバイト範囲をエンコードします。エンコードする必要のない文字がある場合は、そのまま出力されます。エンコードが必要な場合は、最初に「=」を出力し、その後に 2 文字で表される 16 進バイト値を出力します。場合によっては、「=?charset?Q?xxxxxxxx?=」は、xxxxxxxx が quoted-printable エンコーディングであり、元のテキストの文字セットが charset であることを示すために使用されます。段落本文では、直接エンコードし、適切なタイミングで行を折り返し、改行の前に追加の「=」を出力します。

3. MIMEヘッダー情報

メールヘッダー

電子メールのヘッダーには、RFC 822 から継承されたドメイン名が多数あり、MIME によっていくつか追加されます。一般的な標準ドメイン名とその意味は次のとおりです。

ドメイン名の意味を追加

伝送経路のすべてのレベルで受信メールサーバー

リターンパス返信アドレス ターゲットメールサーバー

Delivered-To 送信元アドレス 対象メールサーバー

Reply-To メール作成者の返信アドレス

送信者のアドレスは、電子メールの作成者です。

受信者アドレス メールの作成者

Ccアドレス メールの作成者

Bcc ブラインドコピーアドレスの作成者

日付 メッセージが作成された日時

件名 メールの作成者

メッセージID メッセージID メールの作成者

MIME バージョン メッセージ作成者の MIME バージョン

コンテンツタイプ メール作成者のコンテンツの種類

Content-Transfer-Encoding コンテンツ転送エンコーディング方式 電子メールの作成者

非標準のカスタム ドメイン名はすべて X- で始まります (X-Mailer、X-MSMail-Priority など)。通常、その意味は、電子メールを受信および送信するプログラムが同じである場合にのみ理解されます。

セクションヘッダー

セグメント ヘッダーには、おおよそ次のフィールドがあります。

ドメイン名の意味

Content-Type 本文のタイプ

Content-Transfer-Encoding セグメント本体の転送エンコード方式

コンテンツ配置: 段落の本文をどのように配置するか

コンテンツID セグメントのID

コンテンツの場所 本文の場所（パス）

Content-Base 段落のベース位置

一部のフィールドには値に加えてパラメータがあります。値とパラメータ、パラメータとパラメータは「;」で区切られます。パラメータ名とパラメータ値は「=」で区切られます。

1.MIMEバージョン

使用される MIME のバージョン番号を示します (通常は 1.0)。

のように：

MIME バージョン: 1.0

2. コンテンツタイプ

Content-Type は本文のタイプを定義します。実際には、この識別子を使用して本文に含まれるファイルの種類を判断します。たとえば、text/plain はフォーマットされていないテキスト、text/html は HTML ドキュメント、image/gif は gif 形式の画像などを意味します。 Content-Type は「メイン タイプ/サブタイプ」の形式です。主なタイプは、テキスト、画像、オーディオ、ビデオ、アプリケーション、マルチパート、メッセージなどであり、それぞれテキスト、画像、オーディオ、ビデオ、アプリケーション、セグメント、メッセージなどを表します。各メイン タイプには複数のサブタイプが存在する場合があります。たとえば、テキスト タイプにはプレーン、html、xml、css などのサブタイプが含まれます。 X- で始まるメイン タイプとサブタイプは、IANA に正式に登録されていないが、ほとんどがすでに一般的に使用されているカスタム タイプも示します。たとえば、application/x-zip-compressed は ZIP ファイル タイプです。 Windows では、マルチパートを除くほとんどの既知のコンテンツ タイプがレジストリの「HKEY_CLASSES_ROOT\MIME\Database\Content Type」にリストされています。

RFC には、パラメータの形式に関する追加の規定が多数あります。複数のパラメータを許可するものもあります。一般的なものは次のとおりです。

メイン型パラメータ名の意味

テキスト文字セット 文字セット

画像名

アプリケーション名

複数部分境界

マルチパートタイプ

電子メールでよく使用される複合タイプ: マルチパート。

マルチパート タイプは、テキストが複数の部分で構成されていることを示します。次のサブタイプは、これらの部分間の関係を記述します。

電子メールで使用される 3 つのタイプは次のとおりです。

(1).multipart/alternative: メッセージ本文が2つの部分で構成されており、どちらかを選択できることを示します。主な機能は、エッセイにテキスト形式と HTML 形式の両方がある場合に、2 つのテキストのうち 1 つを選択して表示できることです。HTML 形式をサポートする電子メール クライアント ソフトウェアでは、通常 HTML テキストが表示され、サポートしていない電子メール クライアント ソフトウェアではテキスト テキストが表示されます。

(2).multipart/mixed: 本文と添付ファイルの関係を示し、文書の複数の部分が混在していることを示します。電子メールの MIME タイプが multipart/mixed の場合、電子メールに添付ファイルがあることを意味します。

(3).multipart/related: 文書の複数の部分が関連していることを示します。通常、HTMLテキストとそれに関連する画像を記述するために使用されます。

マルチパートタイプは MIME 電子メールの本質です。電子メールの本文は複数のセクションに分かれており、各セクションはセクション ヘッダーとセクション本文の 2 つの部分で構成され、これら 2 つの部分も空白行で区切られています。それらの間の階層関係は、次の図に示すようにまとめることができます。

+------------------------- multipart/mixed ----------------------------+

| |

| +------------------multipart/related ------------------+ |

| | | |

| | +----- multipart/alternative ------+ +----------+ | +------+ |

| | | | | 埋め込みリソース| | | 添付ファイル| |

| | | +------------+ +-------------+ | +-----------+ | +-------+ |

| | | | プレーンテキスト本文| | ハイパーテキスト本文| | | |

| | | +------------+ +-------------+ | +-----------+ | +-------+ |

| | | | | 埋め込みリソース| | | 添付ファイル| |

| | +----------------------------------+ +----------+ | +------+ |

| | | |

| +------------------------------------------------------+ |

| |

+----------------------------------------------------------------------+

電子メールに添付ファイルを追加する場合は、multipart/mixed セグメントを定義する必要があり、埋め込みリソースがある場合は、少なくとも multipart/related セグメントを定義する必要があり、プレーン テキストとハイパーテキストが共存する場合は、少なくとも multipart/alternative セグメントを定義する必要があることがわかります。 「少なくとも」とは何ですか?たとえば、プレーン テキストとハイパーテキストの本文のみがある場合は、電子メール ヘッダーのタイプを拡張して、multipart/related または multipart/mixed として定義できます。

マルチパート タイプの共通の特徴は、セグメント ヘッダーに「境界」パラメータ文字列が指定され、セグメント本体の各サブセグメントがこの文字列によって区切られることです。すべてのサブセグメントは「--」+ 境界線で始まり、親セグメントは「--」+ 境界 + 「--」線で終わります。段落も空行で区切られます。マルチパート メッセージ本文の場合、メッセージ本文の先頭 (最初の "--" + 境界線の前) に、コメントに相当する追加のテキスト行がいくつかあることがあります。これはデコード時に無視する必要があります。段落間に追加のテキスト行が存在する場合もありますが、これは表示されません。

これらの複合タイプはネストできます。たとえば、電子メールに添付ファイルと、HTML 形式とテキスト形式の本文がある場合、電子メールの構造は次のようになります。

コンテンツタイプ: multipart/mixed

パート1:

コンテンツタイプ: multipart/alternative:

文章：

HTML形式のテキスト

パート2:

付録

メールターミネータ;

複合型は複数の部分から構成されるため、複数の部分を区切るための区切り文字が必要です。これは、上記のメールソースファイルの境界が記述しているものです。Contect 型 :multipart/* の各コンテンツには、複数の部分間の区切りを示すこのような記述があります。

MIME/BASE64 でエンコードされた電子メールのソース コードを表示すると、通常は「これは MIME 形式のマルチパート メッセージです」のような文が含まれます。また、Netscape、MS Mail、Eudora などのほとんどの電子メール プログラムでデコードすることもできます。これらのプログラムは、電子メールの本文を正しく識別し、MIME/BASE64 でエンコードされた部分を正しいテキストまたは添付されたバイナリ ファイルに復元できます。

3. コンテンツ転送エンコーディング

ドキュメントのこの部分がどのようにエンコードされているかを示します。この説明を認識することによってのみ、正しいデコード方法を使用してデコードすることができます。

Content-Transfer-Encoding には、Base64、Quoted-printable、7 ビット、8 ビット、バイナリなど、いくつかの種類があります。

このうち、7bit がデフォルトのエンコード方式です。電子メールのソース コードは、もともとすべて印刷可能な ASCII コードの形式になるように設計されていました。

非 ASCII テキストまたはデータは、必要な形式にエンコードする必要があります。

Base64、Quoted-Printable は、英語圏以外の国で最も広く使用されているエンコード方式です。

バイナリ方式は単なる象徴的なものであり、実用的な価値はありません。

4.境界

この区切り文字は、テキストに表示できない古い文字の組み合わせです。ドキュメントでは、「--」とこの境界を使用してセクションの開始を示します。ドキュメントの末尾では、「--」と境界、そして最後に「--」を使用してドキュメントの終了を示します。複合型はネストできるため、電子メール内に複数の境界が存在する場合があります。