【问题标题】:Different same but same result with zlib与 zlib 不同但相同的结果
【发布时间】:2023-03-15 16:10:01
【问题描述】:

我有重复的检查谁没有工作,因为我的 zlib 哈希对于同一个文件是不同的。

我从我的客户端获得了一个使用 AES 加密的数据(XML 文件)。 我解密了数据(使用 Cipher),得到了一个压缩数据和 base64 编码的字节数组。

我解码 base64、unzlib 并得到我的 XML 文件。

如果我再做一次,我会从 Cipher 中得到不同的 base64。我解码它,unzlib 并得到与下面完全相同的 XML。

由于这个问题,我的重复检查不起作用,因为 base64 值不同,我不明白为什么。

我的 base64 值大约是 3000 个字符,只有最后 10-15 个字符不同。

实际上这个软件是用 PHP 编写的,而且一切都很好。在 JAVA 中的新服务器上,我们收到此错误。

所以客户端数据是正确的,JAVA做了一些我无法解释的事情。

有什么想法吗?

谢谢

【问题讨论】:

  • 可能是 zip 文件中的日期/时间戳。您正在更新它们,而旧代码不是。检查所涉及文件的日期/时间,并确保它们没有更改。
  • 但它不是一个zip文件它是一个xml压缩的字节数组,最后我没有看到任何时间戳,我可以删除这些信息并只获取数据?

标签: java base64 zip zlib


【解决方案1】:

您的问题很难解析,但我认为您的意思是,如果您将 PHP 压缩的内容解压缩,然后用 Java 重新压缩,您会得到不同的压缩数据。当您解压缩该数据时,您会得到完全原始的未压缩数据。

如果正确,就没有问题。无法保证不同的压缩器会产生相同的结果,甚至是相同的压缩器,因为您可以有不同的设置,甚至是相同的压缩器具有相同的设置,因为您可能使用不同的版本。 “我解码它,unzlib 并得到与下面完全相同的 XML。”,意味着所有的压缩器和解压缩器都在做他们应该做的事情。无法保证解压缩后压缩会产生完全相同的结果。无损压缩器的唯一保证是压缩后解压缩将产生完全相同的结果。

您正在使用“我有重复检查”为自己制造问题。检查压缩数据不会检查重复的未压缩数据。如果要查找重复项,或者要检查压缩、传输和解压缩过程的完整性,则需要同时使用未压缩数据,而不是压缩数据。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-02-14
    • 2019-08-28
    • 1970-01-01
    • 2016-05-05
    • 2022-08-05
    • 1970-01-01
    相关资源
    最近更新 更多