在base64编码中填充的目的是什么.以下是维基百科的摘录:
"分配了一个额外的填充字符,可用于强制编码输出为4个字符的整数倍(或等效于未编码的二进制文本不是3个字节的倍数);这些填充字符必须在解码时丢弃,但仍然允许计算未编码文本的有效长度,当其输入二进制长度不是3个字节的倍数时(最后一个非填充字符通常被编码,使得它代表的最后一个6位块将为零在其最低有效位上填充,在编码流的末尾最多可能出现两个填充字符."
我写了一个程序,它可以base64编码任何字符串并解码任何base64编码的字符串.填充解决了什么问题？
TJM*_*TJM 167
你不需要填充的结论是正确的.始终可以根据编码序列的长度明确地确定输入的长度.
但是,填充在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.
为什么不设计协议为每个单词添加整数长度？然后接收器可以正确解码流,不需要填充.
这是一个好主意,只要我们在开始编码之前知道我们编码的数据的长度.但是,如果我们从现场摄像机编码视频块而不是文字呢？我们可能事先不知道每个块的长度.
如果协议使用填充,则根本不需要传输长度.数据可以在从摄像机进入时进行编码,每个块都用填充终止,接收器能够正确解码流.
显然这是一个非常人为的例子,但也许它说明了为什么填充在某些情况下可能会有所帮助.
Zam*_*col 32
填充字符有助于满足长度要求并且没有任何意义.
填充的十进制示例: 给定任意要求所有字符串的长度为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
Rom*_*kov 13
在现代，它没有多大好处。因此，让我们将此视为最初的历史目的可能是什么的问题。
Base64 编码首次出现在1993 年的RFC 1421中。该 RFC 实际上专注于加密电子邮件，并且 Base64 在一小节 4.3.2.4中进行了描述。
该 RFC 没有解释填充的目的。最接近我们最初目的的是这句话：
完整的编码量始终在消息末尾完成。
它不建议串联（此处的最佳答案），也不建议将易于实现作为填充的明确目的。然而，考虑到整个描述，假设这可能是为了帮助解码器以 32 位单元（“量子”）读取输入，这并不是没有道理的。这在今天没有任何好处，但在 1993 年，不安全的 C 代码很可能实际上利用了这个特性。
通过填充，base64 字符串的长度始终是 4 的倍数（如果不是，则字符串肯定已损坏），因此代码可以轻松地在一次处理 4 个字符的循环中处理该字符串（始终将 4 个输入字符转换为 3 个或更少的输出字节）。因此，填充使完整性检查变得容易（length % 4 != 0==>填充不可能出现错误），并且它使处理更简单、更高效。
我知道人们会怎么想：即使没有填充，我也可以在循环中处理所有 4 字节块，然后只需为最后 1 到 3 个字节添加特殊处理（如果存在）。这只是几行额外的代码，速度差异很小，甚至无法测量。可能是这样，但您正在考虑 C（或更高语言）和具有充足 RAM 的强大 CPU。如果您需要使用简单的 DSP 在硬件中解码 Base64，该 DSP 的处理能力非常有限，没有 RAM 存储，并且您必须在非常有限的微汇编中编写代码，该怎么办？如果您根本无法使用代码并且所有事情都必须通过堆叠在一起的晶体管（硬连线硬件实现）来完成，该怎么办？使用填充比不使用要简单得多。