跳到主要内容

4. MIME-Version 头字段

自 RFC 822 于 1982 年发布以来, Internet 消息实际上只有一个格式标准, 因而人们很少觉得需要声明正在使用的格式标准. 本文档是补充 RFC 822 的独立规范. 虽然本文档中的扩展以兼容 RFC 822 的方式定义, 但在某些情况下, 邮件处理代理仍可能希望知道某条消息是否按新标准编写.

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

按照本文档编写的消息 MUST (必须) 包含这样的头字段, 其文本必须逐字如下:

MIME-Version: 1.0

该头字段的存在即断言该消息是按本文档编写的.

由于未来文档可能再次扩展消息格式标准, 下面给出 MIME-Version 字段内容的形式化 BNF:

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

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

注意, MIME-Version 头字段在消息顶层是必需的. multipart entity 的每个 body part 并不需要该字段. 对于类型为 "message/rfc822" 或 "message/partial" 的正文中的嵌入头部, 当且仅当嵌入消息自身声称符合 MIME 时, 才需要该字段.

无法完整规定符合本文档所定义 MIME 的邮件阅读器, 应如何处理未来可能到达且 MIME-Version 值不是 "1.0" 的消息.

还值得注意的是, 特定 media types 的版本控制并不使用 MIME-Version 机制完成. 特别是, 某些格式 (如 application/postscript) 具有媒体格式内部的版本编号约定. 在存在这类约定的地方, MIME 不取代它们. 在不存在这类约定的地方, MIME media type 如有必要可以在 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 之前的某些非标准本地约定, 包含另一种字符集的文本, 或以无法自动识别的方式呈现的非文本数据 (例如 uuencoded 的压缩 UNIX tar 文件).

要点:

  • 所有 MIME 消息 MUST 包含 MIME-Version: 1.0 头
  • 版本格式为 major.minor (例如 1.0)
  • 只在消息顶层需要, body parts 中不需要
  • 必须忽略 RFC 822 注释
  • 非 MIME 消息可以使用本地约定
最后于 更新