Python 电子邮件标题奇怪的行为

Question

用于 python2.7 或 python3 的 Python 电子邮件 header 解码器在编码和未编码文本之间切换时似乎有一些奇怪的行为。

from email.header import decode_header
print decode_header("=?ISO-8859-1?B?QA==?=example.com");
print decode_header("=?ISO-8859-1?B?QA==?= example.com");
print decode_header("=?ISO-8859-1?Q?=40example?= .com");
print decode_header("=?ISO-8859-1?Q?=40example?=.com");

这是结果

[('=?ISO-8859-1?B?QA==?=example.com', None)]
[('@', 'iso-8859-1'), ('example.com', None)]
[('@example', 'iso-8859-1'), ('.com', None)]
[('=?ISO-8859-1?Q?=40example?=.com', None)]

在所有示例输入中，编码文本只是 @ 符号，它应该得到正确解释，但事实并非如此。我认为 RFC 1342 的解释对我来说似乎不正确。 Python 期望空格或换行符作为编码文本的结尾。我在 RFC 中没有看到这一点，RFC 仅表示我阅读时多个编码文本之间需要空间，而不是编码文本和文本的未编码部分之间需要空间。因此，每当你看到“？=”时，你都需要将其视为编码文本的结尾，而Python不会这样做。我想请教专家，这是这里的错误还是我弄错了？

维杰

Answer 1

RFC 2047定义了“编码字”可能出现的 3 个位置。几乎在所有情况下，它都需要分隔空格，甚至在“编码字”和未编码文本之间也是如此，并且大多数不需要分隔空格的情况似乎都是错误。文本如下所示(未应用 errata，并手动调整格式):

An 'encoded-word' may appear in a message header or body partheader according to the following rules:

1. An 'encoded-word' may replace a 'text' token (as defined by RFC 822)in any Subject or Comments header field, any extension messageheader field, or any MIME body part field for which the field bodyis defined as '*text'. An 'encoded-word' may also appear in anyuser-defined ("X-") message or body part header field.

   Ordinary ASCII text and 'encoded-word's may appear together in thesame header field. *However, an 'encoded-word' that appears in aheader field defined as 'text' MUST be separated from any adjacent'encoded-word' or 'text' by 'linear-white-space'.

2. An 'encoded-word' may appear within a 'comment' delimited by "(" and")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC822 ABNF definition for 'comment' is amended as follows:

    comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
   

   A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOTcontain the characters "(", ")" or "'encoded-word' that appears in a 'comment' MUST be separated fromany adjacent 'encoded-word' or 'ctext' by 'linear-white-space'.

   It is important to note that 'comment's are only recognized inside"structured" field bodies. In fields whose bodies are defined as'*text', "(" and ")" are treated as ordinary characters rather thancomment delimiters, and rule (1) of this section applies. (See RFC822, sections 3.1.2 and 3.1.3)

3. As a replacement for a 'word' entity within a 'phrase', for example,one that precedes an address in a From, To, or Cc header. The ABNFdefinition for 'phrase' from RFC 822 thus becomes:

    phrase = 1*( encoded-word / word )
   

   In this case the set of characters that may be used in a "Q"-encoded'encoded-word' is restricted to: <upper and lower case ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore, ASCII 95.)>. An 'encoded-word' that appears within a'phrase' MUST be separated from any adjacent 'word', 'text' or'special' by 'linear-white-space'.