为什么这么多散列和加密的字符串以等号结尾？

我在C＃和MSSQL中工作，并且正如您期望的那样，我将密码存储为盐值和哈希值。

当我查看存储在nvarchar列中的哈希（例如，开箱即用的aspnet成员资格提供程序）时。我一直很好奇为什么生成的Salt和Hash值总是以一个或两个等号结尾。

在使用加密算法时，我已经看到了类似的事情，这是巧合还是有原因？

hashing character-encoding

— 谎言
source

顺便说一句，如果您要在NVARCHAR字段中存储Base64编码的二进制数据，我会为您的6倍存储浪费而哭泣！例如，Base64只能在ASCII的下半部分包含64个字符（因此，您只需要VARCHAR即可保存一半）。对于两个而言，Base64将数据的每个字节分解为1-4个字符。SQL Server已经具有一个VARBINARY类型，该类型完全能够存储您的散列而不会因编码而膨胀，并且在比较中不关心排序... :-)

— jimbobmcgee

@WillieWheeler，哈希必须以某种方式存储。Base64可能不是完美的存储介质，但是它本质上没有错。如果hash("my password")生成数组[1,2,3,4,5]并且我需要将这些值存储在数据库中，则比存储字符串有更糟糕的选择AQIDBAU=（当然，如果使用的哈希函数已经在生成字符串，那么对Base64进行编码似乎有点愚蠢。）

— Brian S

@WillieWheeler我认为您错过了重点。重新阅读Brian S编写的内容-他不是在谈论散列的base64属性-那将是荒谬的base64不是散列算法。他说以base64格式存储哈希（由哈希函数/算法生成）没有错。

— Andrew Savinykh 2014年

OP表示，他存储哈希，哈希以等号结尾。这表明他将散列与Base64编码混淆了。如果要说的是用base64编码哈希是可以的，那当然可以，但是这和什么有什么关系呢？

— 威利·惠勒

是的，我终于意识到发生了什么事。我查看了我的SSH公钥和私钥文件，发现它们也有= / ==结尾。这些是字节数组的base64编码，例如BrianS和zespri描述。多谢你们。

— 威利·惠勒

这些散列的字符串（通常是？）以Base64格式编码，等号用于对字符串进行填充，以使长度（字节数）可被3整除。Wikipedia对此进行了很好的解释：http : //en.wikipedia.org/wiki/Base64。

— 斯文斯拉加尔
source

难道是Base 64编码填充？

“ ==”序列指示最后一组仅包含一个字节，而“ =”指示其包含两个字节。下面的示例说明了如何截断以上所有引号的输入会如何更改输出填充：

http://en.wikipedia.org/wiki/Base64#Output_padding

— 杰迪
source