7

我认为有办法做到这一点,但我不知道怎么做?基本上,我正在编写一个压缩程序,当我尝试解压缩压缩数据时导致出现 crc 错误。通常这意味着解压缩器实际上将我的数据识别为正确的格式并对其进行解压缩,但是当它将结果与 CRC 指示的预期长度进行比较时,它们并不相同。

但是,出于比较的原因,我实际上确实希望查看输出以查看它是否只是一个串联问题(如果解压缩的输出不是乱码而是顺序错误,这应该是相对明显的)。

4

2 回答 2

17

你说“解压缩”,但问题是“gzip”。它是哪一个?这是两个不同的程序,它们以两种不同的格式运行。我将假设gzip。此外,长度不是“由 CRC 指示的”。gzip 预告片包含一个 CRC 和一个未压缩的长度(模 2 32),这是两个不同的东西。

gzip命令将解压缩所有有效的 deflate 数据并在检查 crc 之前将其写出。因此,例如,如果我获取一个.gz文件并在最后损坏 crc(或长度),然后执行以下操作:

gzip -dc < corrupt.gz > result

那么结果将是整个正确的未压缩数据流。无需修改和重新编译gzip,也无需编写自己的 ungzipper。gzip 会抱怨 crc,但仍然会写入所有数据。

于 2012-10-31T05:13:33.780 回答
0

As far as I'm aware, the CRC check is part of the GZIP wrapper, not part of the actual compressed data in DEFLATE format.

So you should be able to take literally just the bytes that are the compressed data stream, ignoring the GZIP header and CRC at the end, and pass it through an Inflater.

In other words, you need to take just the bytes corresponding to those referred to as "compressed blocks" in the GZIP File format specification and try to decompress using a Java Inflater object. A little bit of work but possibly less than re-compiling the GZIP code as Greg suggests (though his option would also work in principle).

于 2012-10-31T01:18:51.383 回答