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

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

读取起来可能有点密集，但是RFC 1341的“ Content-Transfer-Encoding”部分具有所有详细信息：

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

这种情况越来越糟。这是我的摘要：

背景

根据定义（RFC 821），SMTP将邮件限制为每行7位的1000个字符的行。这意味着沿管道发送的所有字节都不能将最高有效（“最高顺序”）位设置为“ 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位或二进制数据。因此，在任何情况下，“ 8位”或“二进制”内容传输编码在互联网上实际上都是合法的。

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

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

二进制编码

binary与相同8bit，但没有行长限制。您仍然可以包含所需的任何字符，并且没有额外的编码。与8bitRFC 1341类似，RFC 1341指出这实际上不是合法的编码传输编码。RFC 3030对此进行了扩展BINARYMIME。

引用可打印

在8BITMIME扩展之前，需要一种方法来发送不能通过7bitSMTP传输的内容。HTML文件（可能包含超过1000个字符的行）和带有国际字符的文件就是很好的例子。的quoted-printable编码（在RFC 1341的5.1节中定义的）被设计成处理这一点。它有两件事：

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

由于转义和短行，带引号的可打印内容比7bit或难于被人阅读8bit，但它确实支持范围广泛的可能内容。

Base64编码

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

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

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