为什么我们使用 base 32 或 base 64 来表示数据而不是 0 和 1？答案

【问题标题】：Why do we use base 32 or base 64 to represent data instead of 0s and 1s?为什么我们使用 base 32 或 base 64 来表示数据而不是 0 和 1？
【发布时间】：2015-02-19 22:08:15
【问题描述】：

我最近编写了一个程序，它可以序列化一些数据（java 对象）并将生成的字符串保存在一个文本文件中。信息在 base 64 中序列化，因此数据最终看起来像这样：

rO0ABXBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBwcHBzcgAab3JnLmJ1a2tpdC51dGlsLmlvLldyYXBwZXLyUEfs8RJvBQIA。

我有点理解 base 64 的含义，但是，既然这是胡言乱语，为什么文本文件或计算机从一开始就不显示 0 和 1？如果我正确理解了底层过程，那么计算机上的所有信息无论如何都会以 0 和 1 的形式存储在某个地方，因为这是计算机最终存储信息的唯一方式。 base 64 不只是一种读取和解释字节的方式吗？为什么要让我的文本编辑器读取保存在计算机上的字节，将它们转换为字母（最终使文档对我来说更短），然后以上面的形式显示？尽管 base 64 以一种视觉上更紧凑的方式显示信息，但没有人可以读取 base 64 文本，并且文件仍然具有相同的确切大小。

【问题讨论】：

这不清楚。您是否在问为什么您的文本编辑器没有将文件显示为 0 和 1 的序列？
抱歉，如果我的问题不太清楚。我知道文本编辑器会显示字母和数字，因为它被告知要这样做，我的问题是为什么我们通常首先打扰告诉文本编辑器以字母顺序显示字节集合，如果可以的话'无论如何不要读它。我希望这更有意义！

标签： java serialization binary base64 base

【解决方案1】：

Base64 用于通过不理解和/或破坏 8 位数据的系统发送 8 位数据。例如大多数较旧的电子邮件系统采用 7 位文本，并且会丢弃您的 8 位电子邮件。

b64/b32 不是存储格式。他们大量浪费了空间。将一个值编码为 base64 会使其大小平均增加约 33%。它们是传输格式，以确保您的 8 位数据完整地通过 7 位系统。

考虑一个简单的文本序列：abc。假设 ASCII 文本，那是

0x61      0x62       0x63      (hex)
01100001  01100010   01100011  (binary)
97        98         99        (decimal)

当挤成一个文件时，你的位会很简单

011000010110001001100011

如果这个 8bit 字节序列通过一个哑 7bit 传输介质发送，然后重新恢复到 8bit 系统，那么所有关于哪些位属于哪个字节的感觉都将丢失。你最终会得到

0110000   1011000  1001100  011

因为接收的 8bit 系统不会知道原始数据是 8bit。它将看到来自 7 位系统的位，并将这些位分成 7 位序列。现在你的价值观被打破了：

0110000   1011000  1001100  011                   (binary)
48        88       88       corrupt/missing bits  (decimal)
30        58       58       corrupt/missing bits  (hex)

这些值将对应于 ASCII 字符

RS X X

与您的原始文本完全不同。

【讨论】：

有趣，感谢您的回答！为什么将信息转换为 base64 格式会放大其大小？存储的信息和字节不还是一样吗？
不能合并任意 8 位数据的更现代的格式示例包括 XML 和 JSON。由于它们可以合并任意文本数据，因此使用 base64 将二进制转换为文本。
@MagnusQ 是的，它是相同的数据，但不，它不是相同的字节。普通字节有 256 种可能性（因此允许每个值打包 8 位），base64 选择可能传输良好的 64 位（因此每个值只允许打包 6 位）。三个二进制字节变成四个 base64 字符。
base64 = 6 位。将 8 位字节转换为 6 位字节意味着您必须添加额外的字符以保留溢出位。这相当于 33% 的开销。