为什么在Base64编码中使用填充？

Question

  

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

引用Wikipedia：

  

...这些填充字符必须   在解码但是仍然被丢弃   允许计算有效   未编码文本的长度，当它的时候   输入二进制长度不是a   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

它使编码消息为4个字符的整数倍。这可能会使编写解码器更容易一些。您可以加载和处理4个块中的字符并将它们转换为3个输出字符，并且填充可以很容易地完成此操作而不会离开字符串的末尾。

Answer 2

正如您所注意到的，无论消息的长度如何，最终填充的长度最多为2个字节，因此它不是一个非常重要的节省 - 更多的是微优化。如果你的应用程序既是编码的生产者也是消费者，你可以去除填充，但这不值得麻烦。

Answer 3

Base64很老，来自可用内存和CPU限制的日子。 编写软件也更复杂（与80年代或90年代相比，今天的SDK和工具包 更加用户友好），而Base64必须在许多不同的系统架构上运行。

也就是说，开发人员可以假设解码Base64数据后的“真实”数据大约是 n 字节;这反过来又让他/她做了更好的记忆管理。

今天它不再重要了，但是在资源有限的那一天，这是一件好事。

更新：从未想过5年后我会得到一个downvote，但现在我可以看到我的回答问题。我猜我们都变老了。 ;）亲爱的访客，享受这个答案的一粒盐。