MIME 標準ヘッダー・フィールド

この情報は MIME の確定仕様では ありません。 場合によっては、MIME パーサーは、標準に照らしてみると厳密には有効ではない文書を許可することがあります。 例えば、MIME-Version ヘッダーが存在しているかどうかにこだわりません。 すべての標準 MIME ヘッダー・フィールドは、MIME 文書にあるとおりに、論理ツリーに書き込まれるにすぎません。 MIME パーサーは、Content-Type ヘッダー・フィールドにのみ特別な注意を払います。

すべての MIME ヘッダーには、MIME-Version ヘッダーの例に示されるように、括弧で囲んだコメントを含められます。

MIME ヘッダー・フィールド

MIME-Version

例:

MIME-version: 1.0 (generated by my-application 1.2)

MIME 文書が RFC 2045 に準拠するためには、このフィールドは値が 1.0 のトップレベル・ヘッダーで必要です。 MIME-Version は個々のバーツに指定してはなりません。

Content-Type

Content-Type は、文書が RFC 2045 に準拠するために必要ではありませんが、MIME パーサーはトップレベルの Content-Type を必要とします。 Content-Type のデフォルトは text/plain です。 Content-Type は、各パーツのデータのタイプを type/subtype と定義します。 MIME パーサーは Content-Type のほとんどの値を受け入れ、それらを論理ツリーに保管します。 ただし、以下の例外があります。

• MIME パーサーは、type = message の Content-Type の値をリジェクトします。
• MIME パーサーは、type = multipart の Content-Type の値が複数パーツ MIME 文書を先導していると想定し、有効な境界パラメーターが含まれていない場合には、そのような値をリジェクトします。 境界パラメーターの値は、複数パーツ・メッセージ内のメッセージ・パーツ間にある区切り文字を定義します。 ネストされた複数パーツ・メッセージでは、ネスト・レベルごとに固有の境界値が必要です。

構文:

Content-Type: type/subtype;parameter

type および subtype は Content-Type を定義し、すべてのオプション・パラメーターはセミコロンで区切ります。

例 1:

Content-Type: multipart/related;type=text/xml

例 1 では、Content-Type が multipart/related として定義され、オプション・パラメーター定義 (type=text/xml) もあります。 この構造が構文的に正しくても、有効な境界パラメーターが存在しないので このメッセージはリジェクトされます。

例 2:

Content-Type: multipart/related;boundary=Boundary;type=text/xml 

例 2 では、構文と意味構造の両面で有効な Content-Type 定義を示しています。 境界値は、オプションで引用符で囲むことができます。 それが MIME 本文に現れる場合、値の前にはシーケンス '--' が付けられ、 結果の値 (この例では --Boundary になります) がメッセージ本体に現れない ようにする必要があります。 メッセージ・データが quoted-printable としてエンコードされる場合、境界に『=_』などのシーケンスを含めてください。このようなシーケンスは、quoted-printable の本体に出現することはできません。

以下の表は、一般的な Content-Type 値を幾つか示しています。 その他の値も許可され、論理ツリーに保管されます。

Content-Type	説明
text/plain	通常、標準的なメールまたはニュース・メッセージに使用されます。 text/richtext も一般的です。
text/xml	通常、SwA (SOAP with Attachments) とともに使用されます。
application/octet-stream	メッセージが不明タイプで、なんらかの種類のデータがバイトとして含まれる場合に使用されます。
application/xml	アプリケーション固有の xml データに使用されます。
x-type	非標準の内容タイプに使用されます。 それは、 文字「x-」で始まる必要があります。
image/jpeg	イメージに使用されます。 image/jpeg と image/gif が、使用される共通のイメージ形式です。
multipart/related	メッセージ内の複数の関連パーツに使用されます。 特に、SwA (SOAP with Attachments) とともに使用されます。
multipart/signed	メッセージ内の複数の関連パーツ (シグニチャーを含む) に使用されます。 特に、S/MIME とともに使用されます。
multipart/mixed	メッセージ内の複数の独立したパーツに使用されます。

Content-Transfer-Encoding

オプション。 多くの内容タイプは 8 ビット文字またはバイナリー・データで表され、XML が含まれる可能性があります。通常、XML は UTF-8 または UTF-16 エンコードを使用します。 このタイプのデータは、一部のトランスポート・プロトコルでは伝送できません。それらは 7 ビットにエンコードされることがあります。

Content-Transfer-Encoding ヘッダー・フィールドは、このタイプのデータを 7 ビット形式にエンコードするために使用されている変換のタイプを示すために使用されます。

WS-I Basic Profile で許可されている値は、以下のものに限られます。

• 7bit - デフォルト
• 8bit
• binary
• base64
• quoted-printable

7bit、8bit、および binary の値はすべて、エンコードが行われなかったことを事実上意味します。 MIME 準拠のメール・ゲートウェイはこの値を使用して、メッセージを処理する方法を制御する可能性があります。 例えば、SMTP を介して値をルーティングして渡す前に、その値を 7bit としてエンコードします。

値 base64 と quoted-printable は、内容がエンコードされていることを意味します。 値 quoted-printable は、オリジナルの 7 ビット以外の文字だけがエンコードされ、人が読むことのできる文書にする意図があることを意味します。 これは、text/plain の Content-Type とともに使用される可能性が最も高い設定です。

Content-ID

オプション。 このフィールドは、パーツにラベルを付け、メッセージの他のパーツから参照できるようにします。 これらのパーツは、一般的にメッセージのパート 0 (先頭) から参照されます。

Content-Description

オプション。 このフィールドは、パーツを記述できるようにします。

MIME エンコード

次のセクションでは base64 と quoted-printable エンコード方式の基本的な ガイドを提供します。MIME エンコード方式の定義的な仕様に 対する RFC 1521 (本トピックの終端でリンクされている) を参照してください。

base64

オリジナル・データは 3 つのオクテットのグループに分けられます。 各グループは 4 つの連結した 6 ビットのグループとして扱われ、各グループは base64 アルファベットの単一桁に変換されます。 base64 アルファベットは、A-Z、a-z、0-9、および / (A=0 および /=63) です。

24 ビットより小さいデータがデータの末尾で使用可能になっている場合、エンコード・データは“=” 文字を使用して埋め込まれます。 エンコード・データの行の最大長は 76 文字で、デコード時に改行 (および上記のアルファベットに含まれないすべてのその他の文字) は無視されます。

例:

入力	出力
Some data encoded in base64.	U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
life of brian	bGlmZSBvZiBicmlhbg==
what	d2hhdA==

quoted-printable

このエンコードは、データの大部分が印刷可能文字で構成されている場合にのみ適しています。 特に、範囲が 33 から 60 および 62 から 126 にある文字は通常、対応する ASCII 文字で表されます。 制御文字および 8 ビット・データは、シーケンス = の後に 16 進数字の対が続いた形で表されます。

標準の ASCII スペース <SP> および水平タブ <HT> は、エンコード行 (ソフト改行を含まない) の末尾に現れているのでなければ、それ自体を表します。エンコード行の末尾にある場合は、相当する 16 進フォーマットを使用する必要があります (それぞれ、=09 と =20)。

データ内の改行は RFC 822 改行シーケンス <CR><LF> で表され、バイナリー・データ・データがエンコードされる場合には、"=0D=0A" とエンコードされる必要があります。

base64 については、エンコード・データの行の最大長は 76 文字です。 エンコード行 (「ソフト」改行) の末尾の ‘=’ 符号は、行が継続することをデコーダーに通知するために使用されます。