encoding - 如果输入长度不能被3整除,为什么base64编码需要填充?

标签 encoding base64 padding decoding

base64编码中填充的目的是什么。以下是维基百科的摘录:

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

我编写了一个程序,可以对任何字符串进行 Base64 编码并解码任何 Base64 编码的字符串。 padding解决了什么问题?

最佳答案

您认为填充是不必要的结论是正确的。始终可以根据编码序列的长度明确确定输入的长度。

但是,在 Base64 编码的字符串以单个序列的长度丢失的方式连接的情况下(例如在非常简单的网络协议(protocol)中可能发生的情况),填充非常有用。

如果连接未填充的字符串,则无法恢复原始数据,因为每个单独序列末尾的奇数字节数信息都会丢失。但是,如果使用填充序列,则不会出现歧义,并且整个序列可以正确解码。

编辑:插图

假设我们有一个程序,可以对单词进行 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

为什么要费心填充?

为什么不直接设计协议(protocol)为每个单词添加整数长度前缀呢?然后接收器可以正确解码流并且不需要填充。

这是一个好主意,只要我们在开始编码之前知道要编码的数据的长度即可。但是,如果我们不是对文字进行编码,而是对来自实时摄像机的视频 block 进行编码呢?我们可能事先不知道每个 block 的长度。

如果协议(protocol)使用填充,则根本不需要传输长度。数据可以在从相机传入时进行编码,每个 block 都以填充终止,并且接收器将能够正确解码流。

显然,这是一个非常人为的示例,但也许它说明了为什么填充在某些情况下可能会有所帮助。

关于encoding - 如果输入长度不能被3整除,为什么base64编码需要填充?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/4080988/

相关文章:

html - 如何对验证的输入[类型 ="submit"] 的值进行编码

c# - 将图像转换为数据 :image/png;base64 for web page disaplay

javascript - 用户另存为时如何控制base64图像

php - PHP 中的捷克语字符编码

python - 如何打印变量中包含的 unicode 字符串的值

javascript - 不熟悉的字符串编码(Base64?) - 尝试保存和使用 .3gp 文件的字符串内容

java - java中有没有可用的正则表达式来识别字符串是否是base64编码的?

css - 按钮填充太大

html - 你能调整 HTML 输入按钮的左右内边距吗?

没有填充的 Java AES