Question

我有一个奇怪的情况，当SQL Server的df.groupby(['Val1'])['Val2'].mean()函数在使用包含变音符号（ä，ö，ü，ß）的字符串将其转换为Hashbyte时没有输出正确的结果时）。

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

SHA2_256

结果是：

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

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

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

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

9F86D081884C7D659A2FEAA0C55AD015A3BF4F1B2B0B822CD15D6C15B0F00A08

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

26A45113433596C5DD53643C7652381202E8009E532A280E513D887174A9ED14

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

我感谢任何帮助解决这个问题。

Answer 1

你有这个：

declare @cryptString varchar(50)

您尝试使用它来保存此值：

müller

那很糟糕。对于任何超出基本ascii字符的内容，您需要nvarchar。

但这仅仅适合初学者。 nvarchar uses UTF-16（请参阅标题为＃34;补充字符＆＃34;大约在页面中间的部分）。该网站可能使用UTF-32或（可能）UTF-8来编码这些字符。任何一个都将使用稍微不同的字节表示，这将产生完全不同的哈希值。

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

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

SQL Server：带有元音变音的Hashbytes

1 个答案: