为什么在 Base64 编码中使用填充？ [复制]

Question

可能重复：
Why does base64 encoding requires padding if the input length is not divisible by 3?

引用Wikipedia:

...这些填充字符必须然后 解码时被丢弃但仍然 允许计算有效 未编码文本的长度，当它的 输入二进制长度不会是 3 个字节的倍数。 ...

但是即使去掉填充字符，也可以很容易地完成原始数据长度的计算。

          |               Encoded
          |--------------------------------------
Raw Size  | Total Size | Real Size | Padding Size
1         | 4          | 2         | 2
2         | 4          | 3         | 1
3         | 4          | 4         | 0
4         | 8          | 6         | 2
5         | 8          | 7         | 1
6         | 8          | 8         | 0
7         | 12         | 10        | 2
8         | 12         | 11        | 1
9         | 12         | 12        | 0
10        | 16         | 14        | 2
.
.
.

因此，鉴于实际编码大小（第三列），您始终可以正确猜测填充大小是多少：

PaddedSize = 4 * Ceil (RealSize / 4)

所以理论上，不需要填充。算法会处理它。考虑到 Base64 编码是一种流行的行业标准，它被用于许多应用程序和设备中。这些将受益于减少的编码大小。那么问题来了，为什么在 Base64 编码中使用填充？

Answer 1

Base64 是旧的，并且来自可用 RAM 和 CPU 受到限制的日子。 此外，编写软件也更加复杂（与 80 年代或 90 年代相比，今天的 SDK 和工具包非常对用户更加友好）并且 Base64 必须在许多不同的系统架构上运行。

也就是说，开发人员可以假设“真实”数据在解码 Base64 数据后大约有 n 个字节长；这反过来又让他/她能够更好地管理内存。

今天已经不重要了，但是在资源有限的时代，这是一件好事。

更新：从没想过我会在 5 年后投反对票，但现在我可以看到我的回答存在问题。我想我们都会变老。 ;) 亲爱的访客，请尽情享受这个答案。

Answer 2

正如您所注意到的，无论消息的长度如何，结尾填充的长度最多为 2 个字节，因此这并不是真正重要的节省 - 更多的是微优化。如果您的应用程序既是编码的生产者又是消费者，您可以去掉填充，但这并不值得这么麻烦。

Answer 3

它使编码的消息成为 4 个字符的整数倍。这可能会使编写解码器稍微容易一些。您可以以 4 个块为单位加载和处理字符并将它们转换为 3 个输出字符，并且填充使执行此操作变得容易，而不会超出字符串的末尾。