在base64编码中填充的目的是什么。以下是维基百科的摘录:
“分配了一个额外的填充字符,可用于强制编码输出为4个字符的整数倍(或等效于未编码的二进制文本不是3个字节的倍数);然后必须丢弃这些填充字符当解码但仍允许计算未编码文本的有效长度时,其输入二进制长度不是3字节的倍数(最后一个非填充字符通常被编码,以便它代表最后的6位块将在其最低有效位上进行零填充,在编码流的末尾最多可能出现两个填充字符。“
我编写了一个程序,它可以对任何字符串进行base64编码并解码任何base64编码的字符串。填充解决了什么问题?
答案 0 :(得分:137)
您的结论是填充是不必要的是正确的。始终可以根据编码序列的长度明确地确定输入的长度。
然而,填充在base64编码的字符串以这样的方式连接的情况下是有用的,即单个序列的长度丢失,例如,在非常简单的网络协议中可能发生。
如果连接了 unpadded 字符串,则无法恢复原始数据,因为有关每个单独序列末尾的奇数字节数的信息会丢失。但是,如果使用填充序列,则没有歧义,整个序列可以正确解码。
假设我们有一个程序对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
。
为什么不设计协议为每个单词添加整数长度?然后接收器可以正确解码流,不需要填充。
这是一个好主意,只要我们在开始编码之前知道我们编码的数据的长度。但是,如果我们从现场摄像机编码视频块而不是文字呢?我们可能事先不知道每个块的长度。
如果协议使用填充,则根本不需要传输长度。数据可以在摄像机进入时进行编码,每个块都用填充结束,接收器可以正确解码流。
显然这是一个非常人为的例子,但也许它说明了为什么在某些情况下填充可能会有所帮助。
答案 1 :(得分:28)
填充字符有助于满足长度要求并且没有任何意义。
填充的十进制示例: 给定任意要求所有字符串的长度为8个字符,数字640可以满足此要求,使用前面的0作为填充字符,因为它们没有任何含义,“00000640”。
字节范例:字节是事实上的标准测量单位,任何编码方案都必须与字节有关。
Base256 完全符合此范例。一个字节等于base256中的一个字符。
Base16 ,十六进制或十六进制,每个字符使用4位。一个字节可以表示两个base16字符。
与base256和base16不同,Base64 不能均匀地适应字节范例。所有base64字符都可以用6位表示,比完整字节短2位。
我们可以将base64编码与字节范例表示为分数:每字符6位,每字节8位。减少这个分数是超过4个字符的3个字节。
这个比率,每4个base64个字符3个字节,是我们在编码base64时要遵循的规则。 Base64编码只能承诺使用3字节包进行测量,与base16和base256不同,其中每个字节都可以独立存在。
所以为什么是鼓励填充,即使编码可以正常工作而没有填充字符?填充字符明确地表明这些额外的点应该是空的并排除任何歧义或可能令人讨厌的错误。填充允许我们解码base64编码,承诺没有丢失的比特。如果没有填充,则不再明确承认三字节包中的测量,并且我们无法再保证在没有附加信息的情况下精确再现原始编码。
以下是RFC 4648(http://tools.ietf.org/html/rfc4648#section-8)
的示例表单“BASE64”函数中的每个字符都使用一个字节(base256)。然后我们将其翻译为base64。
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
答案 2 :(得分:3)
这只是我的理论,我不能提供任何来源,但我认为填充字符只能使解码算法的某些实现 最小< / em>有点简单。特别是,如果算法将编码的字符串放入int[]
之类的内容中,那么最终值有时会太长。
如果输入中已存在填充,则无需其他任何操作 - 算法只能读取和解码输入。
如果不允许算法假设填充存在,和它使用int[]
- 如数据结构,然后需要手动在解码之前填充最后一个整数,或者对输入的原始长度做一些额外的记录。
我个人认为填充不再用于任何目的,但当CPU和RAM不像现在那么丰富时,这种轻微的优化可能很重要。我怀疑这一点很重要但是......当输入被随机截断的输入时,一个好的实现仍然需要做一些合理的事情,并且IMO将能够无需额外费用处理未填充的输入。