RFC 2047 定义了 encoded-words 机制，用于在 MIME 文档中对非 ASCII 字符进行编码。它指定编码字中不允许出现空白字符（空格和制表符）。
但是，RFC 5322 用于解析电子邮件 MIME 文档指定长标题行应“折叠”。这种折叠应该发生在编码字解码之前还是之后？
我最近收到一封电子邮件，其中标头的编码文本部分有一个换行符，如下所示：
Header: =?UTF-8?Q?=C3=A5
=C3=A4?=
这有效吗？
当然，电子邮件可能以许多令人兴奋的方式无效，解析器需要处理它，但了解“正确”方式很有趣。 :)
【问题讨论】：
=0A 那样编码吗？在我的示例中，我使用 UTF-8 对文本 åä 进行了编码。
我误读了问题并回答，好像它是另一种空白。在这种情况下，空格出现在 MIME 单词中，而不是多个由空格分隔的单词。
这种事情是明确不允许的。从RFC2047中的格式介绍：
2. Syntax of encoded-words
An 'encoded-word' is defined by the following ABNF grammar. The
notation of RFC 822 is used, with the exception that white space
characters MUST NOT appear between components of an 'encoded-word'.
然后在同一部分：
IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's
by an RFC 822 parser. As a consequence, unencoded white space
characters (such as SPACE and HTAB) are FORBIDDEN within an
'encoded-word'. For example, the character sequence
=?iso-8859-1?q?this is some text?=
would be parsed as four 'atom's, rather than as a single 'atom' (by
an RFC 822 parser) or 'encoded-word' (by a parser which understands
'encoded-words'). The correct way to encode the string "this is some
text" is to encode the SPACE characters as well, e.g.
=?iso-8859-1?q?this=20is=20some=20text?=
The characters which may appear in 'encoded-text' are further
restricted by the rules in section 5.
这种事情是明确允许的。带有 MIME 词的标题应为 76 个字符或更少，并在需要时折叠。 RFC822 折叠标头缩进第二行和任何附加行。 RFC2047 标头应该只缩进一个空格。第一行的 ?= 和 =? 之间的空格应该从输出中抑制。
参见 RFC 第 12 页底部的示例：
encoded form displayed as
---------------------------------------------------------------------
(=?ISO-8859-1?Q?a?= (ab)
=?ISO-8859-1?Q?b?=)
Any amount of linear-space-white between 'encoded-word's,
even if it includes a CRLF followed by one or more SPACEs,
is ignored for the purposes of display.
【讨论】：