背景资料

根据定义(RFC 821) ，SMTP 将邮件限制为每行7位的1000个字符。这意味着您发送到管道的所有字节都不能将最重要(“最高顺序”)位设置为“1”。

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

Content-Transfer-Encoding报头的值描述了您为解决此问题而选择的规则。

7位编码

7bit simply means "My data consists only of US-ASCII characters, which only use the lower 7 bits for each character." You're basically guaranteeing that all of the bytes in your content already adhere to the restrictions of SMTP, and so it needs no special treatment. You can just read it as-is.

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

只要您的内容符合这些规则，7bit就是最好的传输编码，因为不需要额外的工作; 您只需在字节从管道中出来时读/写它们。它也很容易眼球 7bit的内容，并使它的意义。这里的想法是，如果你只是写在“纯英语文本”，你会很好。但是那个在2005年是不正确的和它今天不是真的。

8位编码

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

与 7bit一样，8bit实际上并不进行字节写入或从连线读取时的任何转换。这只意味着您不能保证所有字节的最高位都不会设置为“1”。

This seems like a step up from 7bit, since it gives you more freedom in your content. However, RFC 1341 contains this tidbit:

自本文件公布之日起，没有任何标准化的互联网传输服务可以合法地在邮件体中包含未编码的8位或二进制数据。因此，在任何情况下，“8位”或“二进制”内容传输编码实际上在互联网上是合法的。

RFC 1341在20年前就问世了。从那时起，我们已经在 RFC 6152中获得了 8位 MIME 扩展。但即便如此，界限仍可能适用:

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

Binary Encoding

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

引自《印刷》杂志

在 8BITMIME扩展之前，需要有一种方法来通过 SMTP 发送不能是 7bit的内容。HTML 文件(可能有超过1000个字符的行)和具有国际字符的文件就是很好的例子。quoted-printable编码(在 RFC1341的5.1节中定义)就是为了处理这个问题而设计的。它有两个作用:

定义如何转义非 US-ASCII 字符，以便它们只能用7位字符表示。(简而言之: 它们显示为一个等于号外加两个7位字符。)
定义行不大于76个字符，并且行分隔符将使用特殊字符(然后转义)表示。

报价打印，因为转义和短行，是更难以阅读的人比 7bit或 8bit，但它确实支持更广泛的可能的内容范围。

Base64编码

如果您的数据大部分是非文本的(例如: 图像文件) ，那么您没有多少选择。7bit没戏了。在 MIME 扩展 RFC 之前，不支持 8bit和 binary。quoted-printable可以工作，但是效率很低(每个字节用3个字符表示)。

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

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