为什么需要base64（又为什么我不能仅通过电子邮件发送二进制文件）？

我正在阅读Base64编码，并在Wikipedia上找到了它：

当需要对二进制数据进行编码时，通常需要使用Base64编码方案，该二进制数据需要通过旨在处理文本数据的媒体进行存储和传输。

...，给出的示例是通过电子邮件发送二进制文件。

我试图了解为什么需要base64。由于二进制数据是一堆字节，它是否可以直接转换为文本数据的ASCII？为什么根本需要base64？还是电子邮件的ASCII控制字符有问题？

对此有很好的维基百科文章。

ARPAnet使用的最早的NCP迭代更像比特流而不是字节流，或者试图协商一个方便的字节大小。8位字节直到后来才被标准化。还尝试了创建可在不同机器上工作的文件传输协议（邮件最初是FTP协议的功能，主要是作为MAIL和MLFL命令，然后拆分为MTP和后来的SMTP）。这些机器通常具有不同的字符编码-ASCII vs EBCDIC-甚至字节大小不同，8位字节vs 6位vs ...

因此，最初定义了邮件传输功能，用于以纯文本格式传输相对较短的消息。特别是“ NVT-ASCII”。例如，RFC 772说：

邮件表示和存储

邮件从发送主机中的存储设备传输到接收主机中的存储设备。由于两个系统中的数据存储表示形式不同，因此可能有必要对邮件执行某些转换。例如，NVT-ASCII在不同系统中具有不同的数据存储表示形式。PDP-10通常将NVT-ASCII存储为五个7位ASCII字符，在36位字中左对齐。360在32位字中将NVT-ASCII存储为四个8位EBCDIC码。Multics将NVT-ASCII存储为36位字中的四个9位字符。

为了简单起见，所有数据必须在MTP中表示为NVT-ASCII。这意味着在传输文本时，无论发送主机和接收主机是否不同，都必须将字符转换为标准的NVT-ASCII表示形式。发送方将数据从其内部字符表示形式转换为标准的8位NVT-ASCII表示形式（请参阅TELNET规范）。接收器将数据从标准格式转换为自己的内部格式。根据该标准，该顺序应用于表示一行文本的结尾。

即使8位通过网络传输，第8位也经常会被丢弃或修改，因为不需要保留它。实际上，某些协议要求将第8位设置为零，例如下面引用的初始SMTP RFC。换句话说，该软件不是8位干净的。

数据传输

TCP连接支持8位字节的传输。SMTP数据是7位ASCII字符。每个字符以8位字节发送，高位清零。

即使在8位ISO-8859-＃字符编码广泛使用之后，这种情况仍持续了很长时间。即使有些服务器已经是8位整洁的，而其他许多服务器却没有，并且盲目发送8位数据将导致消息混乱。

后来，发布了“扩展的SMTP”，允许邮件服务器声明其支持的SMTP扩展。其中之一是8BITMIME，表示接收服务器可以安全地接受8位数据。MIME邮件部分可以具有“ Content-Transfer-Encoding：8bit”，表明它们没有以任何方式进行编码。

但是，SMTP协议仍然基于行，并且具有998个八位位组的行限制，并且使用.行（0D 0A 2E 0D 0A）作为“消息结尾”指示符。这意味着，即使大多数二进制文件可以原封不动地发送，包含此八位位组序列的文件仍然有可能被解释为已传输消息的结尾，而文件的其余部分则被解释为SMTP命令，可能会造成损坏。同样，接收服务器可能会截断超过998个八位位组的“行”。

在2000年，“ BINARYMIME” ESMTP扩展发布为RFC 3030，允许通过SMTP传输原始二进制数据。现在，该消息以预定长度的块进行传输，并且使用零长度的块作为终止符，并且不再需要Base64和类似的编码。不幸的是，很少有SMTP服务器支持此扩展。例如，Postfix和Exim4都不做广告CHUNKING来回复EHLO。要利用BINARYMIME，消息路径中的所有服务器都必须支持BINARYMIME，该服务器可以不止一两个。

也可以看看：

• RFC 765：文件传输协议
• RFC 772：邮件传输协议
• RFC 821：简单邮件传输协议
• 维基百科：8位清除
• 维基百科：8BITMIME

一些较旧的电子邮件系统和软件不是8位纯净的，第8位用作控制字符。这足以掩盖二进制文件，因此需要Base64（或其他编码方案）。