如何理解IMAP电子邮件文本中的等号'='符号？ [英] How to understand the equal sign '=' symbol in IMAP email text?
问题描述
我正在使用Python imaplib处理电子邮件文本。
我使用fetch命令从GMail服务器获取原始数据电子邮件。但是，我发现一件事情非常棘手 - 等号'='。这不是一个正常的等号，而是一个特殊的符号。
例如：
-
'='有时用作文本行末尾的连字标记：
根据您的模块选择，课程讲师也可以在接下来的几周内联系yo =
u进行准备工作。开始=
是明智的做法，回顾模块大纲提供的预备阅读清单现在=
-
有时候，它的作用类似于'％'的转义标记，例如：
a = 20b实际上是a< SPACE> b
= 46rom实际上是从这里
我对这种奇怪的符号感到十分困惑。我认为必须有一个指导来解决这个问题，因为GMail可以在他们的应用程序中正确处理这些事情。
我看到这与HTML编码有关，就像'％ '将被编码。但问题是，我从IMAP响应得到的是一个包含'='符号的字符串。我该如何处理？使用正则表达式？
简而言之，行末尾的等号表示软换行符。一个等号后跟两个十六进制字符（0-9，AF）编码一个八位字节（byte）。
这种编码方案被称为quoted printable，并被定义在 RFC 2045 的第6.7节。特别是请参阅第（1）和（5）项。 $ b
6.7。 Quoted-Printable Content-Transfer-Encoding
Quoted-Printable编码用于表示
在很大程度上由与
中的可打印字符对应的八位位组组成的数据，US-ASCII字符组。它以这样的方式编码数据，即
所产生的八位字节不可能通过邮件传输进行修改。
如果被编码的数据大部分是US-ASCII文本，数据的编码形式
仍然很大程度上被人识别。如果消息通过
字符转换和/或行转换，则
完全US-ASCII的主体也可以用Quoted-Printable编码，以确保
的数据完整性。包装网关。
在这种编码中，八位位组由以下规则确定：
（1）（一般8位表示）除CR外的任何八位字节或
LF是被编码的数据的标准
（标准）形式的CRLF换行符的一部分，可以是由$ = $表示的
，后跟两位数字
八位字节值的十六进制表示。为此，
的十六进制字母
数字是0123456789ABCDEF。大写字母必须是
;小写字母是不允许的。因此，对于
例如，十进制值12（US-ASCII格式输入）
可以用= 0C表示，并且十进制值61（US-
ASCII等号）可以用= 3D表示。除非以下规则
允许替代编码，否则必须遵循此
规则。
（2）（文字表示）
33至60（含）和62至126（含），
的十进制值可以表示为US-ASCII字符
对应于那些八位字节（从EXCAMATION POINT到
不到，大于TILDE，
）。
（3）（空格）值为9和32的八位字节可以分别表示为
，分别表示为US-ASCII TAB（HT）和SPACE字符，
，但绝不能在编码行的最后
中表示。因此编码行上的任何TAB（HT）或SPACE字符
务必在该行
后面加一个可打印的字符。特别地，编码行的
端的=可以表示一个或多个TAB（HT）或SPACE
字符，表示软换行符
（见规则＃5） 。因此，根据规则＃1，必须表示一个十进制
值为9或32的八位字节，它出现在编码行
的末尾。这个规则是必需的，因为一些MTA（消息传输代理，
程序将消息从一个用户传输到另一个用户，或者执行这种传输的一部分）是已知的pad
具有空格的文本行以及其他行是已知的
从行的结尾
中删除空格字符。因此，在解码Quoted-Printable
主体时，一行上的任何尾随空格必须被删除
，因为它必然已经被
中间传输代理添加。
（4）（换行符）文本正文中的换行符（代表
作为文本规范形式的CRLF序列）必须是
（由RFC 822 ）换行符，这也是
CRLF序列，在Quoted-Printable编码中。由于
除了
文本之外的媒体类型的标准表示法通常不包括
换行符的表示形式作为CRLF序列，没有强制换行符
（即打算使用的换行符成为有意义的
并显示给用户）可以出现在这种类型的
quoted-printable编码中。序列
类似于= 0D，= 0A，= 0A = 0D和= 0D = 0A，例行
将出现在用引用表示的非文本数据中
可打印， 当然。
请注意，许多实现可能会选择将各种内容类型的
本地表示直接编码为
，而不是先转换为规范形式，然后再转换回到当地的
代表。特别是，这可能适用于使用除CRLF终结符序列以外的换行符约定
的系统上的纯
文本材料。这样的
实现优化是允许的，但是当组合的规范化编码步骤是
时，只有
等同于分别执行三个步骤。
（5）（Soft Line Breaks）Quoted-Printable编码
要求编码行长度不超过76
个字符。如果较长的行要用Quoted-Printable编码编码
，则必须使用软换行符
。一个等号作为
编码行上的最后一个字符，表示编码文本中的这种非重要（软）
换行符。
I am currently using Python imaplib to process email text.
I use fetch command to fetch the raw data email from GMail server. However, I found one thing really tricky - the equal sign '='. It is not a normal equal sign but a special symbol.
For example:
'=' sometimes acts as the hyphenation mark at the end of text line:
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 =Sometimes, it acts as a escape mark similar to '%', for example:
a=20bis actuallya<SPACE>b
=46rom hereis actuallyFrom here
I am totally confused about such weird notation. I think there must be a guidance to handle this because GMail can handle such thing correctly in their apps.
I see that this is related to HTML encoding, just like '%' will be encoded. But the problem is, all I get from the IMAP response is a string that contain this '=' symbol. How should I handle this? Using regular expression?
In a nutshell, an equal sign at the end of a line indicates a soft line break. An equal sign followed by two hexadecimal characters (0-9, A-F) encodes a single octet (byte).
This encoding scheme is called "quoted printable" and is defined in section 6.7 of RFC 2045. See items (1) and (5), in particular.
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.
这篇关于如何理解IMAP电子邮件文本中的等号'='符号？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
