内容传输编码7位或8位

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

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

它可能有点密集的阅读，但RFC 1341的“内容传输编码”部分有所有的细节：

情况有点恶化。这是我的总结：

背景

根据定义（RFC 821），SMTP将邮件限制为每个7位1000个字符的行。这意味着您发送的pipe道中没有任何字节可以将最重要（“最高阶”）位设置为“1”。

我们要发送的内容往往不会内在地遵守这个限制。想象一个图像文件或包含Unicode字符的文本文件：这些文件的字节通常将其第8位设置为“1”。 SMTP不允许这样做，所以你需要使用“传输编码”来描述你是如何解决不匹配的。

Content-Transfer-Encoding标头的值描述了你select解决这个问题的规则。

7bit只是意味着“我的数据只包含US-ASCII字符，每个字符只使用较低的7位”。你基本上保证你的内容中的所有字节已经符合SMTP的限制，所以不需要特别的处理。你可以直接读取它。

请注意，当您select7bit ，您同意内容中的所有行都less于1000个字符的长度。

只要你的内容遵守这些规则， 7bit是最好的传输编码，因为没有额外的工作需要; 你只是读/写字节，因为他们离开pipe道。 7bit内容并理解它也很容易。这里的想法是，如果你只是写在“简单的英文文本”，你会没事的。但2005年情况并非如此，今天也不是这样。

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

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

这看起来像是从7bit升级，因为它给你更多的内容自由。但是，RFC 1341包含这个珍闻：

截至本文件发布时，没有标准化的互联网传输，在邮件正文中包含未编码的8位或二进制数据是合法的。因此，“8位”或“二进制”内容传送编码在互联网上实际上是合法的。

RFC 1341在20年前出现。从那以后，我们在RFC 6152中获得了8位MIME扩展。但即使如此，线路限制仍然可能适用：

请注意，这个扩展并不能消除SMTP服务器限制线路长度的可能性; 服务器可以自由地实现这个扩展，但是设置一个不小于1000个八位字节的行长限制。

binary与8bit相同，只是没有行长限制。你仍然可以包含你想要的任何字符，而且没有额外的编码。类似于8bit ，RFC 1341指出，这不是一个真正的合法编码传输编码。 RFC 3030用BINARYMIME扩展了这个。

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

引用Printable，由于逃跑和短线，比人7bit或8bit更难以阅读，但它确实支持更广泛的可能内容。

如果您的数据大部分是非文本的（例如图像文件），则没有多less选项。 7bit不在桌面上。在MIME扩展RFC之前不支持8bit和binary 。 quoted-printable会工作，但效率真的很差（每个字节将由3个字符表示）。

对于这种types的数据， base64是一个很好的解决scheme。它将3个原始字节编码为4个US-ASCII字符，相对有效。 RFC 1341进一步将base64编码数据的行长度限制为76个字符以适应SMTP邮件，但是当您只是以固定长度拆分或连接任意字符时，这相对容易pipe理。

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