跳到主要内容

3. 消息头部字段的变更

为允许在字段值中使用非 ASCII 的 Unicode 字符, [RFC5322] 中的头部定义被扩展以支持新格式. 以下各节规定了 RFC 5322 ABNF 所需的变更.

下文未提及的语法规则仍按 [RFC5322] 定义.

注意, 本协议不改变 RFC 5322 中定义头部字段名的规则. 头部字段的正文允许包含 Unicode 字符, 但头部字段名本身必须仅由 ASCII 字符组成.

另请注意, 这种格式的消息通过 SMTP 传输时需要使用 SMTPUTF8 扩展 [RFC6531].

3.1. UTF-8 语法与规范化​

UTF-8 字符可以用八位组来定义, 使用以下取自 [RFC3629] 的 ABNF [RFC5234]:

UTF8-non-ascii  =   UTF8-2 / UTF8-3 / UTF8-4

UTF8-2          =   <Defined in Section 4 of RFC3629>

UTF8-3          =   <Defined in Section 4 of RFC3629>

UTF8-4          =   <Defined in Section 4 of RFC3629>

关于 Unicode 规范化的讨论见 [RFC5198]; 应当 (SHOULD) 使用规范化形式 NFC [UNF]. 实际上, 若要正确地进行国际化, 最常被提及的目标之一就是允许人们正确拼写自己的姓名. 由于许多邮箱的 local part 反映了个人姓名, 该原则同样适用于邮箱. 不应 (SHOULD NOT) 使用 NFKC 规范化形式 [UNF], 因为它可能丢失在某些特殊情况下正确拼写某些姓名所需的信息.

3.2. RFC 5322 的语法扩展​

以下规则扩展了 [RFC5322] 和 [RFC5234] 中定义的 ABNF 语法, 以允许 UTF-8 内容.

VCHAR   =/  UTF8-non-ascii

ctext   =/  UTF8-non-ascii

atext   =/  UTF8-non-ascii

qtext   =/  UTF8-non-ascii

text    =/  UTF8-non-ascii
              ; note that this upgrades the body to UTF-8

dtext   =/  UTF8-non-ascii

上述变更意味着以下构造现在允许使用 UTF-8:

  1. 非结构化文本 (unstructured text), 用于 "Subject:" 或 "Content-description:" 等头部字段.

  2. 任何使用 atom 的构造, 包括但不限于地址和 Message-ID 的 local part. 这包括 "Received:" 头部字段 "for" 子句中的地址.

  3. 带引号的字符串 (quoted string).

  4. 域 (domain).

注意, 头部字段名不在此列; 它们仍被限制为 ASCII.

3.3. Message-ID 中 8-bit UTF-8 的使用​

Message-ID 生成算法的实现者可以 (MAY) 倾向于将输出限制为 ASCII, 因为这样做有一些好处, 例如在邮件列表会话中构造 "In-reply-to:" 和 "References:" 头部字段时, 其中一些发送方使用国际化地址, 而另一些不使用.

3.4. 对行长限制的影响​

[RFC5322] 第 2.1.1 节将行长限制为 998 个字符, 并建议将行长限制为仅 78 个字符. 本规范将前一个限制改为 998 个八位组. (注意, 在 ASCII 中八位组和字符实际上相同, 但在 UTF-8 中并非如此.) 78 字符限制仍以字符而非八位组定义, 因为它旨在解决显示宽度问题, 而不是行长问题.

3.5. MIME 消息类型编码限制的变更​

本规范更新了 [RFC2045] 的第 6.4 节. [RFC2045] 禁止对 "message/" 的任何子类型施加内容传输编码. 本规范放宽了该规则 -- 它允许新定义的 MIME 类型允许内容传输编码, 并且允许对 message/global 使用内容传输编码 (见第 3.7 节).

背景: 通常 message/global 的传输会在 8-bit-clean 信道中进行, 且正文部分采用 "identity" 编码, 也就是说无需解码.

但在按 [RFC6152] 所述将包含 message/global 的消息从 8-bit 降级为 7-bit 的情况下, 可能必须对该消息施加某种编码. 如果该消息在 7-bit 环境与实现这些扩展的环境之间多次往返, 就可能出现多层编码. 预计这在实践中很少见到, 而且人们认为处理该问题的其他方式所带来的复杂度要大于在必要时允许嵌套编码的复杂度.

3.6. MIME 编码词的使用​

MIME 编码词 (encoded-words) 设施 [RFC2047] 提供了放置非 ASCII 文本的能力, 但仅限于本扩展所允许位置的一个子集. 此外, 编码词要复杂得多, 因为它们允许使用任意字符集. 因此, 在为采用本扩展的消息生成头部字段时, 不应 (SHOULD NOT) 使用编码词. 代理可以 (MAY) 在并入来自另一条消息的材料时, 将编码词的用法转换为直接使用 UTF-8.

注意, 解码编码词时必须小心, 因为把编码词替换为其 UTF-8 解码等价物后, 结果可能在语法上是非法的. 选择解码编码词的处理程序禁止 (MUST NOT) 生成语法非法的字段.

3.7. message/global 媒体类型​

这种格式的国际化消息必须 (MUST) 仅在经 [RFC6531] 授权的情况下传输, 或在支持这些消息的非 SMTP 环境内传输. 满足以下任一条件的消息即为 "message/global 消息":

  • 它包含本文档所规定的 8-bit UTF-8 头部值, 或

  • 它在其正文部分的头部字段中包含 8-bit UTF-8 值.

除此之外, message/global 部分的内容与 message/rfc822 部分完全相同.

如果这种类型的对象被发送到仅支持 7-bit 的系统, 则必须 (MUST) 施加适当的内容传输编码. (注意, 符合 MIME 但不识别 message/global 的系统应按照 [RFC2046] 第 5.2.4 节所述将其视为 "application/octet-stream".)

注册信息如下:

Type name: message

Subtype name: global

Required parameters: none

Optional parameters: none

Encoding considerations: 允许任何内容传输编码. 在允许的情况下推荐使用 8-bit 或 binary 内容传输编码.

Security considerations: 见第 4 节.

Interoperability considerations: 对于带有国际化电子邮件头部的电子邮件消息, 该媒体类型提供了与 message/rfc822 内容类型类似的功能. 当需要将此类内容嵌入另一条消息或将其退回时, 通常可以选择使用该媒体类型并保持内容不变, 或者将内容向下转换为 message/rfc822. 这两种选择都能与既有实现互操作, 但具有不同的特性. 不了解国际化头部的系统通常会将 message/global 正文部分视为未知附件, 而它们能够理解 message/rfc822 的结构. 然而, 理解 message/global 的系统所提供的功能要优于向下转换为 message/rfc822 的结果. 最具互操作性的选择取决于已部署的软件.

Published specification: RFC 6532

Applications that use this media type: 支持 multipart/report 生成或解析的 SMTP 服务器和电子邮件客户端. 将带有国际化头部的消息作为附件转发的电子邮件客户端.

Additional information:

Magic number(s): none

File extension(s): 建议使用扩展名 ".u8msg".

Macintosh file type code(s): 建议使用统一类型标识符 (UTI) "public.utf8-email-message". 它符合 "public.message" 和 "public.composite-content", 但不一定符合 "public.utf8-plain-text".

Person & email address to contact for further information: 见本文档的作者地址一节.

Intended usage: COMMON

Restrictions on usage: 这是一种嵌入其他 MIME 媒体类型的结构化媒体类型. 除非该媒体类型通过仅支持 7-bit 的传输发送, 否则应当 (SHOULD) 使用 8-bit 或 binary 内容传输编码.

Author: 见本文档的作者地址一节.

Change controller: IETF Standards Process