我正在尝试在SQLExpress数据库中将md5 has (通过php生成)与其原始值进行匹配。
我在我的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与'ID‘值12290匹配的'temp’值返回: 1867dce5f1ee1ddb46ff0ccd1fc58e03
在这个问题上的任何帮助都将不胜感激!
谢谢
发布于 2011-06-10 16:20:03
我没有SQL服务器来测试这一点,但是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尝试在转换中使用不同的长度-有什么不同吗?
发布于 2011-06-10 16:22:43
Python帮了我的忙。
>>> from hashlib import md5
>>> md5('1\x002\x002\x009\x000\x00').digest().encode('hex')
'1867dce5f1ee1ddb46ff0ccd1fc58e03'NVARCHAR是Unicode类型,从上面的实验可以看出,在您的数据库:'1\02\09\09\00\0'中,'12990'被存储为UTF-16LE。
假设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
发布于 2011-06-10 16:14:29
以下两种情况中的一种最有可能是问题:
'12290' (例如,额外的空格)CONVERT函数生成这样的值在任何情况下,标准的调试方法都是使用SQL查询来选择ID字段的字符串长度和CONVERT的返回值;如果两者都不等于5,则会发现错误。
或者,您可以对包含数据的表执行转储,并查看生成的INSERT语句,以查看数据库表示该列中的值是什么。
https://stackoverflow.com/questions/6303624
复制相似问题