非官方中文译本声明：本页为 IETF RFC 2047《MIME Part Three: Message Header Extensions for Non-ASCII Text（MIME 第三部分：报文头非 ASCII 扩展）》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc2047。

RFC 2047：MIME 第三部分（报文头非 ASCII 扩展）

独立提交 · K. Moore · University of Tennessee · 1996 年 11 月 · 类别：Standards Track（标准跟踪）· 取代：RFC 1521、1522、1590 · ISSN: 2070-1721

本备忘录的状态

本文档规定了互联网团体使用的一项互联网标准跟踪协议，并请求讨论与改进建议。有关该协议的标准化状态与现状，请参考最新版的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。

摘要

STD 11、RFC 822 定义了报文表示协议，详尽规定了 US-ASCII 报文头的细节，并将报文内容（或报文主体）留作扁平的 US-ASCII 文本。这套统称为多用途互联网邮件扩展（Multipurpose Internet Mail Extensions，MIME）的文档重新定义了报文的格式，以允许：

使用 US-ASCII 之外字符集的文本报文主体；
一组可扩展的、用于非文本报文主体的不同格式；
多部分（multi-part）报文主体；以及
使用 US-ASCII 之外字符集的文本报文头信息。

这些文档基于 RFC 934、STD 11 与 RFC 1049 中记载的早期工作，但对其进行了扩展与修订。由于 RFC 822 对报文主体所述甚少，这些文档在很大程度上与 RFC 822 正交（而非对其修订）。

本文档是该系列中的第三篇。它描述了针对 RFC 822 的扩展，以允许 Internet 邮件头字段中出现非 US-ASCII 文本数据。

本系列中的其他文档包括：

RFC 2045，规定了用于描述 MIME 报文结构的各种头字段；
RFC 2046，定义了 MIME 媒体类型系统的总体结构，并定义了一组初始的媒体类型；
RFC 2048，规定了 MIME 相关设施的各类 IANA 注册流程；以及
RFC 2049，描述了 MIME 一致性准则，并提供了一些 MIME 报文格式的示例、致谢与参考文献。

这些文档是 RFC 1521、1522 与 1590 的修订版，而后者本身又是 RFC 1341 与 1342 的修订版。RFC 2049 中的一个附录描述了与先前版本的差异及变更。

1. 引言
2. encoded-word 的语法
3. 字符集
4. 编码
- 4.1. "B" 编码
- 4.2. "Q" 编码
5. 报文头中 encoded-word 的使用
6. 邮件阅读器对 encoded-word 的支持
- 6.1. 报文头中 encoded-word 的识别
- 6.2. encoded-word 的显示
- 6.3. 邮件阅读器对格式错误 encoded-word 的处理
7. 一致性
8. 示例
9. 参考文献
10. 安全考量
11. 致谢
12. 作者地址
附录. 相对 RFC 1522 的变更

1. 引言

RFC 2045 描述了一种机制，用于标注以各种字符集编码的文本主体部分，以及如何将此类主体部分编码为可打印 US-ASCII 字符序列的方法。本备忘录描述了类似的技术，以允许在 RFC 822 [2] 报文头的若干部分中对非 ASCII 文本进行编码，且这种方式不太可能使现有的报文处理软件产生混淆。

与 RFC 2045 中描述的编码技术一样，此处概述的技术旨在以一种不太可能被现有 Internet 邮件处理程序的怪癖所干扰的方式，在报文头中使用非 ASCII 字符。具体而言，已知某些邮件中转程序会（a）删除某些报文头字段而保留其他字段，（b）重新排列 To 或 Cc 字段中地址的顺序，（c）重新排列报文头字段的（纵向）顺序，和/或（d）在原报文之外的不同位置对报文头进行"折行"。此外，已知某些邮件阅读程序难以正确解析那些虽然依据 RFC 822 合法、却使用反斜杠引用（backslash-quoting）来"隐藏"诸如 "<"、"," 或 ":" 等特殊字符，或利用了该规范中其他不常用特性的报文头。

尽管这些程序未能正确解释 RFC 822 头字段是不幸的，但若要去"破坏"这些程序，将给 Internet 邮件系统带来严重的运行问题。因此，本备忘录所描述的扩展并不依赖 RFC 822 那些鲜被使用的特性。

取而代之的是，某些"普通"可打印 ASCII 字符序列（称为"encoded-word"，编码字）被保留用作编码数据。encoded-word 的语法使其不太可能在报文头中"偶然"作为普通文本出现。此外，encoded-word 中所使用的字符被限制为：在 encoded-word 出现的上下文中没有特殊含义的字符。

一般而言，一个"encoded-word"是一个可打印 ASCII 字符序列，它以 "=?" 开头，以 "?=" 结尾，中间有两个 "?"。它指定了一个字符集与一个编码方法，并依据该编码方法的规则，包含了以图形化 ASCII 字符表示的原始文本。

实现本规范的邮件撰写程序将提供在头字段中输入非 ASCII 文本的手段，但在把这些字段插入报文头之前，会将这些字段（或这些字段的适当部分）转换为 encoded-word。

实现本规范的邮件阅读程序将在报文头的某些部分出现 encoded-word 时识别出它们。它不会"原样"显示 encoded-word，而是会反向执行编码，并以指定的字符集显示原始文本。

说明

本备忘录大量依赖 RFC 822 与 RFC 2045 中定义的记法与术语。特别是，本备忘录所用 ABNF 的语法在 RFC 822 中定义，且 RFC 822 中的许多终结符或非终结符也被用于此处定义的头字段扩展文法。在 RFC 822 中定义且为本备忘录所引用的符号包括：'addr-spec'、'atom'、'CHAR'、'comment'、'CTLs'、'ctext'、'linear-white-space'、'phrase'、'quoted-pair'、'quoted-string'、'SPACE' 与 'word'。成功实现此协议扩展需要仔细阅读 RFC 822 对这些术语的定义。

当本备忘录中出现术语"ASCII"时，它指的是"7 位美国信息交换标准码"（ANSI X3.4-1986）。该字符集的 MIME 字符集名称为 "US-ASCII"。当并非特指 MIME 字符集名称时，本文档出于简洁及与 RFC 822 一致性的考虑使用术语"ASCII"。但实现者需注意：在 MIME 报文与主体部分头中，字符集名称必须拼写为 "US-ASCII"。

本备忘录规定了一种在报文头中表示非 ASCII 文本的协议。它明确不定义任何在"8 位头"与纯 ASCII 头之间的转换，也不假定此类转换是可能的。

2. encoded-word 的语法

一个 'encoded-word' 由下列 ABNF 文法定义。此处使用 RFC 822 的记法，唯一的例外是：在 'encoded-word' 的各组成部分之间不得出现空白字符。

   encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

   charset = token    ; see section 3

   encoding = token   ; see section 4

   token = 1*<Any CHAR except SPACE, CTLs, and especials>

   especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
               <""> / "/" / "[" / "]" / "?" / "." / "="

   encoded-text = 1*<Any printable ASCII character other than "?"
                     or SPACE>
                  ; (but see "Use of encoded-words in message
                  ; headers", section 5)

'encoding' 与 'charset' 名称都是大小写无关的。因此字符集名称 "ISO-8859-1" 等价于 "iso-8859-1"，而名为 "Q" 的编码既可写为 "Q" 也可写为 "q"。

一个 'encoded-word' 的长度（包括 'charset'、'encoding'、'encoded-text' 与定界符）不得超过 75 个字符。若希望编码超出单个 75 字符 'encoded-word' 所能容纳的更多文本，可以使用多个 'encoded-word'（以 CRLF SPACE 分隔）。

虽然对多行头字段的长度没有限制，但包含一个或多个 'encoded-word' 的头字段的每一行被限制在 76 个字符以内。

这些长度限制既是为了便于通过网际邮件网关实现互操作，也是为了限制头字段解析器在判定某个记号是 "encoded-word" 还是其他内容之前（在寻找最后的 ?= 定界符时）必须使用的先行（lookahead）量。

重要：'encoded-word' 被设计为由 RFC 822 解析器识别为 'atom'。因此，未编码的空白字符（如 SPACE 与 HTAB）在 'encoded-word' 内部是被禁止的。例如，字符序列

      =?iso-8859-1?q?this is some text?=

会被解析为四个 'atom'，而不是单个 'atom'（被 RFC 822 解析器解析）或 'encoded-word'（被理解 'encoded-word' 的解析器解析）。编码字符串 "this is some text" 的正确方式是对 SPACE 字符一并编码，例如：

      =?iso-8859-1?q?this=20is=20some=20text?=

可出现在 'encoded-text' 中的字符还受到第 5 节规则的限制。

3. 字符集

'encoded-word' 的 'charset' 部分指定了与未编码文本相关联的字符集。'charset' 可以是 MIME "text/plain" 主体部分的 "charset" 参数所允许的任何字符集名称，或任何为配合 MIME text/plain 内容类型而向 IANA 注册的字符集名称。

某些字符集使用代码切换（code-switching）技术在"ASCII 模式"与其他模式之间切换。如果 'encoded-word' 中的未编码文本包含一段使字符集解释器切换出 ASCII 模式的序列，则它必须包含额外的控制码，使得在 'encoded-word' 结束时重新选中 ASCII 模式。（此规则分别适用于每个 'encoded-word'，包括同一头字段内相邻的 'encoded-word'。）

当有可能使用不止一个字符集来表示 'encoded-word' 中的文本，且消息的发送方与接收方之间不存在私下约定时，建议优先使用 ISO-8859-* 系列成员，而非其他字符集。

4. 编码

最初，"encoding" 的合法取值为 "Q" 与 "B"。这些编码如下所述。"Q" 编码推荐在待编码的大多数字符属于 ASCII 字符集时使用；否则应使用 "B" 编码。尽管如此，声称能识别 'encoded-word' 的邮件阅读器必须能够为其支持的任意字符集接受两种编码中的任意一种。

只有可打印 ASCII 字符的一个子集可用于 'encoded-text'。不允许使用空格与制表符，以使 'encoded-word' 的起止一目了然。"?" 字符在 'encoded-word' 内用于分隔 'encoded-word' 的各个部分，因而不能出现在 'encoded-text' 部分中。其他字符在某些上下文中也是非法的。例如，出现在 From 头字段中地址之前的 'phrase' 内的 'encoded-word' 不得包含 RFC 822 所定义的任何 "specials"。最后，某些其他字符在部分上下文中被禁用，以确保经过网际邮件网关的消息的可靠性。

"B" 编码自动满足这些要求。"Q" 编码允许在报文头中的非关键位置（如 Subject）使用范围广泛的可打印字符，而在其他位置可用的字符则较少。

4.1. "B" 编码

"B" 编码与 RFC 2045 定义的 "BASE64" 编码完全相同。

4.2. "Q" 编码

"Q" 编码类似于 RFC 2045 定义的 "Quoted-Printable"（引号可打印）内容传输编码。它旨在让含有大多数 ASCII 字符的文本无需解码即可在 ASCII 终端上辨认。

任意 8 位值可用一个 "=" 后跟两个十六进制数字表示。例如，若使用的字符集为 ISO-8859-1，则 "=" 字符将编码为 "=3D"，SPACE 编码为 "=20"。（十六进制数字 "A" 至 "F" 应使用大写。）
8 位十六进制值 20（如 ISO-8859-1 的 SPACE）可表示为 "_"（下划线，ASCII 95）。（此字符可能无法通过某些网际邮件网关，但其使用将极大提升在使用不支持此编码的邮件阅读器时 "Q" 编码数据的可读性。）注意，"_" 始终代表十六进制 20，即便 SPACE 字符在所使用字符集中占据不同的码位。
对应于除 "="、"?" 与 "_"（下划线）之外的可打印 ASCII 字符的 8 位值，可以表示为那些字符本身。（但第 5 节中的限制仍适用。）特别地，SPACE 与 TAB 在编码字内部不得以其本身表示。

5. 报文头中 encoded-word 的使用

一个 'encoded-word' 可依据下列规则出现在报文头或主体部分头中：

一个 'encoded-word' 可以（按 RFC 822 的定义）替换任何 Subject 或 Comments 头字段、任何扩展报文头字段，或任何其字段体被定义为 '*text' 的 MIME 主体部分字段中的 'text' 记号。一个 'encoded-word' 也可出现在任何用户自定义的（"X-"）报文或主体部分头字段中。
普通 ASCII 文本与 'encoded-word' 可以一同出现在同一头字段中。但是，出现在定义为 '*text' 的头字段中的 'encoded-word' 必须与前后的任何相邻 'encoded-word' 或 'text' 以 'linear-white-space' 分隔。
一个 'encoded-word' 可以出现在由 "(" 与 ")" 界定的 'comment' 内部，即任何允许 'ctext' 之处。更精确地说，RFC 822 中 'comment' 的 ABNF 定义修正如下：
```
    comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
```
出现在 'comment' 中的 "Q" 编码 'encoded-word' 不得包含字符 "("、")" 或 " （换行符）。出现在 'comment' 中的 'encoded-word' 必须与任何相邻的 'encoded-word' 或 'ctext' 以 'linear-white-space' 分隔。

需注意，'comment' 仅能在"结构化"字段体内部被识别。在字段体定义为 '*text' 的字段中，"(" 与 ")" 被视为普通字符而非注释定界符，此时适用本节规则 (1)。（见 RFC 822 第 3.1.2 与 3.1.3 节。）
作为 'phrase' 内 'word' 实体的替换，例如出现在 From、To 或 Cc 头中地址之前的那个。因此 RFC 822 中 'phrase' 的 ABNF 定义变为：
```
    phrase = 1*( encoded-word / word )
```
在这种情况下，"Q" 编码 'encoded-word' 中可使用的字符集被限制为：<大写与小写 ASCII 字母、十进制数字、"!"、"*"、"+"、"-"、"/"、"=" 与 "_"（下划线，ASCII 95）>。出现在 'phrase' 内的 'encoded-word' 必须与任何相邻的 'word'、'text' 或 'special' 以 'linear-white-space' 分隔。

这些是 'encoded-word' 唯一可以出现的位置。具体而言：

一个 'encoded-word' 不得出现在 'addr-spec' 的任何部分中。
一个 'encoded-word' 不得出现在 'quoted-string' 内部。
一个 'encoded-word' 不得用于 Received 头字段。
一个 'encoded-word' 不得用于 MIME Content-Type 或 Content-Disposition 字段的参数中，也不得用于任何结构化字段体中（'comment' 或 'phrase' 内部除外）。

'encoded-word' 中的 'encoded-text' 必须是自包含的；'encoded-text' 不得从一个 'encoded-word' 延续到另一个。这意味着 "B" 'encoded-word' 的 'encoded-text' 部分长度将是 4 字符的倍数；对于 "Q" 'encoded-word'，出现在 'encoded-text' 部分中的任何 "=" 字符之后都必须跟随两个十六进制字符。

每个 'encoded-word' 必须编码整数个八位组（octet）。每个 'encoded-word' 中的 'encoded-text' 必须依据所指定编码是良构的；'encoded-text' 不得在下一个 'encoded-word' 中延续。（例如，"=?charset?Q?=?=" 后接 "=?charset?Q?AB?=" 是非法的，因为两个十六进制数字 "AB" 必须紧跟同一个 'encoded-word' 中的 "="。）

每个 'encoded-word' 必须表示整数个字符。一个多八位组字符不得被拆分到相邻的 'encoded-word' 之间。

只有可打印数据与空白字符数据才应使用此方案进行编码。然而，由于这些编码方案允许对任意八位组值进行编码，实现此解码的邮件阅读器还应确保：在接收方终端上显示解码后的数据时，不会引起不期望的副作用。

使用这些方法来编码非文本数据（如图片或声音）不在本备忘录的定义范围内。允许使用 'encoded-word' 表示纯 ASCII 字符组成的字符串，但不鼓励。在极少数情况下，可能有必要对看起来像 'encoded-word' 的普通文本进行编码。

6. 邮件阅读器对 encoded-word 的支持

6.1. 报文头中 encoded-word 的识别

邮件阅读器必须依据 RFC 822 中的规则解析报文与主体部分头，以正确识别 'encoded-word'。

'encoded-word' 的识别方式如下：

任何定义为 '*text' 的报文或主体部分头字段，或任何用户自定义头字段，应按如下方式解析：从字段体起始处开始，并在每次 'linear-white-space' 出现之后，检查每一个最长 75 个可打印字符（且不含任何 'linear-white-space'）的序列，看其依据第 2 节语法规则是否构成一个 'encoded-word'。任何其他可打印字符序列都应作为普通 ASCII 文本处理。
任何未定义为 '*text' 的头字段应依据该头字段的语法规则解析。但是，出现在 'phrase' 内的任何 'word'，若符合第 2 节的语法规则，则应作为 'encoded-word' 处理；否则应作为普通 'word' 处理。
在 'comment' 内部，任何最长 75 个可打印字符（且不含 'linear-white-space'）、并符合第 2 节语法规则的序列，应作为 'encoded-word' 处理；否则应作为普通注释文本处理。
为按本规范解释 'encoded-word'，不要求存在 MIME-Version 头字段。原因之一在于：并不期望邮件阅读器在显示可能包含 'encoded-word' 的行之前，先解析整个报文头。

6.2. encoded-word 的显示

任何被如此识别的 'encoded-word' 都会被解码，并在可能的情况下，以原始字符集显示所得未编码文本。

注意：encoded-word 的解码与显示发生在结构化字段体被解析为记号之后。因此，有可能在 encoded-word 中隐藏 'special' 字符，而这些字符在显示时将与周围文本中的 'special' 字符无法区分。正因如此及其他原因，通常无法将包含 'encoded-word' 的报文头转换为可被 RFC 822 邮件阅读器解析的未编码形式。

当显示某个含有多个 'encoded-word' 的特定头字段时，分隔一对相邻 'encoded-word' 的任何 'linear-white-space' 将被忽略。（这是为了让多个 'encoded-word' 能够用于表示长串未编码文本，而无须在未编码文本中出现空格的位置处断开 'encoded-word'。）

若将来定义了其他编码，而邮件阅读器不支持所用编码，它可（a）将 'encoded-word' 作为普通文本显示，或（b）代以适当的消息，表明该文本无法被解码。

若邮件阅读器不支持所用字符集，它可（a）将 'encoded-word' 作为普通文本显示（即按其在头中的原样），（b）尽"最大努力"使用现有字符进行显示，或（c）代以适当的消息，表明解码后的文本无法显示。

若所用字符集采用了代码切换技术，则编码文本的显示隐式地从"ASCII 模式"开始。此外，邮件阅读器必须确保在 'encoded-word' 显示完毕后，输出设备重新回到"ASCII 模式"。

6.3. 邮件阅读器对格式错误 encoded-word 的处理

有可能出现这样的情况：一个依据第 2 节语法合法的 'encoded-word'，却依据所用编码的规则而格式错误。例如：

一个包含对特定编码而言非法的字符的 'encoded-word'（例如，"B" 编码中的 "-"，或 "B" 与 "Q" 编码中的 SPACE 或 HTAB）是格式错误的。
任何编码了非整数个字符或非整数个八位组的 'encoded-word' 是格式错误的。

邮件阅读器无需尝试显示与格式错误 'encoded-word' 相关联的文本。但是，邮件阅读器不得因为某个 'encoded-word' 格式错误而阻止对报文的显示或处理。

7. 一致性

声称符合本规范的邮件撰写程序必须确保：在 '*text' 或 '*ctext' 中，任何以 "=?" 开头、以 "?=" 结尾的非空白可打印 ASCII 字符序列，都必须是有效的 'encoded-word'。（"开头"意指：在字段体起始处、紧接 'linear-white-space' 之后，或对于 '*ctext' 内的 'encoded-word' 紧接 "(" 之后；"结尾"意指：在字段体末尾、紧接 'linear-white-space' 之前，或对于 '*ctext' 内的 'encoded-word' 紧接 ")" 之前。）此外，'phrase' 中任何以 "=?" 开头、以 "?=" 结尾的 'word' 都必须是有效的 'encoded-word'。

声称符合本规范的邮件阅读程序必须能够在消息头中合适位置出现时，依据第 6 节规则区分 'encoded-word' 与 'text'、'ctext' 或 'word'。它必须为其支持的任意字符集同时支持 "B" 与 "Q" 两种编码。当字符集为 "US-ASCII" 时，该程序必须能够显示未编码文本。对于 ISO-8859-* 字符集，邮件阅读程序至少必须能够显示其中同样属于 ASCII 字符集的那些字符。

8. 示例

以下是含有 'encoded-word' 的报文头示例：

   From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
   CC: =?ISO-8859-1?Q?Andr=E9?= Pirard <PIRARD@vm1.ulg.ac.be>
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

      Note: In the first 'encoded-word' of the Subject field above, the
      last "=" at the end of the 'encoded-text' is necessary because each
      'encoded-word' must be self-contained (the "=" character completes a
      group of 4 base64 characters representing 2 octets).  An additional
      octet could have been encoded in the first 'encoded-word' (so that
      the encoded-word would contain an exact multiple of 3 encoded
      octets), except that the second 'encoded-word' uses a different
      'charset' than the first one.

   From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se>
   To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
   Subject: Time for ISO 10646?

   To: Dave Crocker <dcrocker@mordor.stanford.edu>
   Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
   From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>
   Subject: Re: RFC-HDR care and feeding

   From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
         (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
   To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
      <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
   Subject: Test of new header generator
   MIME-Version: 1.0
   Content-type: text/plain; charset=ISO-8859-1

以下示例说明了出现在结构化字段体中的、含有 'encoded-word' 的文本是如何显示的。对于定义为 '*text' 的字段，规则略有不同，因为 "(" 与 ")" 不被识别为 'comment' 定界符。[第 5 节，第 (1) 段]。

在以下每个示例中，若相同的序列出现在 '*text' 字段中，"显示为"形式将不会被视为编码字，而是与"编码形式"完全相同。这是因为以下每个示例中的 encoded-word 都与一个 "(" 或 ")" 字符相邻。

编码形式（encoded form）	显示为（displayed as）
(=?ISO-8859-1?Q?a?=)	(a)
(=?ISO-8859-1?Q?a?= b)	(a b)
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)	(ab)
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)	(ab)
(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)	(ab)
(=?ISO-8859-1?Q?a_b?=)	(a b)
(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)	(a b)

在 'comment' 内部，'encoded-word' 与周围文本之间必须出现空白。[第 5 节，第 (2) 段]。但是，起始 'comment' 的 "(" 与 'encoded-word' 之间不需要空白。
相邻 'encoded-word' 之间的空白不会被显示。
即使 'encoded-word' 之间有多个 SPACE，在显示时也会被忽略。
'encoded-word' 之间的任意数量的 linear-white-space（即便包含后接一个或多个 SPACE 的 CRLF）在显示时都会被忽略。
为使 SPACE 显示在被编码文本的某一部分内，SPACE 必须作为 'encoded-word' 的一部分被编码。
为使 SPACE 显示在两串被编码文本之间，SPACE 可以作为其中一个 'encoded-word' 的一部分被编码。

9. 参考文献

[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, 1982 年 8 月。

[RFC 2049] Borenstein, N., 与 N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, 1996 年 11 月。

[RFC 2045] Borenstein, N., 与 N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 1996 年 11 月。

[RFC 2046] Borenstein N., 与 N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, 1996 年 11 月。

[RFC 2048] Freed, N., Klensin, J., 与 J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1996 年 11 月。

10. 安全考量

本备忘录不讨论安全问题。

11. 致谢

作者希望感谢 Nathaniel Borenstein、Issac Chan、Lutz Donnerhacke、Paul Eggert、Ned Freed、Andreas M. Kirchwitz、Olle Jarnefors、Mike Rosin、Yutaka Sato、Bart Schaefer 与 Kazuhiko Yamamoto，感谢他们针对本规范的早期版本所提供的有益建议、深刻评论与启发性的问题。

12. 作者地址

Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville TN 37996-1301

EMail: moore@cs.utk.edu

附录. 相对 RFC 1522 的变更（不分先后）

明确声明：使用 'encoded-word' 不要求 MIME-Version 存在。
增加明确说明：SPACE 与 TAB 不允许出现在 'encoded-word' 内部，并解释 'encoded-word' 在 RFC 822 解析器看来必须像一个 'atom'（更精确地说，是作为 'atom' 的值）。
增加了来自 Olle Jarnefors（谢谢！）的示例，说明了带有相邻 linear-white-space 的 encoded-word 是如何显示的。
明确列出 RFC 822 中定义且为本备忘录所引用的术语。
修正了因 nroff 的怪癖导致一行或两行及少数字符在所得文本中消失的转录排版错误。
澄清：encoded-word 允许出现在 RFC 822 头与 MIME 主体部分头中的 '*text' 字段内，但不作为参数值。
澄清：对于任何使用代码切换序列的字符集，要求在 'encoded-word' 的编码部分内切换回 ASCII 的要求。
增加说明：'encoded-word' 在 'comment' 内部由 "(" 与 ")" 定界，但在 *text 中并非如此（多么奇怪！）。
修正 Andre Pirard 示例，去掉 =E9 之后多余的 "_"（在 1342 之后已不再需要）。
澄清：'encoded-word' 可以紧接起始 "(" 之后出现，或紧接定界 'comment' 的结束 ")" 之前出现，而不仅仅是在 *ctext 内部与 "(" 和 ")" 相邻。
增加说明：解释 "B" 'encoded-word' 的 'encoded-text' 部分总是含有 4 的倍数个字符。
增加关于示例中 "=" 的说明。
说明：'encoded-word' 的处理发生在解析之后，以及由此带来的一些影响。
明确声明：不能期望在 1522 与纯 822 或所谓"8 位头"之间进行转换。
明确声明：'encoded-word' 在 'quoted-string' 内部无效。