如何理解 IMAP 电子邮件文本中的等号“=”符号?
Posted
技术标签:
【中文标题】如何理解 IMAP 电子邮件文本中的等号“=”符号?【英文标题】:How to understand the equal sign '=' symbol in IMAP email text? 【发布时间】:2013-03-15 07:55:09 【问题描述】:我目前正在使用 Python imaplib 来处理电子邮件文本。
我使用 fetch 命令从 GMail 服务器获取原始数据电子邮件。然而,我发现一件事非常棘手 - 等号'='。它不是一个普通的等号,而是一个特殊的符号。
例如:
'=' 有时充当文本行末尾的连字符:
Depending upon your module selections, course lecturers may also contact yo=
u with preparatory work over the next few weeks. It would be wise to start =
reviewing the preparatory reading lists provided on the module syllabi now =
有时,它充当类似于 '%' 的转义标记,例如:
a=20b
实际上是a<SPACE>b
=46rom here
实际上是From here
我对这种奇怪的符号完全感到困惑。我认为必须有一个指导来处理这个问题,因为 GMail 可以在他们的应用程序中正确处理这样的事情。
我看到这与 html 编码有关,就像 '%' 将被编码一样。但问题是,我从 IMAP 响应中得到的只是一个包含这个“=”符号的字符串。我该如何处理?使用正则表达式?
【问题讨论】:
您要查找的术语是“quoted-printable”,它是该格式的名称(应在邮件的 MIME 标头中注明)。谷歌搜索应该会为您提供所需的所有信息。 @kindall 感谢这个关键字!我去看看 【参考方案1】:简而言之,行尾的等号表示软换行符。等号后跟两个十六进制字符(0-9、A-F)编码单个八位字节(字节)。
这种编码方案称为“引用可打印”,并在RFC 2045 的第 6.7 节中定义。尤其参见第 (1) 和 (5) 项。
6.7. Quoted-Printable Content-Transfer-Encoding
The Quoted-Printable encoding is intended to represent data that
largely consists of octets that correspond to printable characters in
the US-ASCII character set. It encodes the data in such a way that
the resulting octets are unlikely to be modified by mail transport.
If the data being encoded are mostly US-ASCII text, the encoded form
of the data remains largely recognizable by humans. A body which is
entirely US-ASCII may also be encoded in Quoted-Printable to ensure
the integrity of the data should the message pass through a
character-translating, and/or line-wrapping gateway.
In this encoding, octets are to be represented as determined by the
following rules:
(1) (General 8bit representation) Any octet, except a CR or
LF that is part of a CRLF line break of the canonical
(standard) form of the data being encoded, may be
represented by an "=" followed by a two digit
hexadecimal representation of the octet's value. The
digits of the hexadecimal alphabet, for this purpose,
are "0123456789ABCDEF". Uppercase letters must be
used; lowercase letters are not allowed. Thus, for
example, the decimal value 12 (US-ASCII form feed) can
be represented by "=0C", and the decimal value 61 (US-
ASCII EQUAL SIGN) can be represented by "=3D". This
rule must be followed except when the following rules
allow an alternative encoding.
(2) (Literal representation) Octets with decimal values of
33 through 60 inclusive, and 62 through 126, inclusive,
MAY be represented as the US-ASCII characters which
correspond to those octets (EXCLAMATION POINT through
LESS THAN, and GREATER THAN through TILDE,
respectively).
(3) (White Space) Octets with values of 9 and 32 MAY be
represented as US-ASCII TAB (HT) and SPACE characters,
respectively, but MUST NOT be so represented at the end
of an encoded line. Any TAB (HT) or SPACE characters
on an encoded line MUST thus be followed on that line
by a printable character. In particular, an "=" at the
end of an encoded line, indicating a soft line break
(see rule #5) may follow one or more TAB (HT) or SPACE
characters. It follows that an octet with decimal
value 9 or 32 appearing at the end of an encoded line
must be represented according to Rule #1. This rule is
necessary because some MTAs (Message Transport Agents,
programs which transport messages from one user to
another, or perform a portion of such transfers) are
known to pad lines of text with SPACEs, and others are
known to remove "white space" characters from the end
of a line. Therefore, when decoding a Quoted-Printable
body, any trailing white space on a line must be
deleted, as it will necessarily have been added by
intermediate transport agents.
(4) (Line Breaks) A line break in a text body, represented
as a CRLF sequence in the text canonical form, must be
represented by a (RFC 822) line break, which is also a
CRLF sequence, in the Quoted-Printable encoding. Since
the canonical representation of media types other than
text do not generally include the representation of
line breaks as CRLF sequences, no hard line breaks
(i.e. line breaks that are intended to be meaningful
and to be displayed to the user) can occur in the
quoted-printable encoding of such types. Sequences
like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely
appear in non-text data represented in quoted-
printable, of course.
Note that many implementations may elect to encode the
local representation of various content types directly
rather than converting to canonical form first,
encoding, and then converting back to local
representation. In particular, this may apply to plain
text material on systems that use newline conventions
other than a CRLF terminator sequence. Such an
implementation optimization is permissible, but only
when the combined canonicalization-encoding step is
equivalent to performing the three steps separately.
(5) (Soft Line Breaks) The Quoted-Printable encoding
REQUIRES that encoded lines be no more than 76
characters long. If longer lines are to be encoded
with the Quoted-Printable encoding, "soft" line breaks
must be used. An equal sign as the last character on a
encoded line indicates such a non-significant ("soft")
line break in the encoded text.
【讨论】:
非常感谢您的回答!!那么处理它的最佳做法是什么?我应该使用像=$
和=[0-9A-Z]2,2
这样的正则表达式来捕获这些特殊的吗?
你应该使用quopri
模块来处理它。 docs.python.org/2/library/quopri.html以上是关于如何理解 IMAP 电子邮件文本中的等号“=”符号?的主要内容,如果未能解决你的问题,请参考以下文章
中科大 计算机网络14 EMail SMTP简单邮件传输协议 POP3邮件传输协议 IMAP消息访问协议 HTTP超文本传输协议
如何在 Python 中通过 imap/pop3 识别 Outlook“消息 ID”?
如何使用 Zend_Mail_Protocol_Imap 或 Zend_Mail_Storage_Imap 批量检索电子邮件