为什么base64编码的字符串末尾有=号
我知道什么是 base64 编码以及如何在 C# 中计算 base64 编码，但是我已经多次看到，当我将字符串转换为 base64 时，会出现一个 = 位于最后。
出现了一些问题：
base64字符串是否总是以=结尾？- 为什么最后要添加
=？
I know what base64 encoding is and how to calculate base64 encoding in C#, however I have seen several times that when I convert a string into base64, there is an = at the end.
A few questions came up:
- Does a
base64string always end with=? - Why does an
=get appended at the end?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
问 base64 字符串是否总是以
=结尾？答：不会。（单词
usb是通过 base64 编码成dXNi)问为什么要在末尾附加
=？答：简短回答：
最后一个字符（
=符号）仅在使用特殊字符数对消息进行编码的最终过程中作为补充（填充）添加。如果您的字符串是 3 个字符的倍数，则不会有
=符号，因为Base64编码每三个 字节（一个字符=1字节）并将它们表示为 ASCII 标准中的四个可打印字符。示例：
(a)如果要编码
ABCDEFG <=> [
ABC] [DEF] [G]Base64处理第一个块（产生 4 个字符）和第二（因为它们已完成）。但对于第三个，它将在输出中添加两个==以完成 4 个所需的字符。因此，结果将是 QUJD REVG Rw== （不带空格）。[
ABC] =>QUJD[
DEF] =>REVG[
G] =>Rw==(b) 如果要编码ABCDEFGH <=> [
ABC] [DEF] [GH]同样，它会在输出末尾添加一个
=获得 4 个字符。结果将是 QUJD REVG R0g= （不带空格）。
[
ABC] =>QUJD[
DEF] =>REVG[
GH] =>R0g=Q Does a base64 string always end with
=?A: No. (the word
usbis base64 encoded intodXNi)Q Why does an
=get appended at the end?A: As a short answer:
The last character (
=sign) is added only as a complement (padding) in the final process of encoding a message with a special number of characters.You will not have an
=sign if your string has a multiple of 3 characters, becauseBase64encoding takes each three bytes (a character=1 byte) and represents them as four printable characters in the ASCII standard.Example:
(a) If you want to encode
ABCDEFG <=> [
ABC] [DEF] [G]Base64deals with the first block (producing 4 characters) and the second (as they are complete). But for the third, it will add a double==in the output in order to complete the 4 needed characters. Thus, the result will be QUJD REVG Rw== (without spaces).[
ABC] =>QUJD[
DEF] =>REVG[
G] =>Rw==(b) If you want to encode ABCDEFGH <=> [
ABC] [DEF] [GH]similarly, it will add one
=at the end of the output to get 4 characters.The result will be QUJD REVG R0g= (without spaces).
[
ABC] =>QUJD[
DEF] =>REVG[
GH] =>R0g=它用作填充。
更完整的答案是，base64 编码的字符串并不总是以
=结尾，它只会以一个或两个=结尾，如果他们需要将字符串填充到适当的长度。It serves as padding.
A more complete answer is that a base64 encoded string doesn't always end with a
=, it will only end with one or two=if they are required to pad the string out to the proper length.来自维基百科：
因此，这是某种填充。
From Wikipedia:
Thus, this is some sort of padding.
如果可用的位少于 24 位，则它在 RFC 2045 中定义为特殊填充字符编码数据的末尾。
Its defined in RFC 2045 as a special padding character if fewer than 24 bits are available at the end of the encoded data.
等号 (=) 在某些形式的 Base64 编码中用作填充。关于 base64 的 维基百科文章 包含所有详细信息。
The equals sign (=) is used as padding in certain forms of base64 encoding. The Wikipedia article on base64 has all the details.
这是填充。来自http://en.wikipedia.org/wiki/Base64：
It's padding. From http://en.wikipedia.org/wiki/Base64:
http://www.hcidata.info/base64.htm
将“Mary had”编码为 Base 64
在此示例中，我们是使用简单的文本字符串（“Mary had”），但无论数据是什么（例如图形文件），原则都成立。为了将每 24 位输入数据转换为 32 位输出，Base 64 编码将 24 位分成 4 个 6 位块。我们注意到的第一个问题是“Mary had”不是 3 字节的倍数 - 它是 8 字节长。因此，最后一组位只有 4 位长。为了解决这个问题，我们添加了两位额外的“0”，并通过在末尾添加“=”来记住这一事实。如果要转换为 Base 64 的文本字符串有 7 个字节长，则最后一组将有 2 位。在这种情况下，我们会添加四个额外的“0”位，并通过在末尾放置“==”来记住这一事实。
http://www.hcidata.info/base64.htm
Encoding "Mary had" to Base 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.
=是一个填充字符。如果输入流的长度不是 3 的倍数，则会添加填充字符。这是解码器所要求的：如果不存在填充，则最后一个字节将具有错误数量的零位。这里有更好更深入的解释：https://base64tool.com/检测是否提供的字符串是base64或不是/
=is a padding character. If the input stream has length that is not a multiple of 3, the padding character will be added. This is required by decoder: if no padding present, the last byte would have an incorrect number of zero bits.Better and deeper explanation here: https://base64tool.com/detect-whether-provided-string-is-base64-or-not/
等于或双等于用作填充。这是 RFC2045 中定义的一个愚蠢的概念，实际上是多余的。任何像样的解析器都可以对 Base64 字符串进行编码和解码，而无需知道填充，只需计算字符数并在大小分别不能被 3 或 4 整除时填充其余部分。这实际上时不时地会带来困难，因为一些解析器期望填充，而另一些解析器则公然忽略它。例如，我的 MPU Base64 解码器需要填充，但它通过网络接收未填充的 Base64 字符串。这会导致解析错误，我必须自己解释。
The equals or double equals serves as padding. It's a stupid concept defined in RFC2045 and it is actually superfluous. Any decent 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 divisible 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 erroneous parsing and I had to account for it myself.