MD5 哈希值不匹配
我试图将 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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
Python 帮助我帮助你。
NVARCHAR 是 Unicode 类型,从上面的实验来看,
'12990'
在数据库中存储为 UTF-16LE:'1\02\09\09\00\0'.
假设 PHP 中的数据编码是 UTF-8 数据,并且您不想更改数据库中的现有数据,则可以通过以下方式修复 PHP 脚本:
输出:
如果 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.
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:
Output:
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.phpAlso, see http://www.php.net/manual/en/function.mb-convert-encoding.php
我没有 SQL Server 来测试这一点,但 CONVERT 命令可能会创建带有 240 多个尾随空白的 NVARCHAR(如您指定的 NVARCHAR(255))
尝试将 NVARCHAR 设置为要测试的 ID 的长度:
尝试在 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:
Try with different lengths in the CONVERT - is there any difference?
两件事之一很可能是问题所在:
'12290'
(例如额外的空格)CONVERT
函数 ;在任何情况下,标准的调试方法都是使用 SQL 查询来 SELECT 该 ID 字段的字符串长度以及 CONVERT 的返回值 如果其中一个不等于
5
,则您发现了错误。或者,您可以对相关表(包括数据)执行转储,然后查看生成的 INSERT 语句以查看数据库显示该列中的值是什么。
One of two things is most likely the problem:
'12290'
(e.g. extra whitespace)CONVERT
function produces such a valueIn 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 to5
, 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.