SQL Server德语变音字符SHA256哈希计算结果不匹配问题

哈希算法的计算对象是原始字节序列，跨平台结果不一致的核心原因是字符编码不统一：

• 你当前SQL语句中的字符串字面量'ö'未加N前缀，属于非Unicode的VARCHAR类型，SQL Server会使用数据库默认代码页对其编码。德语变音ö不属于ASCII字符，在不同代码页下对应的字节值完全不同。
• 纯ASCII字符o在绝大多数单字节代码页、UTF-8编码下的字节值完全一致，所以不带变音的场景下结果能和其他平台匹配。
• Snowflake、Python及通用在线哈希工具默认使用UTF-8编码处理输入字符，ö对应的UTF-8字节序列为0xC3B6，而你当前SQL Server环境中非Unicode编码的ö对应字节和该值不匹配，最终导致哈希结果差异。

你可以执行以下语句直接验证字节差异：

-- 查看非Unicode编码下ö的字节
SELECT CAST('ö' AS VARBINARY(MAX)) AS NonUnicodeBytes
-- 查看UTF-8编码下ö的字节
SELECT CAST(CAST(N'ö' AS VARCHAR(MAX)) COLLATE Latin1_General_100_CI_AS_SC_UTF8 AS VARBINARY(MAX)) AS UTF8Bytes

根据你使用的SQL Server版本选对应写法即可，计算结果会和其他平台完全对齐。

方案1：原生UTF-8支持（SQL Server 2019及以上版本） #

直接将输入字符串显式转换为UTF-8编码的VARCHAR类型后再计算哈希，写法最简单：

-- 正确计算带变音字符的SHA256，对齐其他平台UTF-8结果
SELECT CONVERT(VARCHAR(MAX), HASHBYTES('SHA2_256', CAST(N'ö' AS VARCHAR(MAX)) COLLATE Latin1_General_100_CI_AS_SC_UTF8), 2) AS HASH_ID

执行返回值为6DBD11FD012E225B28A5D94A9B432BC491344F3E92158661BE2AE5AE2B8B1AD8，和其他平台结果一致。

方案2：兼容低版本（SQL Server 2019以下所有版本） #

老版本没有原生UTF-8排序规则，可以通过逐位转换Unicode码点生成UTF-8字节序列后计算哈希：

DECLARE @Input NVARCHAR(MAX) = N'ö'
DECLARE @UTF8 VARBINARY(MAX) = 0x

;WITH NumSeq AS (
    SELECT Number FROM master..spt_values WHERE Type = 'P' AND Number BETWEEN 1 AND LEN(@Input)
),
CodePoints AS (
    SELECT UNICODE(SUBSTRING(@Input, Number, 1)) AS CP FROM NumSeq
)
SELECT @UTF8 = @UTF8 + 
    CASE WHEN CP < 0x80 THEN CAST(CP AS BINARY(1))
         WHEN CP < 0x800 THEN CAST(0xC0 + CP/64 AS BINARY(1)) + CAST(0x80 + CP%64 AS BINARY(1))
         ELSE CAST(0xE0 + CP/4096 AS BINARY(1)) + CAST(0x80 + (CP/64)%64 AS BINARY(1)) + CAST(0x80 + CP%64 AS BINARY(1))
    END
FROM CodePoints

SELECT CONVERT(VARCHAR(MAX), HASHBYTES('SHA2_256', @UTF8), 2) AS HASH_ID

• 所有包含非ASCII字符的字符串字面量，必须加N前缀声明为Unicode类型（NVARCHAR），避免被数据库默认代码页转码产生乱码
• 跨系统对齐哈希值的前提是提前统一约定字符串编码，生产场景优先选择UTF-8作为统一编码标准

内容的提问来源于stack exchange，提问作者Charles Joseph