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

このセクションは、共通 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/plains です。 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) です。

図 1. base64 データ形式変更8 ビット・データが 6 ビット・エンコード・データに分解される方法

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

例:

入力 出力
Some data encoded in base64. U29tZSBkYXRhIGVuY29kZWQgaW4gYmFzZTY0Lg==
life of brian bGlmZSBvZiBicmlhbg==¥012
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 文字です。 エンコード行 (「ソフト」改行) の末尾の ‘=’ 符号は、行が継続することをデコーダーに通知するために使用されます。

関連概念
メッセージのモデル化
メッセージ・モデル
関連タスク
メッセージ・モデルの開発
メッセージ・モデル・オブジェクトの処理
関連資料
メッセージ・モデルの参照情報
メッセージ・モデル・オブジェクトのプロパティー
追加の MRM ドメイン情報
追加の MIME ドメイン情報
関連情報
RFC 1521: MIME Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
RFC 822: Standard for the format of ARPA Internet text messages
特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック
Copyright IBM Corporation 1999, 2006 最終更新: 08/21/2006
ad30590_