如果输入长度不能被3整除，为什么base64编码需要填充？


Why does base64 encoding require padding if the input length is not divisible by 3?

在base64编码中填充的目的是什么？以下是维基百科的摘录：

"分配了一个额外的填充字符，用于将编码输出强制为4个字符的整数倍(或当未编码的二进制文本不是3个字节的倍数时等效)；然后在解码时必须丢弃这些填充字符，但仍允许计算未编码文本的有效长度，当它的输入二进制长度不是3字节的倍数时(最后一个非填充字符通常被编码，这样它所代表的最后一个6位块将被零填充在它的最低有效位上，最多两个填充字符可能出现在编码流的末尾)。

我编写了一个程序，它可以对任何字符串进行base64编码，并对任何base64编码的字符串进行解码。填充解决了什么问题？

你认为填充是不必要的结论是对的。总是可以从编码序列的长度中明确地确定输入的长度。

但是，在base64编码的字符串以这样一种方式连接的情况下，填充很有用，即单个序列的长度会丢失，例如，在非常简单的网络协议中可能会发生这种情况。

如果连接了未添加的字符串，则无法恢复原始数据，因为每个序列末尾的奇数字节数信息将丢失。但是，如果使用填充序列，就不会有歧义，而且整个序列可以正确解码。

编辑：插图

假设我们有一个程序，base64对单词进行编码，连接它们并通过网络发送它们。它对"i"、"am"和"tjm"进行编码，将结果夹在一起而不加填充，并将其传输。

  • I编码到SQ(SQ==带填充)
  • AM编码到QU0(QU0=带填充)
  • TJM编码到VEpN(VEpN带填充)

所以传输的数据是SQQU0VEpN。接收器base64将其解码为I\x04\x14\xd1Q)，而不是预期的IAMTJM。结果是无意义的，因为发送者已经销毁了每个单词在编码序列中的结尾信息。如果发送方发送了SQ==QU0=VEpN，那么接收者可以将其解码为三个单独的base64序列，这些序列将连接起来以得到IAMTJM。

为什么要用衬垫？

为什么不设计一个协议来给每个单词加上一个整数长度的前缀呢？然后接收器可以正确地解码流，不需要填充。

这是一个好主意，只要我们知道在开始编码之前要编码的数据的长度。但是，如果我们不是用文字，而是用现场摄像机来编码视频块呢？我们可能事先不知道每个块的长度。

如果协议使用填充，则根本不需要传输长度。当数据从相机中传入时，可以对其进行编码，每个数据块都以填充结束，并且接收器能够正确地对数据流进行解码。

显然，这是一个非常做作的例子，但也许它说明了为什么填充在某些情况下可能有用。

相关讨论

什么是填充字符？

填充字符有助于满足长度要求，没有任何意义。

填充的十进制示例：如果任意要求所有字符串的长度都为8个字符，则数字640可以满足此要求，使用前面的0作为填充字符，因为它们没有任何含义，"00000640"。

二进制编码

字节范式：字节是事实上的标准度量单位，任何编码方案都必须与字节相关。

base256正好符合这个范例。一个字节等于base256中的一个字符。

十六进制或十六进制，每个字符使用4位。一个字节可以表示两个base16字符。

与base256和base16不同，base64不能均匀地适应字节范式。所有base64字符都可以用6位表示，比完整字节短2位。

我们可以用分数来表示base64编码和字节范式：每个字符6位，每个字节8位。这个分数减少了3个字节，超过4个字符。

这个比率，每4个base64字符3个字节，是我们在编码base64时要遵循的规则。base64编码甚至只能保证使用3个字节的数据包进行测量，而base16和base256的每一个字节都可以独立存在。

所以为什么鼓励填充，即使没有填充字符编码也可以很好地工作？填充字符明确地表示，这些额外的点应该是空的，并且排除了任何模糊性或潜在的令人讨厌的错误。填充允许我们解码base64编码，保证不会丢失位。如果没有填充，就不能再明确地确认在三个字节的包中进行测量，而且如果没有额外的信息，我们就不能再保证原始编码的精确复制。

实例

以下是RFC 4648的示例(http://tools.ietf.org/html/rfc4648第8节)

"base64"函数中的每个字符使用一个字节(base256)。然后我们把它转换成base64。

1
2
3
4
5
6
7
BASE64("")       =""           (No bytes used. 0%3=0.)
BASE64("f")      ="Zg=="       (One byte used. 1%3=1.)
BASE64("fo")     ="Zm8="       (Two bytes. 2%3=2.)
BASE64("foo")    ="Zm9v"       (Three bytes. 3%3=0.)
BASE64("foob")   ="Zm9vYg=="   (Four bytes. 4%3=1.)
BASE64("fooba")  ="Zm9vYmE="   (Five bytes. 5%3=2.)
BASE64("foobar") ="Zm9vYmFy"   (Six bytes. 6%3=0.)

下面是一个编码器，您可以使用它来玩：http://www.motobit.com/util/base64-decoder-encoder.asp

相关讨论

这只是我的一个理论，我不能提供任何来源，但我认为填充字符只能使解码算法的一些实现变得简单一点。特别是，如果算法将编码的字符串放入类似于int[]的东西中，那么最终值有时会太长。

如果填充已经存在于输入中，那么不需要做任何其他事情-算法只需读取和解码输入。

但是，如果算法不允许假定存在填充，并且它使用类似于int[]的数据结构，则需要在解码前手动填充最终整数，或者对输入的原始长度进行一些额外的记帐。

我个人认为填充不再有任何作用，但是回到CPU和RAM没有现在那么丰富的时候，这种轻微的优化可能已经很重要了。但我怀疑这很重要…当FED输入被随机截断时，一个好的实现仍然需要做一些明智的事情，而IMO将给予处理未添加输入的能力，而不需要额外的成本。

相关讨论