为什么base64编码的字符串在结尾有一个=号

它作为填充。

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

从维基百科:

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

因此，这是某种填充。

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

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

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

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

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

http://www.hcidata.info/base64.htm < a href = " http://www.hcidata.info/base64.htm " > < / >

将“Mary had”编码为64进制

在这个例子中，我们使用了一个简单的文本字符串(“Mary had”)，但无论数据是什么(例如图形文件)，原则都是成立的。为了将每个24位的输入数据转换为32位的输出数据，Base 64编码将24位分割为4个6位的块。我们注意到的第一个问题是“Mary had”不是3字节的倍数——它是8字节长。因此，最后一组比特只有4比特长。为了解决这个问题，我们增加了两个额外的“0”位，并在末尾加上一个“=”来记住这个事实。如果要转换为Base 64的文本字符串有7个字节长，那么最后一组将有2位。在这种情况下，我们会增加4个额外的“0”位，并通过在最后加上“==”来记住这一点。

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

答:不是。(单词usb是base64编码到dXNi中)

Q为什么=会被附加在结尾?

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

例子:

(一)如果你想编码

英语字母 & lt; =比;[__abc0] [__abc1] [__abc2]

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

[ABC] =比;QUJD

[DEF] =比;REVG

[G] =比;Rw==

如果你想编码ABCDEFGH <=>[__abc0] [__abc1] [__abc2]

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

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

[ABC] =比;QUJD

[DEF] =比;REVG

[GH] =比;R0g=

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

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

等号或双等号用作填充。它是在RFC2045中定义的一个愚蠢的概念，实际上是多余的。任何递减解析器都可以在不知道填充的情况下对base64字符串进行编码和解码，只需计算字符数，如果size不能分别被3或4整除，则填充其余的字符。这实际上会时不时地导致一些困难，因为一些解析器期望填充，而另一些解析器则公然忽略它。例如，我的MPU base64解码器需要填充，但它通过网络接收到一个无填充的base64字符串。这导致了错误的解析，我不得不自己解释。