Skip to main content

4. MIME-Version Header Field (MIME-Version头部字段)

自1982年RFC 822发布以来, 实际上只有一种互联网消息的格式标准, 并且很少需要声明正在使用的格式标准. 本文档是补充RFC 822的独立规范. 尽管本文档中的扩展已经以与RFC 822兼容的方式定义, 但仍然存在一些情况, 邮件处理代理可能希望知道消息是否是根据新标准组成的.

因此, 本文档定义了一个新的头部字段"MIME-Version", 用于声明正在使用的互联网消息正文格式标准的版本.

根据本文档组成的消息必须 (MUST) 包含这样的头部字段, 具有以下逐字文本:

MIME-Version: 1.0

此头部字段的存在是断言该消息已按照本文档编写.

由于未来的文档可能再次扩展消息格式标准, 因此为MIME-Version字段的内容给出了正式的BNF:

version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

因此, 可能替换或扩展"1.0"的未来格式指定符被约束为两个整数字段, 由句点分隔. 如果收到MIME-Version值不是"1.0"的消息, 则不能假定它符合本文档.

请注意, MIME-Version头部字段在消息的顶层是必需的 (required). 对于多部分实体的每个正文部分, 它不是必需的. 对于类型为"message/rfc822"或"message/partial"的正文的嵌入头部, 当且仅当嵌入的消息本身声称符合MIME时才需要它.

无法完全指定符合本文档定义的MIME的邮件阅读器应如何处理将来可能以某个MIME-Version值 (不是"1.0") 到达的消息.

还值得注意的是, 特定媒体类型的版本控制不是使用MIME-Version机制完成的. 特别是, 某些格式 (如application/postscript) 具有媒体格式内部的版本编号约定. 在存在这种约定的地方, MIME不会取代它们. 在不存在这种约定的地方, 如有必要, MIME媒体类型可以在content-type字段中使用"version"参数.

实现者注意事项​

当检查MIME-Version值时, 必须忽略存在的任何RFC 822注释字符串. 特别是, 以下四个MIME-Version字段是等效的:

MIME-Version: 1.0

MIME-Version: 1.0 (produced by MetaSend Vx.x)

MIME-Version: (produced by MetaSend Vx.x) 1.0

MIME-Version: 1.(produced by MetaSend Vx.x)0

在没有MIME-Version字段的情况下, 接收邮件用户代理 (无论是否符合MIME要求) 可以选择根据本地约定解释消息正文. 目前正在使用许多这样的约定, 应该注意, 在实践中, 非MIME消息几乎可以包含任何内容.

不可能确定非MIME邮件消息实际上是US-ASCII字符集中的纯文本, 因为它很可能是一条消息, 使用一些早于MIME的非标准本地约定, 包括另一个字符集中的文本或以无法自动识别的方式呈现的非文本数据 (例如, uuencode压缩的UNIX tar文件).

关键点:

  • 所有MIME消息必须包含MIME-Version: 1.0头部
  • 版本格式为major.minor (如1.0)
  • 仅在消息顶层需要, 正文部分不需要
  • 忽略RFC 822注释
  • 非MIME消息可能使用本地约定
Last updated on