Skip to main content

5. Content-Type Header Field (Content-Type头部字段)

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

历史注释: Content-Type头部字段首次在RFC 1049中定义. RFC 1049使用了更简单且功能较弱的语法, 但在很大程度上与此处给出的机制兼容.

Content-Type头部字段通过给出媒体类型和子类型标识符, 并提供某些媒体类型可能需要的辅助信息, 来指定实体正文中数据的性质. 在媒体类型和子类型名称之后, 头部字段的其余部分只是一组参数, 以attribute=value表示法指定. 参数的顺序不重要.

一般来说, 顶级媒体类型用于声明数据的一般类型, 而子类型指定该类型数据的特定格式. 因此, "image/xyz"的媒体类型足以告诉用户代理该数据是图像, 即使用户代理不知道特定的图像格式"xyz". 这些信息可用于, 例如, 决定是否向用户显示来自无法识别的子类型的原始数据——对于无法识别的text子类型, 这样的操作可能是合理的, 但对于无法识别的image或audio子类型则不然. 因此, text、image、audio和video的注册子类型不应 (SHOULD NOT) 包含实际上属于不同类型的嵌入信息. 此类复合格式应 (SHOULD) 使用"multipart"或"application"类型表示.

参数是媒体子类型的修饰符, 因此不会从根本上影响内容的性质. 有意义的参数集取决于媒体类型和子类型. 大多数参数与单个特定子类型相关联. 但是, 给定的顶级媒体类型可以定义适用于该类型的任何子类型的参数. 参数可能是由其定义的内容类型或子类型所必需的, 或者它们可能是可选的. MIME实现必须 (MUST) 忽略它们不识别的任何参数的名称.

例如, "charset"参数适用于"text"的任何子类型, 而"boundary"参数对于"multipart"媒体类型的任何子类型都是必需的.

没有适用于所有媒体类型的全局有意义的参数. 在MIME模型中, 真正的全局机制最好通过定义额外的Content-*头部字段来解决.

在RFC 2046中定义了七种顶级媒体类型的初始集合. 其中五种是离散类型 (discrete types), 就MIME处理而言, 其内容基本上是不透明的. 其余两种是复合类型 (composite types), 其内容需要MIME处理器进行额外处理.

这组顶级媒体类型旨在基本完整. 预计通常可以通过创建这些初始类型的新子类型来完成对更大的支持类型集的添加. 将来, 只能通过对本标准的标准跟踪扩展来定义更多的顶级类型. 如果出于任何原因要使用另一个顶级类型, 则必须 (MUST) 为其指定以"X-"开头的名称, 以表明其非标准状态并避免与未来官方名称的潜在冲突.

5.1. Syntax of the Content-Type Header Field (Content-Type头部字段的语法)​

在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 Defaults (Content-Type默认值)​

如果实体中不存在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

七种顶级媒体类型:

离散类型 (Discrete Types)​

  1. text: 文本数据
  2. image: 图像数据
  3. audio: 音频数据
  4. video: 视频数据
  5. application: 应用程序数据

复合类型 (Composite Types)​

  1. multipart: 多部分实体
  2. message: 封装的消息

常见参数:

  • charset: 用于text类型, 指定字符集
  • boundary: 用于multipart类型, 指定分隔符
  • name: 文件名 (非标准, 但广泛使用)
Last updated on