内容传输编码 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标头的值描述了您为解决此问题而选择的规则。

7位编码

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

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

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

8位编码

8bit表示“我的数据可能包含扩展的 ASCII 字符；它们可能使用第 8（最高）位来表示标准 US-ASCII 7 位字符之外的特殊字符。” 与7bit ，仍然有 1000 个字符的行限制。

8bit ，就像7bit一样，实际上并没有对字节进行任何转换，因为它们被写入或从线路中读取。 这只是意味着您不能保证没有任何字节的最高位设置为“1”。

这似乎是7bit一个进步，因为它为您的内容提供了更多的自由。 但是，RFC 1341 包含以下花絮：

截至本文档发布时，还没有标准化的 Internet 传输可以在邮件正文中包含未编码的 8 位或二进制数据。 因此，在 Internet 上没有任何情况下“8 位”或“二进制”内容传输编码实际上是合法的。

RFC 1341 于 20 多年前问世。 从那时起，我们在RFC 6152 中获得了8 位 MIME 扩展。 但即便如此，行限制仍然可能适用：

请注意，此扩展并不能消除 SMTP 服务器限制行长的可能性； 服务器可以自由地实现此扩展，但仍将行长度限制设置为不低于 1000 个八位字节。

二进制编码

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

引用可打印

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

• 定义如何转义非 US-ASCII 字符，以便它们只能用 7 位字符表示。 （简短版本：它们显示为一个等号加两个 7 位字符。）
• 定义行将不超过 76 个字符，并且换行符将使用特殊字符（然后进行转义）表示。

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

Base64 编码

如果您的数据主要是非文本的（例如：图像文件），则您没有太多选择。 7bit不在桌面上。 在 MIME 扩展 RFC 之前，不支持8bit和binary 。 quoted-printable可以工作，但效率很低（每个字节将由 3 个字符表示）。

base64是此类数据的一个很好的解决方案。 它将 3 个原始字节编码为 4 个 US-ASCII 字符，这是相对高效的。 RFC 1341 进一步将base64编码数据的行长度限制为 76 个字符以适合 SMTP 消息，但是当您只是以固定长度拆分或连接任意字符时，这相对容易管理。

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

Answer 2

使用 content-transfer-encoding: 7bit正文中使用的字节（或更正确的部分边界内）应表​​示 ascii 字符，但不表示扩展的 ascii 字符。 这意味着 0-127 十进制（不使用第 8 位）。

由于未使用第 8 位，这意味着您无法使用utf-8或iso8859-7字节对文本进行编码，因为它们使用第 8 位。 您也不能添加二进制内容。

使用 content-transfer-encoding: 8bit您可以使用任何可能的字节，这意味着您可以使用utf-8字节或iso8859-7字节（都假设在 SMTP 中使用8BITMIME扩展名）对文本进行编码。 但是，由于仍然适用的最大行限制，您添加二进制内容仍然不安全，这可能会用换行符破坏您的字节。

现在，即使使用 7 位内容传输编码，您仍然可以将content-type的charset参数设置为utf-8 ，只要您仍然将字节保持在 0-127 的边界之间。

例如，使用7bit内容传输编码表示 ascii 之外的字符的一种可能方法是使用html 代码字符（ content-type: text/html ）

许多电子邮件客户端会根据情况将content-transfer-encoding为7bit 8bit或8bit 。 例如发送英文文本时为7bit ，发送多语言文本时为8bit 。 并且总是有quoted-printable和base64的选项，它们的字符也不使用第8位，但这超出了问题的范围。