阅读起来可能有点密集，但 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 包含以下花絮：
截至本文档发布时，尚不存在可以合法在邮件正文中包含未编码的 8 位或二进制数据的标准化互联网传输。因此，在任何情况下，“8 位”或“二进制”内容传输编码在互联网上实际上是合法的。
RFC 1341 已于 20 多年前问世。从那时起我们就得到了8 位 MIME 扩展 in RFC 6152。但即便如此，线路限制仍然可能适用：
请注意，此扩展并不能消除 SMTP 服务器限制线路长度的可能性；服务器可以自由地实现此扩展，但仍然设置不低于 1000 个八位字节的行长度限制。
二进制编码
binary是相同的8bit，除了没有行长度限制。您仍然可以包含任何您想要的字符，并且没有额外的编码。如同8bit，RFC 1341 声明它并不是真正合法的编码传输编码。RFC 3030将此扩展为BINARYMIME.
引用可打印
之前8BITMIME扩展，需要有一种方法来发送无法发送的内容7bit通过 SMTP。 HTML 文件（可能有超过 1000 个字符行）和具有国际字符的文件就是很好的例子。这quoted-printable编码（在 RFC 1341 的第 5.1 节中定义）旨在处理此问题。它做了两件事：
- 定义如何转义非 US-ASCII 字符，以便它们只能用 7 位字符表示。 （简短版本：它们显示为等号加两个 7 位字符。）
- 定义行不超过 76 个字符，并且换行符将使用特殊字符（然后转义）表示。
由于转义和短行，引用的可打印内容比人类更难阅读7bit or 8bit，但它确实支持更广泛的可能内容。
Base64 编码
如果您的数据主要是非文本（例如：图像文件），则您没有太多选择。7bit已经不在讨论范围内了。8bit and binary在 MIME 扩展 RFC 之前不受支持。quoted-printable可以，但效率很低（每个字节将由 3 个字符表示）。
base64对于此类数据来说是一个很好的解决方案。它将 3 个原始字节编码为 4 个 US-ASCII 字符，效率相对较高。 RFC 1341 进一步限制了行长度base64- 将数据编码为 76 个字符以适合 SMTP 消息，但当您只是以固定长度拆分或连接任意字符时，管理起来相对容易。
最大的缺点是base64- 编码数据几乎完全无法被人类读取，即使它只是下面的“纯”文本。
