为什么在 base64 中使用二进制数 64 而不是整个 ASCII 集？答案

【问题标题】：Why use the binary number 64 in base64 as opposed to whole ASCII set?为什么在 base64 中使用二进制数 64 而不是整个 ASCII 集？
【发布时间】：2019-11-03 15:43:41
【问题描述】：

我试图理解为什么我们会使用 Base64 将二进制数据转换为 ASCII 字符，而不是直接将其转换为 ASCII。在我见过的每次 Base64 计算中，您要么从 ASCII 字符开始，要么从在最终转换为 Base64 的过程中转换为 ASCII 的二进制数据开始。

我的问题是：为什么不直接将其保留为 ASCII，而不是将其转换为 Base64 子集？

我已经阅读了有关 Stackoverflow 的所有相关问题，虽然我发现了很多有用的信息，但这是我仍然无法解决的问题的一部分。

【问题讨论】：

请提供更多有关您所在的编程环境和语言的上下文。（BTW-ASCII 不支持所有字节值，因此您不能表示 ASCII。）
这不是特定项目的一部分；只是理论。使用 Base64，您可以使用一组 64 个字符中的文本字符序列来表示二进制数据序列。我只是想知道为什么我们会特别使用 64 个字符，而不是使用具有 100 个字符的 ASCII 集。我认为这与 64 是二进制的事实有关，但我不明白为什么我们需要在这种情况下使用二进制数。
移动数据时使用 Base64。没有具有某些限制的运输文件或机制，你是对的，这是没有意义的。

标签： encoding character-encoding base64 character ascii

【解决方案1】：

有几个原因。我认为几个最重要的原因是：

64 是一个很好的数字，它需要更少的计算（实际上只是移位）来将字节转换为 base64 和反之。没有乘法或除法。简单、快速，尤其是在不给邮件服务器增加更多负载的情况下。计算所需的输出缓冲区也很容易。
选择了一个安全的集合。并非 ASCII 中的所有字符或 ISO 中的所有字符都是安全的。某些国家/地区更改$ 或& 或~。并非所有字符集都有{。 ASCII 更改了几个字符的定义（例如 @ 位置）。应该允许空格（但在语义使用之外），与控制字符相同。不要假设 ASCII 在每台计算机或邮件服务器上都可用。事实上，ISO C 版本 1990 支持没有所有 ASCII 字符的机器。
它不应该干扰应该使用它的其他分隔符（电子邮件标题、URL 等），所以没有引号字符，而不是 :。可惜web使用/和=，但是因为有很多免费字符，所以解决问题很简单，不用重新设计。

【讨论】：