MD5 哈希值不匹配

发布于 2024-11-14 20:13:09 字数 794 浏览 0 评论 0原文

我试图将 md5(通过 php 生成)与其在 SQLExpress 数据库中的原始值进行匹配。

我在 SQL 查询中使用以下函数,

master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', 'ID'), 1, 0)

其中“ID”是数据库中的字段。

然而,它们似乎都返回不同的 md5 哈希值。我一直使用“12290”作为静态值来测试这一点。

php md5() 返回: 0bd81786a8ec6ae9b22cbb3cb4d88179

以下 SQL 语句返回相同的输出:

DECLARE @password VARCHAR(255)
SET @password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', '12290'), 1, 0)
SELECT @password

然而,当我从表中运行以下语句时:

SELECT ID,  master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(255), ID)), 1, 0) AS temp
FROM Clients
ORDER BY ID ASC

与 12290 的 'ID' 值匹配的 'temp' 值返回: 1867dce5f1ee1ddb46ff0ccd1fc58e03

关于此事的任何帮助是非常感谢!

谢谢

I am trying to match a md5 has (generated through php) to its original value in a SQLExpress database.

I am using the following function in my SQL query

master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', 'ID'), 1, 0)

Where 'ID' is the field in the database.

However they both seem to return different values for the md5 hash. I have been using '12290' as a static value to test this.

php md5() returns: 0bd81786a8ec6ae9b22cbb3cb4d88179

The following SQL Statement returns the same output:

DECLARE @password VARCHAR(255)
SET @password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', '12290'), 1, 0)
SELECT @password

Yet when I run the following statement from the table:

SELECT ID,  master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(255), ID)), 1, 0) AS temp
FROM Clients
ORDER BY ID ASC

The 'temp' value matching to the 'ID' value of 12290 returns: 1867dce5f1ee1ddb46ff0ccd1fc58e03

Any help on the matter would be much appreciated!

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

醉梦枕江山 2024-11-21 20:13:09

Python 帮助我帮助你。

>>> from hashlib import md5
>>> md5('1\x002\x002\x009\x000\x00').digest().encode('hex')
'1867dce5f1ee1ddb46ff0ccd1fc58e03'

NVARCHAR 是 Unicode 类型,从上面的实验来看,'12990' 在数据库中存储为 UTF-16LE:'1\02\09\09\00\0'.

假设 PHP 中的数据编码是 UTF-8 数据,并且您不想更改数据库中的现有数据,则可以通过以下方式修复 PHP 脚本:

<?php
    $password = '12290';
    $hash = md5(mb_convert_encoding($password, 'UTF-16LE', 'UTF-8')) . "\n";
    echo $hash;
?>

输出:

susam@swift:~$ php utf16le-hash.php
1867dce5f1ee1ddb46ff0ccd1fc58e03

如果 PHP 中的数据采用其他格式编码,例如 ASCII、ISO-8859-1 等。您可以相应地将第三个参数更改为 mb_convert_encoding 。所有支持的编码的列表可在以下位置找到: http://www.php .net/manual/en/mbstring.supported-encodings.php

另请参阅 http://www.php.net/manual/en/function.mb-convert-encoding.php

Python helped me to help you.

>>> from hashlib import md5
>>> md5('1\x002\x002\x009\x000\x00').digest().encode('hex')
'1867dce5f1ee1ddb46ff0ccd1fc58e03'

NVARCHAR is Unicode type and it seems from the above experiment that '12990' is stored as UTF-16LE in your database: '1\02\09\09\00\0'.

Assuming that the data encoding in the PHP is UTF-8 data and you don't want to change the existing data in the database, this is how you can fix your PHP script:

<?php
    $password = '12290';
    $hash = md5(mb_convert_encoding($password, 'UTF-16LE', 'UTF-8')) . "\n";
    echo $hash;
?>

Output:

susam@swift:~$ php utf16le-hash.php
1867dce5f1ee1ddb46ff0ccd1fc58e03

In case the data in PHP is in some other encoding such as ASCII, ISO-8859-1, etc. you can change the third argument to mb_convert_encoding accordingly. The list of all supported encodings is available at: http://www.php.net/manual/en/mbstring.supported-encodings.php

Also, see http://www.php.net/manual/en/function.mb-convert-encoding.php

东京女 2024-11-21 20:13:09

我没有 SQL Server 来测试这一点,但 CONVERT 命令可能会创建带有 240 多个尾随空白的 NVARCHAR(如您指定的 NVARCHAR(255))

尝试将 NVARCHAR 设置为要测试的 ID 的长度:

ARE @password VARCHAR(255)
SET @password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(5), '12290')), 1, 0)
SELECT @password

尝试在 CONVERT 中使用不同的长度 - 有什么区别吗?

I don't have SQL server to test this on, but the CONVERT command might be creating the NVARCHAR with 240-odd trailing blanks (as you have specified NVARCHAR(255))

Try setting the NVARCHAR to the length of the ID to test:

ARE @password VARCHAR(255)
SET @password = master.sys.fn_varbintohexsubstring(0, HASHBYTES('MD5', CONVERT(NVARCHAR(5), '12290')), 1, 0)
SELECT @password

Try with different lengths in the CONVERT - is there any difference?

冷了相思 2024-11-21 20:13:09

两件事之一很可能是问题所在:

  1. 该行中的 ID 列的值不完全等于 '12290'(例如额外的空格)
  2. CONVERT 函数 ;

在任何情况下,标准的调试方法都是使用 SQL 查询来 SELECT 该 ID 字段的字符串长度以及 CONVERT 的返回值 如果其中一个不等于5,则您发现了错误。

或者,您可以对相关表(包括数据)执行转储,然后查看生成的 INSERT 语句以查看数据库显示该列中的值是什么。

One of two things is most likely the problem:

  1. Either the ID column in that row has a value not exactly equal to '12290' (e.g. extra whitespace)
  2. Or the CONVERT function produces such a value

In any case, a standard debugging approach would be to use an SQL query to SELECT the string lengths of that ID field and the return value of CONVERT; if either is not equal to 5, you found the error.

Alternatively you can perform a dump of the table in question including data, and look at the generated INSERT statement to see what the database says the value in that column is.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文