问题标签 [adler32]

关于 zlib 中使用的校验和 adler32。

从 RFC 1950 开始：

ADLER32：这包含根据 Adler-32 算法计算的未压缩数据（不包括任何字典数据）的校验和值。

这是一个 png（IDAT 中的 zlib）。

• 蓝色 = 长度，4 个字节
• 红色 = 类型，4 个字节
• 黄色 = crc，4 个字节
• 绿色 = zlib 标头，2 个字节
• gray = zlib 数据，不同的字节
• 粉红色 = adler32，4 个字节

现在解析灰色数据并将 zlib 数据传递给计算 adler32 的外部程序。

结果是 64c60bbd，而不是 b0337596。

...或从图像映射传递数据时。

结果是 1a49bac4，而不是 b0337596

checksum.exe的代码：

问题，什么可能导致计算中的差异？即zlib 的adler32 的输入数据到底是什么？

解决方案：

如前所述，zlib adler32 是通过未压缩的数据流计算的，在 png 中是过滤后的数据流。在这种情况下，那将是...

注意，这里的未压缩数据流是一个红色 50x50 的 rgba 图像，过滤器每行增加一个字节，结果为 10,050 个字节。即 50*50*40 + 50。

我已成功重定向到 ccavenue 支付网关，但在单击取消按钮时，它在重定向 url 页面中显示错误“安全错误。检测到非法访问” 。

这是我的重定向网址页面：

我用谷歌搜索了这个问题，但没有得到任何解决方案。如何解决此错误..请对此提出一些建议？

我在一些单元测试中被这个咬了。

我想使用Inflater解压缩一些 ZLIB 压缩的数据，其中原始数据长度是预先知道的。

这（直截了当）按预期工作

现在，压缩输入可以以任意大小的块出现。以下代码模拟了压缩输入除了最后 4 个字节外全部输入的情况，然后一次输入一个剩余字节。（据我了解，zlib 流的最后 4 个或 5 个字节不需要解压缩完整数据，但需要它们来检查完整性 - Adler-32 CRC）。

好吧，这对我不起作用（Java 1.8.0_181）。充气机没有完成，Adler CRC 校验没有完成，看起来；更多：似乎字节没有被送入充气机。

更奇怪的是：如果在一次调用中输入尾随的 4 个字节，它就可以工作。

你可以在这里试试：https ://repl.it/@HernanJJ/Inflater-Test

当我一次输入整个输入一个字节时，甚至会发生更奇怪的事情：有时该行 int nx= inf.inflate(buf2);//should give 0返回非零（当所有数据都已经膨胀时）。

这是预期的行为吗？我错过了什么吗？

我的任务是编写两个 java 程序。一个程序创建一个名为“userinput.txt”的文件，然后将用户输入的所有内容写入该文件。完成后，将创建一个名为“Checksum.txt”的新文件，该文件将在读取其中的内容后记下“userinput.txt”文件的校验和。

第二个程序只是读取相同的“userinput.txt”文件，然后生成一个校验和并将其打印到控制台上（我还必须让程序读取另一个 checksum.txt 文件并将其显示在控制台中以比较两者但我还没有解决这个问题）。

我为这两个编写了程序，但我的问题是它们都是不同的校验和，即使它们正在读取同一个文件。我使用 Adler32，但 CRC32 也给了我两个不同的校验和（控制台上的校验和总是与 checksum.txt 中存储的校验和不同），坦率地说，我不确定是什么原因造成的：/

这是接受用户输入并生成校验和文件的代码：

读取文件并在控制台中生成校验和的代码：

我试图从头开始编写Adler-32 哈希函数只是为了找点乐子，我已经完成了它，除了每次我散列一个字符串时，它总是缺少前面的零。我已经阅读了数十次公式和 Adler-32 描述，但我无法弄清楚为什么我的代码会产生它。代码如下。

我正在努力解压来自 BizTalk Server 的 AS2 请求的 Zlib 压缩 Mime 主体。

事情是：

我收到的 HTTP 正文与预期的一样。我可以阅读 ASCII 编码的 Mime 标头：

"内容类型：application/pkcs7-mime；smime-type=compressed-data；name=smime.p7m\r\n内容-传输-编码：二进制\r\n\r\n"

以两个换行符结束，我期待之后的压缩体。但是当我使用 Ionic.Zlib ZlibStream.UncompressBuffer() 解压缩以下字节时，它会引发错误。

Zlib Header 可以通过例如十六进制编码字节“78da”来识别。当我从那里开始解压缩它时，它工作正常。

两个换行符结束 mime 标头和“78da”开始 zlib 压缩数据之间的字节是多少？

“3080060b2a864886f70d0109100109a0803080020100300f060b2a864886f70d01091003080500308006092a864886f70d010701a080248004820769”

下一个问题，如果我把所有字节都读到最后，最后一个字节是无法解压的。据我了解，zLib 数据应该以 adler32 校验和结尾，但是如何在不尝试解压缩的情况下识别压缩数据的结尾或长度。我在成功解压缩数据后看到一些尾随字节：“1f9b1f1fcbc51f0482000445a59371”那是什么？

谢谢你的想法！

Adler32 和 CRC 具有f(a || b)可以从、和廉价计算的属性。是否有任何其他具有此属性的常见非加密哈希函数？f(a)f(b)len(b)

上下文（为了避免 XY 问题）是我通过将字符串拆分成块来删除重复数据，这些块由它们的哈希索引。然后可以将输入字符串表示为串联的块序列。我想使用一个散列函数，使字符串的所有表示具有相同的散列，可以直接从块散列计算而不需要底层数据，因为它以未指定的顺序流式传输，因此可能不可用任何时候都在同一个地方。

我的设计需要大约 2^32 个块。碰撞是非常昂贵的，但不会损害正确性。基于此，我认为CRC64 会起作用，但我很好奇我的替代方案是什么。我不介意 128 位哈希用于未来的校对（如：数据集大小可能会增长）。