它起到填充的作用。

一个更完整的答案是，base64编码的字符串并不总是以一个=结尾，如果需要将字符串填充到适当的长度，它只会以一个或两个=结尾。

从维基百科:

最后的'=='序列表示最后一组只包含一个字节，'='表示它包含两个字节。

因此，这是某种填充。

等号(=)在某些形式的base64编码中用作填充。关于base64的维基百科文章有所有的细节。

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

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

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

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

http://www.hcidata.info/base64.htm

将“Mary had”编码为64进制

In this example we are using a simple text string ("Mary had") but the principle holds no matter what the data is (e.g. graphics file). To convert each 24 bits of input data to 32 bits of output, Base 64 encoding splits the 24 bits into 4 chunks of 6 bits. The first problem we notice is that "Mary had" is not a multiple of 3 bytes - it is 8 bytes long. Because of this, the last group of bits is only 4 bits long. To remedy this we add two extra bits of '0' and remember this fact by putting a '=' at the end. If the text string to be converted to Base 64 was 7 bytes long, the last group would have had 2 bits. In this case we would have added four extra bits of '0' and remember this fact by putting '==' at the end.

问: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=

=是填充字符。如果输入流的长度不是3的倍数，则填充字符将被添加。这是解码器所要求的:如果没有填充，最后一个字节将有一个不正确的零位数。

更好更深入的解释在这里:https://base64tool.com/detect-whether-provided-string-is-base64-or-not/

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.