Email 内容传输编码7位或8位

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

---

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

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

情况越来越糟了。以下是我的总结：

背景 根据定义，SMTP（RFC 821）将邮件限制为每行1000个字符，每个字符7位。这意味着您发送到管道的所有字节都不能将最高有效（“最高阶”）位设置为“1”

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

内容传输编码

标题的值描述了您为解决此问题而选择的规则

7比特编码

7bit

的简单意思是“我的数据只包含US-ASCII字符，每个字符只使用较低的7位。”您基本上是在保证内容中的所有字节都遵守SMTP的限制，因此不需要特殊处理。你可以照原样读

请注意，当您选择

7bit

时，您同意内容中的所有行长度都小于1000个字符

只要您的内容遵守这些规则，

7bit

就是最好的传输编码，因为不需要额外的工作；您只需在字节离开管道时读取/写入它们。它还可以很容易地观察

7bit

内容并理解它。这里的想法是，如果你只是用“纯英语文本”写作，你会没事的。但这在今天是不正确的

8比特编码

8bit

表示“我的数据可能包括扩展ASCII字符；它们可能使用第8位（最高）来表示标准US-ASCII 7位字符之外的特殊字符。”与

7bit

一样，仍有1000个字符的行限制

8bit

，就像

7bit

，在写入或从线路读取字节时，实际上不会对字节进行任何转换。这只是意味着您不能保证所有字节的最高位都设置为“1”

这似乎是对

7bit

的一个提升，因为它给了你更多的内容自由。但是，RFC 1341包含以下内容：

截至本文件发布之日，还没有标准化的互联网传输，在邮件正文中包含未编码的8位或二进制数据是合法的。因此，在任何情况下，“8位”或“二进制”内容传输编码在互联网上都是合法的

RFC1341问世于20多年前。从那以后，我们就开始了。但即使如此，仍可能适用以下限值：

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

二进制编码

binary

与

8bit

相同，只是没有行长度限制。您仍然可以包含任何想要的字符，并且没有额外的编码。与

8bit

类似，RFC1341声明它实际上不是合法的编码传输编码。使用

BINARYMIME

扩展此功能

引用可打印 在使用

8BITMIME

扩展之前，需要有一种方法通过SMTP发送不能是

7bit

的内容。HTML文件（可能有1000多个字符行）和带有国际字符的文件就是很好的例子。

引用的可打印编码（在RFC 1341第5.1节中定义）旨在处理此问题。它做两件事：


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

由于转义和短线，引用的可打印文本比
7bit
或
8bit
更难被人阅读，但它确实支持更广泛的可能内容

Base64编码
如果您的数据大部分是非文本的（例如：图像文件），那么您没有很多选择<代码>7它不在桌面上<在MIME扩展RFCs之前，不支持代码>8位

和

二进制

<代码>引用的可打印可以工作，但效率很低（每个字节将由3个字符表示）

base64

是这类数据的良好解决方案。它将3个原始字节编码为4个US-ASCII字符，这是相对有效的。RFC 1341进一步将

base64

编码数据的行长度限制为76个字符，以适应SMTP消息，但当您仅以固定长度拆分或连接任意字符时，这相对容易管理

---

最大的缺点是

base64

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

使用内容传输编码：7位正文中使用的字节（或在零件边界内更正确）应表示ascii字符，但不表示扩展ascii字符。这意味着0-127十进制（未使用第8位）

自8日起