我看到了许多关于base64在当今互联网中使用的资源。据我所知，所有这些资源似乎都以不同的方式阐明了单个用例：在Base64中对二进制数据进行编码，以避免在传输期间(由中间系统)将其误解/损坏为其他内容。但我没有发现任何解释如下：
- 为什么二进制数据会被中间系统破坏？如果我将图像从服务器发送到客户端，任何中间服务器/系统/路由器都会简单地将数据转发到客户端路径中的下一个适当的服务器/系统或路由器。为什么中间服务器/系统/路由器需要解释其接收到的内容？在当今的互联网中，有没有这样的系统可能会破坏/错误地解释它接收到的数据
- 为什么我们只担心二进制数据会被破坏。我们使用Base64是因为我们确信这64个字符永远不会被破坏/误解。但按照同样的逻辑，任何不属于base64字符的文本字符都可能被破坏/误解。那么，为什么base64只用于编码二进制数据？扩展同样的想法，当我们使用浏览器时，javascript和HTML文件是以base64格式传输的吗
使用Base64有两个原因：
- 不是8位干净的系统。这源于"；之前的时间"；一些系统非常重视ASCII，只考虑(并传输)任何8位字节中的7位(由于ASCII只使用7位，只要所有内容实际上都是ASCII，那就"好"了)
- 系统是8位干净的，但试图使用特定的编码对数据进行解码(即，他们认为它是格式良好的文本)
在传输二进制(即非文本)数据时，这两种方法都会产生类似的效果：它们会试图将二进制数据解释为明显没有意义的字符编码中的文本数据(因为二进制数据中没有字符编码)，并因此以不可修复的方式修改数据。
Base64以一种相当巧妙的方式解决了这两个问题：它将所有可能的二进制数据流映射到有效的ASCII文本中：第8位从未在Base64编码的数据上设置，因为只使用常规的旧ASCII字符。
这也很好地解决了第二个问题，因为最常用的字符编码(除了UTF-16和UCS-2，以及一些较少使用的编码)是ASCII兼容的，这意味着：所有有效的ASCII流恰好也是最常见编码中的有效流，并表示相同的字符(这些编码的示例是ISO-8859-*系列、UTF-8和大多数Windows代码页)。
关于你的第二个问题，答案有两个：
- 文本数据通常带有某种元数据(数据中的HTTP标头或元标记)，用于描述用于解释它的编码。为处理此类数据而构建的系统可以理解、容忍或解释这些标记
- 在某些情况下(尤其是邮件传输)，我们确实必须使用各种编码技术来确保文本不会被损坏。这可能是使用带引号的可打印编码，有时甚至是在Base64中包装文本数据
最后但并非最不重要的是：Base64有一个严重的缺点，那就是效率低下。每编码3个字节的数据，就会产生4个字节的输出，从而使数据的大小增加约33%。这就是为什么在不必要的时候应该避免它。
BASE64的用途之一是发送电子邮件。
邮件服务器使用终端传输数据。通常也有翻译，例如将cr翻译成单个n，反之亦然。注意：也不能保证可以使用8位(电子邮件标准是旧的，它也允许非"互联网"电子邮件，所以使用!而不是@)。此外，系统可能不是完全ASCII。
此外，nn.被认为是正文的末尾，mbox也使用n>From来标记新邮件的开始，所以当8位标志在邮件服务器中很常见时，这些问题也没有完全解决。
BASE64是消除所有问题的好方法：内容只是作为所有服务器都必须知道的字符发送，而编码/解码问题只需要发送者和接收者的协议(以及正确的程序)，而不用担心中间有很多中继服务器。注：c、r、n等全部忽略。
注意：您也可以使用BASE64对URL中的字符串进行编码，而无需担心网络浏览器的解释。您也可以在配置文件中看到BASE64(例如，包括图标)：特制的图像可能不会被解释为配置。只有BASE64可以方便地将二进制数据编码为非二进制数据设计的协议。