我知道什么是base64编码,以及如何在c#中计算base64编码,但是我已经看到过几次,当我将一个字符串转换为base64时,在结尾有一个=。
他提出了几个问题:
base64字符串总是以=结尾吗? 为什么an =要加在后面?
我知道什么是base64编码,以及如何在c#中计算base64编码,但是我已经看到过几次,当我将一个字符串转换为base64时,在结尾有一个=。
他提出了几个问题:
base64字符串总是以=结尾吗? 为什么an =要加在后面?
当前回答
不。 将base64编码的字符串填充为长度为4个字符的倍数,以便能够正确解码。
其他回答
它起到填充的作用。
一个更完整的答案是,base64编码的字符串并不总是以一个=结尾,如果需要将字符串填充到适当的长度,它只会以一个或两个=结尾。
这是填充。从http://en.wikipedia.org/wiki/Base64:
理论上,解码不需要填充字符,因为 缺失的字节数可以从Base64的数目计算出来 位数。在某些实现中,填充字符是强制的, 而对另一些人则不使用。填充字符的一种情况 需要连接多个Base64编码的文件。
=是填充字符。如果输入流的长度不是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.
从维基百科:
最后的'=='序列表示最后一组只包含一个字节,'='表示它包含两个字节。
因此,这是某种填充。