2

所以我对 PHP 中的散列函数有一个奇怪的小问题。它只在某些时候发生,这让我感到困惑。本质上,我有一个 Java 应用程序和一个 PHP 页面,它们都计算相同字符串的 SHA256。两者之间没有任何问题,因为它们(通常)计算相同的哈希值。一个例外是每隔一段时间,PHP 的输出就会比 Java 的输出长一个字符。

我在 PHP 中有这段代码:

$token = $_GET["token"];
$token = hash("sha256", $token."<salt>");
echo "Your token is " . $token;

99% 的时间,我得到了正确的哈希值。但每隔一段时间,我就会得到这样的东西(添加空间以显示差异):

26be60ec9a36f217df83834939cbefa33ac798776977c1970f6c38ba1cf92e92 # PHP
26be60ec9a36f217df83834939cbefa33ac798776977c197 f6c38ba1cf92e92 # Java

如您所见,它们几乎相同。但是出于某种原因,顶部的(由 PHP 计算)还有一个 0。我还没有真正注意到它的韵律或理由,但它确实难倒了我。我尝试过考虑诸如错误编码或错误返回值之类的事情,但没有一个能真正解释为什么除了那个字符之外它们几乎相同。

对此问题的任何帮助将不胜感激。

编辑:该空间仅位于底部以突出显示额外 0 的位置。实际的散列没有空格,并且确实是一个有效的散列,因为它与 Java 生成的散列相同。

EDIT2:对此感到抱歉。我用记事本++检查了长度,由于它与我的普通文本编辑器不同,我误读了1个长度。所以是的,上面的确实是正确的。这意味着这是我的 Java 代码中的一个错误。我将探索伊格纳西奥的答案并回复你。

4

2 回答 2

4

顶部哈希是正确的长度;输出底部哈希是因为十六进制值在输出时未填充零(请注意,它是一个字节的 MSn)。因此,Java 程序中存在与哈希算法无关的错误。

>>> '%04x %02x%02x %x%x' % (0x1201, 0x12, 0x01, 0x12, 0x01)
'1201 1201 121'
于 2012-08-20T16:57:33.067 回答
2

实际上,它是 SECOND 哈希,它的长度似乎不正确(63)。难道它是通过组装两个不同的令牌生成的,也许最后一个 - 应该是 16 个字符 - 删除了初始零?

于 2012-08-20T16:57:56.637 回答