5. Content-Type 头字段

Content-Type 字段的目的是足够完整地描述正文中包含的数据, 使接收用户代理可以选择适当的代理或机制向用户呈现数据, 或以其他适当方式处理数据. 该字段中的值称为 media type (媒体类型).

历史说明: Content-Type 头字段最早在 RFC 1049 中定义. RFC 1049 使用的语法更简单且能力较弱, 但与这里给出的机制大体兼容.

Content-Type 头字段通过给出 media type 和 subtype 标识符, 并提供某些 media types 可能需要的辅助信息, 来规定实体正文中数据的性质. 在 media type 和 subtype 名称之后, 该头字段的其余部分只是一组参数, 用 attribute=value 表示法指定. 参数顺序没有意义.

一般而言, 顶层 media type 用于声明数据的一般类型, 而 subtype 指定该数据类型的具体格式. 因此, "image/xyz" 这样的 media type 足以告诉用户代理该数据是一幅图像, 即使用户代理不了解具体图像格式 "xyz". 例如, 这类信息可用于决定是否向用户显示未识别 subtype 的原始数据: 对于 text 的未识别 subtype, 这种行为可能合理; 但对于 image 或 audio 的未识别 subtype 则不合理. 因此, text, image, audio 和 video 的已注册 subtype 不应包含实际属于其他类型的嵌入信息. 这类复合格式应使用 "multipart" 或 "application" 类型表示.

参数是 media subtype 的修饰符, 因而不会从根本上改变内容性质. 有意义的参数集合取决于 media type 和 subtype. 大多数参数与单个具体 subtype 关联. 但是, 给定顶层 media type 可以定义适用于该类型任意 subtype 的参数. 参数可以由定义它们的内容类型或 subtype 要求, 也可以是可选的. MIME 实现 must (必须) 忽略名称不认识的任何参数.

例如, "charset" 参数适用于 "text" 的任何 subtype, 而 "boundary" 参数对于 "multipart" media type 的任何 subtype 都是必需的.

不存在适用于所有 media types 且具有全局意义的参数. 在 MIME 中可能被认为是全局性的机制, 最好在 MIME 模型中通过定义额外的 Content-* 头字段来处理.

RFC 2046 定义了最初的七种顶层 media types. 其中五种是 discrete types (离散类型), 就 MIME 处理而言其内容是不透明的. 剩余两种是 composite types (复合类型), 其内容需要额外 MIME 处理.

这组顶层 media types 旨在基本完整. 预期对更大受支持类型集合的增加, 通常可以通过为这些初始类型创建新的 subtypes 来完成. 将来只有通过该标准的标准轨道扩展, 才可以定义更多顶层类型. 如果出于任何原因要使用其他顶层类型, 其名称必须以 "X-" 开头, 以表明其非标准状态, 并避免与未来正式名称发生潜在冲突.

5.1. Content-Type 头字段语法

在 RFC 822 的 Augmented 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 := &lt;An extension token defined by a
               standards-track RFC and registered
               with IANA.>

x-token := &lt;The two characters "X-" or "x-" followed, with
            no intervening white space, by any token>

subtype := extension-token / iana-token

iana-token := &lt;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*&lt;any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

tspecials :=  "(" / ")" / "&lt;" / ">" / "@" /
              "," / ";" / ":" / "\" / &lt;">
              "/" / "[" / "]" / "?" / "="
              ; Must be in quoted-string,
              ; to use within parameter values

5.2. Content-Type 默认值

如果实体中不存在 Content-Type 头字段, 默认 Content-Type 取决于上下文:

在 MIME 消息顶层, 默认值 是 text/plain; charset=us-ascii
在 multipart entity 的 body part 内, 默认 Content-Type 是 text/plain; charset=us-ascii
在 "message/rfc822" 实体内, 默认 Content-Type 是 text/plain; charset=us-ascii

要点:

Content-Type 格式: type/subtype; parameter=value
type 和 subtype 不区分大小写
参数名不区分大小写, 但参数值通常区分大小写
默认值: text/plain; charset=us-ascii

七种顶层 Media Types:

Discrete Types

text: 文本数据
image: 图像数据
audio: 音频数据
video: 视频数据
application: 应用数据

Composite Types

message: 封装消息
multipart: 多个部分

5.1. Content-Type 头字段语法​

5.2. Content-Type 默认值​

Discrete Types​

Composite Types​

5.1. Content-Type 头字段语法

5.2. Content-Type 默认值

Discrete Types

Composite Types