问题标签 [hashbytes]

我正在使用 SQL Server 2014。作为更大任务的一部分，我需要从表中检测更新等，因此我正在实现 Hashbytes。Hasbytes 字段定义为varbinary(MAX)。

这是我的 SQL：

但是，我只是不断收到错误：

'MD5' 附近的语法不正确。

我哪里错了？

我们的旧 sql 遗留代码之一，使用 HASHBYTES 函数和 sha2_256 转换 sql 中的数字列。

整个过程正在转向 python，因为我们在遗留工作的基础上进行了一些高级用法。但是，当使用连接器时，我们调用的是相同的 sql 代码，HASHBYTES('sha2_256',column_name) id 返回值很多垃圾。

在sql中运行代码会导致这个

从 python 运行相同的 sql 查询会导致

b"z\xc8+'y\x11o@\xa8\xce\xa0\xd8[\xe4\xaa\x02\xaf\x7f\x81;S\x83\xba\xc6\r^q\xb7\xbd\xb9\ xf7\x05"

代码是

我尝试过通常的垃圾清除但没有帮助

当我使用非英文字符时，生成的哈希值不一样，但除此之外，一切都很好。有没有人有解决方案来获得相同的结果？

MYSQL

SQL 服务器

我遇到了一个超出我的谷歌搜索能力的问题，如果有任何帮助，我将不胜感激。

我创建了一个非常简单的 SSIS 包，用于使用 OLEDB 连接将数据从 Azure SQL 数据库中的源表复制到 MS SQL 数据库中的目标。目标表是从源数据库生成的脚本创建的（在 SSMS 中，我右键单击数据库名称 -> 任务 -> 生成脚本），因此它们应该是相同的。SSIS 包不进行任何转换——它是对目标表的简单截断，然后是具有连接到 OleDBDestination 的 OleDBSource 的数据流任务。

但是，我在执行包时收到以下错误：

所讨论的主键列的数据类型为 char(32)，并使用 HASHBYTES 函数使用“SHA2_256”算法生成。错误消息给出了一个错误的主键示例，基本上是一系列空格。当我查看 Source 表时，看起来确实有多行，其中主键只是一系列空格。但我猜 Azure SQL 可以以某种方式区分它们，因为 Source 表上没有主键问题。只有当我尝试将数据复制到本地 MS SQL Server 数据库时，我才会遇到主键违规。

我尝试过的事情：

1. 检查源和目标表列、数据库和服务器上的排序规则设置是否相同。

2. 检查 SSIS 数据流源和目标的高级编辑器以确保代码页相同。

3. 删除目标表上的主键约束，然后使用 SSIS 移动数据，然后运行查询以比较 SSIS 传输的哈希值与完全生成新哈希值。对于大约 8% 的表，SQL Server 认为传输的散列与新散列不匹配，尽管散列通常看起来相似。这是查询：

基于#3，我的猜测是发生以下情况之一：

1. SSIS 在将数据从源复制到目标时以某种方式转换哈希。

2. 目标列/表/数据库具有一些设置，使其存储 char(32) 数据的方式与源列/表/数据库不同。

3. 某种错误。

任何人有任何经验可以帮助阐明这个问题吗？

我正在关注这个问题的简单示例：

它返回一个正确的散列值：K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=

现在我尝试按照 Microsoft Hashbytes 文档示例将 secret 声明为变量：

它返回一个错误的哈希：

有没有办法将秘密声明为变量以获得正确的哈希？

我是 SQL 中这个 Hashbytes 的新手。我在 SQL Server 2017 上使用它。

我正在使用 org.apache.commons.codec.digest.DigestUtils 库来计算 Java 中的 SHA1 哈希。 DigestUtils.sha1Hex("0x808204E039EFB76D96D3780BB507674").

不幸的是，这并没有给出与下面的 SQL 语句相同的结果？

varbinary 的等价物是 Java 中的 byte[]。所以，我试过DigestUtils.sha1Hex("0x808204E039EFB76D96D3780BB507674".getBytes())了，但这也没有帮助。请指导。

我知道存储HASHBYTES函数输出的最佳数据类型是BINARY/VARBINARY，但我们希望按照CHARDataVault 最佳实践的建议存储它，而且并非所有收费都支持BINARY类型的键，例如 PowerBI。

所以问题是，如何将其转换为CHAR? 当我做简单时，CAST/CONVERT我得到不同的输出而不是HASHBYTES函数的原始输出。

预期值为098F6BCD4621D373CADE4E832627B4F6（不带0x），实际值为 kÍF!ÓsÊÞNƒ&'´ö

我们一直PWDENCRYPT在我们的网站中使用散列密码 - 但想将其更改为使用HASHBYTES.

是否可以使这种转换自动进行？我知道不可能解密这些字符串 - 但是我要考虑什么来进行这种转换？

提前感谢您的回答。

我正在散列相同的值，但得到不同的结果。

这是一个简化的示例来解释我遇到的情况：

我有一个看起来像这样的维度表：

性别的数据类型是 NVARCHAR(6)，gender_id 是 INT

当我执行以下任何查询时，我得到相同的哈希：

输出：'0x6B216D8BB993AA263265CCF645C282B100000000'

输出：'0x6B216D8BB993AA263265CCF645C282B100000000'

在场景 1 中，我将 gender_id 转换为 INT，在场景 2 中，我将 gender_id 转换为 NVARCHAR。在这两种情况下，哈希都是相同的。

当我对维度中的特定值而不是列执行查询时，我的哈希值是不同的：

输出：'0x048A5F0EE2D2B4070CFF8A38CB6DAC7100000000'

输出：'0x6B216D8BB993AA263265CCF645C282B100000000'

在场景 3 中，我将 1 转换为 INT，就像我在场景 1 中所做的那样。在场景 4 中，我将 1 转换为 NVARCHAR，就像我在场景 2 中所做的那样。但是，场景 3 和 4 具有不同的哈希值。除此之外，场景 4 的哈希值与场景 1 和 2 中的哈希值一致。

我无法理解为什么场景 1、2 和 4 的哈希值相同，但场景 3 的哈希值不同。在我的维度中，gender_id 是一个 INT。当我查询我的维度时，无论我如何转换它，哈希总是相同的。在场景 3 和 4 中，当我用实际值替换列名时，结果会发生变化。除非我将其转换为 NVARCHAR，否则场景 3 中的哈希将不匹配场景 1 和 2。为什么会这样，因为gender_id 自然是一个INT？

将不胜感激您的任何见解，并很乐意在需要时提供更多说明。

谢谢！

为了获得较长文本的内容派生密钥，我计算了HASHBYTES('SHA1', text). 它返回 20 个字节长varbinary。由于我知道结果的长度，我将其存储为binary(20).

为了使其更短（用作键），我想遵循 Git 的短散列思想——就像十六进制表示的第一个（或最后一个）字符一样。而不是字符，我想binary(5)从binary(20).

尝试使用 SQL Server 2016 时，似乎采用以下简单方法：

返回前导字节（高位字节）：

但是，文档（https://docs.microsoft.com/en-us/sql/t-sql/data-types/binary-and-varbinary-transact-sql?view=sql-server-ver15）警告说：

不保证任何数据类型和二进制数据类型之间的转换在 SQL Server 版本之间是相同的。

好吧，这不完全是一种转换。尽管如此，这种不确定性是否也适用于binary从较长版本的binary? 对于 SQL Server 的未来版本，我应该期待什么？