5. Content-Typeヘッダーフィールド (Content-Type Header Field)
Content-Typeフィールドの目的は、受信ユーザエージェント (User Agent) がユーザにデータを提示するための適切なエージェントまたはメカニズムを選択できるように、または適切な方法でデータを処理できるように、本文に含まれるデータを十分に記述することです。このフィールドの値はメディアタイプ (Media Type) と呼ばれます。
歴史的注記 (HISTORICAL NOTE): Content-Typeヘッダーフィールドは、最初にRFC 1049で定義されました。RFC 1049は、よりシンプルでパワフルではない構文を使用していましたが、ここで提供されるメカニズムと大部分互換性があります。
Content-Typeヘッダーフィールドは、メディアタイプとサブタイプの識別子を指定し、特定のメディアタイプに必要となる可能性のある補助情報を提供することによって、エンティティの本文内のデータの性質を指定します。メディアタイプとサブタイプ名の後、ヘッダーフィールドの残りは、attribute=value表記で指定されたパラメータのセットです。パラメータの順序は重要ではありません。
一般に、トップレベルのメディアタイプは、データの一般的なタイプを宣言するために使用され、サブタイプは、そのタイプのデータの特定の形式を指定します。したがって、「image/xyz」のメディアタイプは、ユーザエージェントが特定の画像形式「xyz」の知識を持っていない場合でも、データが画像であることをユーザエージェントに伝えるのに十分です。このような情報は、たとえば、認識されないサブタイプの生データをユーザに表示するかどうかを決定するために使用できます。このようなアクションは、認識されないテキストのサブタイプには合理的かもしれませんが、認識されない画像やオーディオのサブタイプには合理的ではありません。このため、テキスト、画像、オーディオ、およびビデオの登録されたサブタイプには、実際に異なるタイプの埋め込み情報を含めるべきではありません (SHOULD NOT)。このような複合形式は、「multipart」または「application」タイプを使用して表現されるべきです (SHOULD)。
パラメータは、メディアサブタイプの修飾子であり、そのため、コンテンツの性質を根本的に変更するものではありません。意味のあるパラメータのセットは、メディアタイプとサブタイプに依存します。ほとんどのパラメータは、単一の特定のサブタイプに関連付けられています。ただし、特定のトップレベルメディアタイプは、そのタイプの任意のサブタイプに適用可能なパラメータを定義する場合があります。パラメータは、それらを定義するコンテンツタイプまたはサブタイプによって必須である場合もあれば、オプションである場合もあります。MIME実装は、認識しない名前のパラメータを無視しなければなりません (MUST)。
たとえば、「charset」パラメータは「text」の任意のサブタイプに適用可能ですが、「boundary」パラメータは「multipart」メディアタイプの任意のサブタイプに必須です。
すべてのメディアタイプに適用されるグローバルに意味のあるパラメータはありません (NO)。MIMEでグローバルと考えられるメカニズムは、追加のContent-*ヘッダーフィールドを定義することによって、MIMEモデルで最もよく対処されます。
RFC 2046では、7つのトップレベルメディアタイプの初期セットが定義されています。これらのうち5つは、MIME処理に関しては内容が不透明な離散タイプ (Discrete Types) です。残りの2つは、追加のMIME処理を必要とする内容を持つ複合タイプ (Composite Types) です。
このトップレベルメディアタイプのセットは、実質的に完全であることを意図しています。サポートされるタイプのより大きなセットへの追加は、一般に、これらの初期タイプの新しいサブタイプの作成によって達成できることが期待されます。将来、より多くのトップレベルタイプは、この標準への標準化過程の拡張によってのみ定義される可能性があります。何らかの理由で別のトップレベルタイプを使用する場合は、その非標準ステータスを示し、将来の公式名との潜在的な競合を避けるために、「X-」で始まる名前を付けなければなりません (MUST)。
5.1. Content-Typeヘッダーフィールドの構文 (Syntax of the Content-Type Header Field)
RFC 822の拡張BNF表記では、Content-Typeヘッダーフィールド値は次のように定義されます:
content := "Content-Type" ":" type "/" subtype
*(";" parameter)
; Matching of media type and subtype
; is ALWAYS case-insensitive.
type := discrete-type / composite-type
discrete-type := "text" / "image" / "audio" / "video" /
"application" / extension-token
composite-type := "message" / "multipart" / extension-token
extension-token := ietf-token / x-token
ietf-token := <An extension token defined by a
standards-track RFC and registered
with IANA.>
x-token := <The two characters "X-" or "x-" followed, with
no intervening white space, by any token>
subtype := extension-token / iana-token
iana-token := <A publicly-defined extension token. Tokens
of this form must be registered with IANA
as specified in RFC 2048.>
parameter := attribute "=" value
attribute := token
; Matching of attributes
; is ALWAYS case-insensitive.
value := token / quoted-string
token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
or tspecials>
tspecials := "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
; Must be in quoted-string,
; to use within parameter values
5.2. Content-Typeのデフォルト (Content-Type Defaults)
Content-Typeヘッダーフィールドがエンティティに存在しない場合、デフォルトのContent-Typeはコンテキストに依存します:
- MIMEメッセージのトップレベルでは、デフォルトは
text/plain; charset=us-asciiです - マルチパートエンティティの本文パート内では、デフォルトのContent-Typeは
text/plain; charset=us-asciiです - "message/rfc822" エンティティ内では、デフォルトのContent-Typeは
text/plain; charset=us-asciiです
主要ポイント:
- Content-Type形式:
type/subtype; parameter=value - タイプとサブタイプは大文字小文字を区別しません
- パラメータ名は大文字小文字を区別しませんが、値は通常区別します
- デフォルト値:
text/plain; charset=us-ascii
7つのトップレベルメディアタイプ:
離散タイプ (Discrete Types)
- text: テキストデータ
- image: 画像データ
- audio: オーディオデータ
- video: ビデオデータ
- application: アプリケーションデータ
複合タイプ (Composite Types)
- message: カプセル化されたメッセージ
- multipart: 複数のパート