问题描述
函数cSHA1(m)在客户端我使用的是Rusha, {
return(new Rusha).digest(m);
$ / code>
在服务器上,我使用Node的本地加密
模块,
函数sSHA1(m){
var h = crypto.createHash( 'SHA1');
h.update(m);
return h.digest('hex');
}
让我们试试看:
cSHA1('foo')
0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
sSHA1('foo')
'0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
cSHA1('bar')
62cdb7020ff920e5aa642c3d4066950dd1f01f4d
sSHA1('bar')
'62cdb7020ff920e5aa642c3d4066950dd1f01f4d'
到目前为止,这么好。
现在让我们将它们引入曲线球...
cSHA1(String.fromCharCode(10047))
5bab61eb53176449e25c2c82f172b82cb13ffb9d
sSHA1(String.fromCharCode (10047))
'5bab61eb53176449e25c2c82f172b82cb13ffb9d'
好的,
我有一个字符串,它的重要性应该不是很重要,无论如何,这是一个很长的故事,但是:
<$ (c){
return c.charCodeAt();
})
收益率这两个地方的结果完全相同:
[58,34,10047,32,79]
code>
现在,让我们对它进行哈希:
:✿O
cSHA1(s)
a199372c8471f35d14955d6abfae4ab12cacf4fb
s
':? O'
sSHA1(s)
'fc67b1e4ceb3e57e5d9f601ef4ef10c347eb62e6'
这使我一点点悲伤;到底是什么东西?
当比较shas1和shashha的SHA1哈希值时,我遇到了与德语变音符相同的问题。
$ b
原因很简单:一些扔石头的傻瓜决定Javascript字符串是UTF16 - 而PHP没有提供关于编码的sh * t,它只是需要什么。因此,如果您向PHP提供了一个json_decode(\\\ä),它会将它变成一个2字节的字符串0xc3 0xa4(UTF8)。
从这个(0xE4)中创建一个UTF16字节 - 并且Rusha的手册明确地说所有codepoints必须低于256 。
为了帮助你自己,请使用,例如 sha.digest(utf16to8(\\\ä))
。这将提供rusha正确的代码点。
On the client I'm using Rusha, which I've put into a wrapper:
function cSHA1(m){
return (new Rusha).digest(m);
}
On the server I'm using Node's native crypto
module,
function sSHA1(m){
var h = crypto.createHash('sha1');
h.update(m);
return h.digest('hex');
}
Let's try it:
cSHA1('foo')
"0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33"
sSHA1('foo')
'0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33'
cSHA1('bar')
"62cdb7020ff920e5aa642c3d4066950dd1f01f4d"
sSHA1('bar')
'62cdb7020ff920e5aa642c3d4066950dd1f01f4d'
So far, so good.
Now let's throw them a curveball...
cSHA1(String.fromCharCode(10047))
"5bab61eb53176449e25c2c82f172b82cb13ffb9d"
sSHA1(String.fromCharCode(10047))
'5bab61eb53176449e25c2c82f172b82cb13ffb9d'
Ok, fine.
I have a string, and it shouldn't be important how I got it, and it's a long story, anyway, but:
s.split('').map(function(c){
return c.charCodeAt();
})
yields the exact same result in both places:
[58, 34, 10047, 32, 79]
Now, let's hash it:
s
":"✿ O"
cSHA1(s)
"a199372c8471f35d14955d6abfae4ab12cacf4fb"
s
':"? O'
sSHA1(s)
'fc67b1e4ceb3e57e5d9f601ef4ef10c347eb62e6'
This has caused me a fair bit of grief; what the hell?
I have run into the same problem with the German Umlaut character when comparing SHA1 hashes of PHPs sha1 and Rusha.
The reason is simple: some stoned fool decided Javascript strings are UTF16 - and PHP doesn't give a sh*t about encoding, it just takes what is there. So, if you supply PHP a json_decode("\u00e4"), it will turn this into a 2-byte string 0xc3 0xa4 (UTF8).
JS instead will make a single UTF16 byte out of this (0xE4) - and Rusha's manual explicitly says all codepoints must be below 256.
To help yourself, use the UTF18-to-8 library at http://www.onicos.com/staff/iz/amuse/javascript/expert/utf.txt like sha.digest(utf16to8("\u00e4"))
. This will feed rusha correct codepoints.
这篇关于在服务器和客户端上使用相同的SHA1哈希值的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!