不。 将base64编码的字符串填充为长度为4个字符的倍数，以便能够正确解码。

不。 将base64编码的字符串填充为长度为4个字符的倍数，以便能够正确解码。

这是填充。从http://en.wikipedia.org/wiki/Base64:

理论上，解码不需要填充字符，因为 缺失的字节数可以从Base64的数目计算出来 位数。在某些实现中，填充字符是强制的， 而对另一些人则不使用。填充字符的一种情况 需要连接多个Base64编码的文件。

The equals or double equals serves as padding. It's a stupid concept defined in RFC2045 and it is actually superfluous. Any decend parser can encode and decode a base64 string without knowing about padding by just counting up the number of characters and filling in the rest if size isn't dividable by 3 or 4 respectively. This actually leads to difficulties every now and then, because some parsers expect padding while others blatantly ignore it. My MPU base64 decoder for example needs padding, but it receives a non-padded base64 string over the network. This leads to erronous parsing and I had to account for it myself.

它在RFC 2045中定义为一个特殊的填充字符，如果在编码数据的末尾可用的比特数少于24位。

问:base64字符串总是以=结尾吗?

答:不是。(usb字是base64编码到dXNi)

问:为什么an =要加在后面?

答:简而言之: 最后一个字符(=符号)仅作为补码(填充)添加到使用特定字符数对消息进行编码的最后过程中。

如果字符串有3个字符的倍数，则不会有=号，因为Base64编码每3个字节(一个字符=1字节)，并在ASCII标准中将它们表示为4个可打印字符。

例子:

(a)如果你想编码

Abcdefg <=> [abc] [def] [g]

Base64处理第一个块(产生4个字符)和第二个块(当它们完整时)。但对于第三个，它将在输出中添加一个double ==，以完成4个所需字符。因此，结果将是QUJD REVG Rw==(不含空格)。

[ABC] => QUJD

[DEF] =>快节奏

[G] => Rw==

(b)如果你想编码ABCDEFGH <=> [ABC] [DEF] [GH]

类似地，它将在输出的末尾添加one =以获得4个字符。

结果将是QUJD REVG R0g=(不带空格)。

[ABC] => QUJD

[DEF] =>快节奏

[GH] => R0g=