1

我发现了一个奇怪的情况，当 SQL Server 的函数在将其转换为包含变音符号 (ä,ö,ü,ß) 的字符串Hashbyte时没有输出正确的结果。SHA2_256

我在 SQL Server 中运行示例代码：

 declare @cryptString varchar(50) 
 set @cryptString = 'test'

 select convert(Varchar(64), Hashbytes('SHA2_256', @cryptstring), 2)

结果是：

9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08

当我在https://hashgenerator.de/上检查 SHA256 转换时，结果是一样的。

我的问题：当我尝试加密例如“müller”时，SQL Server 中的结果是：

26A45113433596C5DD53643C7652381202E8009E532A280E513D887174A9ED14

当我在https://hashgenerator.de/上检查 SHA256 转换时，结果不同。

2dbd218072117713f2d5996a726a9b216ed791ffd0783b6ba4ab6d61b8333192

我认为这可能是一个编码问题，但我搜索了几个小时，找不到任何线索来解决这个问题。

我感谢任何形式的帮助来解决这个问题。

4

1 回答 1

1

你有这个：

declare @cryptString varchar(50)

你尝试用它来保存这个值：

müller

那很糟。nvarchar对于任何可能超出基本 ascii 字符的内容，您都需要一个。

但这只是初学者。nvarchar使用 UTF-16（请参阅页面一半左右标题为“补充字符”的部分）。该网站可能使用 UTF-32 或（可能）UTF-8 对这些字符进行编码。任何一个都将使用稍微不同的字节表示，这将产生完全不同的哈希值。

我相信您在https://hashgenerator.de/看到了 UTF-8 ，因为 UTF-8 在仅使用 ASCII 字符时匹配 ASCII。使用 UTF-8，简单的值 liketest会为网站和数据库产生相同的结果。

要解决此问题，请了解 SQL 哈希将使用 ASCII 或 UTF-16，因此您必须在您使用的任何其他平台上更改编码以匹配数据库。最简单的选择可能是始终对这些值使用 UTF-16，但您也可以选择坚持使用varchar数据库并将文本转换为 ascii，然后再计算其他地方的哈希（要知道您会失去一些保真度）。

于 2017-12-01T20:08:44.387 回答