email - 内容传输编码 7 位或 8 位

Question

发送电子邮件内容时，需要设置“内容传输编码”标题。我观察到我收到的许多电子邮件标题。一些电子邮件使用“7bit”，一些电子邮件使用“8bit”。

这两者有什么区别？推荐哪个？为了设置这些标题，电子邮件正文是否需要任何特殊编码？

Answer 1

阅读起来可能有点密集，但 RFC 1341 的“内容传输编码”部分包含所有详细信息:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

情况有点变得越来越糟。这是我的总结:

背景

根据定义 (RFC 821)，SMTP 将邮件限制为 1000 个字符的行，每行 7 位。这意味着您通过管道发送的任何字节都不能将最高有效(“最高阶”)位设置为“1”。

我们要发送的内容通常不会固有地遵守此限制。想想一个图像文件，或一个包含 Unicode 字符的文本文件:这些文件的字节通常将它们的第 8 位设置为“1”。 SMTP 不允许这样做，因此您需要使用“传输编码”来描述您是如何解决不匹配问题的。
Content-Transfer-Encoding 的值 header 描述您为解决此问题而选择的规则。

7位编码
7bit仅表示“我的数据仅由 US-ASCII 字符组成，每个字符仅使用低 7 位。”您基本上可以保证内容中的所有字节都已遵守 SMTP 的限制，因此不需要特殊处理。您可以按原样阅读它。

注意选择7bit时，您同意您的内容中的所有行的长度都少于 1000 个字符。

只要您的内容遵守这些规则，7bit是最好的传输编码，因为不需要额外的工作；您只需在字节离开管道时读/写字节。也很容易吸引眼球7bit内容并理解它。这里的想法是，如果你只是用“纯英文文本”写作，你会没事的。但是那个wasn't true in 2005今天不是这样。

8位编码
8bit意思是“我的数据可能包含扩展的 ASCII 字符；它们可能使用第 8(最高)位来指示标准 US-ASCII 7 位字符之外的特殊字符。”与 7bit 一样，仍然有 1000 个字符的行限制。
8bit ，就像 7bit , 实际上不会对字节进行任何转换，因为它们被写入或从线路中读取。这只是意味着您不能保证没有任何字节的最高位设置为“1”。

这似乎比 7bit 更上一层楼，因为它为您的内容提供了更多自由。但是，RFC 1341 包含以下花絮:

As of the publication of this document, there are no standardized Internet transports for which it is legitimate to include unencoded 8-bit or binary data in mail bodies. Thus there are no circumstances in which the "8bit" or "binary" Content-Transfer-Encoding is actually legal on the Internet.

RFC 1341 于 20 多年前问世。从那以后我们得到了8bit MIME Extensions在 RFC 6152 .但即便如此，行限制仍然可能适用:

Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets.

二进制编码
binary与 8bit 相同，除了没有行长限制。您仍然可以包含您想要的任何字符，并且没有额外的编码。类似于 8bit , RFC 1341 声明它不是真正的合法编码传输编码。 RFC 3030用 BINARYMIME 扩展了这个.

引用可打印

之前8BITMIME扩展，需要有一种方法来发送不能是 7bit 的内容通过 SMTP。 HTML 文件(可能有超过 1000 个字符的行)和带有国际字符的文件就是很好的例子。 quoted-printable encoding(在 RFC 1341 的第 5.1 节中定义)旨在处理此问题。它做两件事:

定义如何转义非 US-ASCII 字符，以便它们只能用 7 位字符表示。 (简短版本:它们显示为等号加两个 7 位字符。)

定义行将不超过 76 个字符，并且换行符将使用特殊字符(然后进行转义)表示。

Quoted Printable，由于有转义和短行，比 7bit 更难被人类阅读。或 8bit ，但它确实支持更广泛的可能内容。

Base64 编码

如果您的数据主要是非文本的(例如:图像文件)，则您没有太多选择。 7bit不在 table 上。 8bit和 binary在 MIME 扩展 RFC 之前不受支持。 quoted-printable会工作，但效率很低(每个字节将由 3 个字符表示)。
base64是此类数据的一个很好的解决方案。它将 3 个原始字节编码为 4 个 US-ASCII 字符，这是相对高效的。 RFC 1341 进一步限制了 base64 的行长- 将数据编码为 76 个字符以适应 SMTP 消息，但是当您只是以固定长度拆分或连接任意字符时，这相对容易管理。

最大的缺点是base64 - 编码的数据几乎完全无法被人类读取，即使它只是下面的“纯”文本。