base64编码，以及如何在C＃中计算base64编码，但是我多次看到，将字符串转换为base64时，最后会有一个=。出现了一些问题up：
base64字符串是否总是以=结尾吗？为什么将
=附加到末尾？#1 楼
更完整的答案是，base64编码的字符串并不总是以
=结尾，如果需要将字符串填充出来，则只会以一个或两个=结尾。到适当的长度。评论
“需要填充字符的一种情况是串联多个Base64编码的文件。”
–AndréPuel
2014年11月30日19:41
@AndréPuel：重新同步一个=就足够了。如果您想找到边界，则应该始终存在一个终止符（并且仍然只需要一个字符）。 Base64的整个填充概念只是一个脑袋……
–6502
15年8月20日在19:07
但是，该链接与base64完全无关。
– NH。
17年8月18日在16:25
我只希望发布一个相关且可靠的链接，并通过插图和示例有效地说明有关base64中的填充的信息。 Wikipedia的当前链接与@NH完全无关。提到。
–Fr0zenFyr
19年7月5日在10:48
@ Fr0zenFyr如果您想要一个链接，则en.wikipedia.org/wiki/Base64#Output_padding非常好。但是Badr的答案确实是一个更好的答案（它尚未获得选票）。
– NH。
19年7月9日在18:58
#2 楼
1-否2-简短的回答：
第65个字符（“ =符号”）仅在消息编码的最终过程中用作补充。
如果您的字符串具有3个字符的倍数，则不会有'='符号，因为
Base64编码每三个字节（8位）占用一个字节，并将它们表示为ASCII标准中的四个可打印字符。 详细信息：
（a）如果要编码
ABCDEFG <=> [
ABC] [DEF] [G Base64将处理（产生4个字符）第一个块和第二个块（已完成），但是对于第三个块，它将在输出中添加一个双==以完成所需的4个字符。结果将是QUJD REVG Rw ==（无空格）（b）如果要编码...
ABCDEFGH <=> [
ABC] [DEF] [ GH 类似地，它将在输出末尾仅添加一个
=以获得4个字符结果将是QUJD REVG R0g =（无空格）
评论
这比其他答案甚至Wikipedia更为完整和明确，并且应该比已接受的答案拥有更多的选票，后者仅指向Wikipedia链接。恭喜您！已投票！
– ANewGuyInTown
18年1月30日在23:14
@ANewGuyInTown接受的解决方案中的Wikipedia链接不正确，它与base64上的填充无关。 Legolas在下面的答案中链接了正确的页面
–Fr0zenFyr
19年7月5日在10:55
关于base64填充的另一个很好的（IMHO）相关答案
–spottedmahn
20年1月28日在19:27
#3 楼
摘自Wikipedia：最终的'=='序列指示最后一组仅包含一个字节，而'='指示其包含两个字节。
因此，这是一种填充。
#4 楼
将Base64编码的字符串的长度填充为4个字符的倍数，以便可以正确对其进行解码。
评论
我在最后删除了=，并测试了100万个字符串。解码始终匹配。
–nice_dev
19年4月9日在11:01
#5 楼
如果在编码数据的末尾少于24位，则它在RFC 2045中定义为特殊的填充字符。#6 楼
等号（=）用作base64编码的某些形式的填充。有关base64的Wikipedia文章提供了所有详细信息。评论
您能否解释为什么“ ==”是1个字节而“ =“ =”是2个字节的逻辑？我就是听不懂。怎么输入：“任何肉体的快乐”。可以得到结果“ YW55IGNhcm5hbCBwbGVhc3VyZS4 =“，而“任何狂欢”可以得到结果“ YW55IGNhcm5hbCBwbGVhc3VyZQ ==”？
–空
13年3月21日在6:25
并非'=='是1个字节，'='是2个字节。在这种情况下，您整个字符串中的字节数必须始终为4的倍数。因此，您用'='符号填充，直到得到为止。第一个字符串比第二个字符串多一个字符，因此需要较少的填充'='。
–山姆·霍洛威（Sam Holloway）
13 Mar 27 '13 at 13:31
这个答案应该是评论吗？
–Fr0zenFyr
19年7月5日在10:57
#7 楼
它是填充。从http://en.wikipedia.org/wiki/Base64：理论上讲，不需要填充字符，因为可以丢失丢失的字节数由Base64位数计算得出。在某些实现中，填充字符是强制性的，
而在其他实现中则不使用。需要填充字符
的一种情况是串联多个Base64编码的文件。
评论
关于“需要填充字符的一种情况是串联多个Base64编码的文件”部分。是错的。例如，当连接两个base64文件时，每个文件的源字节为3个字节长，base64字符串将为4个字符长，并且没有填充字节。当您将这两个base64字符串连接在一起时，将无法基于连接的字符串来判断一个在哪里开始，一个在哪里停止。因此，依靠base64填充来解决此问题是行不通的。对于字节长度被3整除的任何文件都会存在此问题。
–罗恩C
17年2月10日在14:51
我想这意味着最终结果应该是输入的串联的情况。例如encode（encode（A）+ encode（B））= A + B可以填充，但不能不填充。
–托马斯·伦纳德
17年2月11日在16:26
也许但是这种有限的使用不允许在将编码字符串串联在一起的一般情况下依赖于填充字符。我仅提及它是为了帮助可能认为他们可以使用它的开发人员。
–罗恩C
17年2月13日在13:52
我认为您的反对意见确实突出了填充和定界概念之间的区别。通常不希望串联的结果包含足够的信息以使其可逆。您不会知道“ c3dpenpsZXJz”最初是“ c3dpenps” +“ ZXJz”还是“ c3dp” +“ enpsZXJz”。但是您也不知道“ swizzlers”最初是“ swi” +“ zzlers”还是“ swizzl” +“ ers”。
–GargantuChet
17年4月21日在21:22
从相关的Base64填充答案中复制我的评论：> Base64串联[带有'='填充]允许编码器并行处理大型块，而无需将块大小对齐为三的倍数。类似地，作为一种实现细节，可能存在一个编码器，该编码器需要刷新内部数据缓冲区，其大小不是三的倍数。
– Andre D
17-09-5在6:39
#8 楼
http://www.hcidata.info/base64.htm将“ Mary had”编码为Base 64
在此示例中，我们使用了一个简单的文本字符串（“ Mary ”），但是无论数据是什么（例如图形文件），该原理都适用。为了将输入数据的每24位转换为32位输出，Base 64编码将24位拆分为4个6位的块。我们注意到的第一个问题是“ Mary have”不是3字节的倍数-它是8字节长。因此，最后一组位只有4位长。为了解决这个问题，我们添加了两个额外的位“ 0”，并在末尾添加“ =”来记住这一事实。如果要转换为Base 64的文本字符串长7个字节，则最后一组将具有2位。在这种情况下，我们将添加四个额外的位“ 0”，并通过在最后放置“ ==”来记住这一事实。
#9 楼
=是一个填充字符。如果输入流的长度不是3的倍数，则将添加填充字符。这是解码器所必需的：如果不存在填充，则最后一个字节将具有不正确的零位数目。此处的详细解释如下：https://base64tool.com/detect-whether-provided-string-is -base64-or-not /
评论
这与C＃完全无关。实际上，它与c＃有关，并非所有语言都包含=，例如许多perl库都省略了=，因此了解用户使用的环境实际上是相关的。
似乎这样会使它在某些情况下成为不太有效的混淆方法，因为它很容易被检测到。
@ user1167442 Base64不能用于混淆。它用于将二进制数据（或带有unicode和其他特殊字符的字符串）作为字符串传输。