有哪些不同的 zlib 压缩方法以及如何在 Java 的 Deflater 中强制使用默认值？
我正在使用 DeflaterOutputStream 将数据压缩为专有存档文件格式的一部分。 然后我使用 jcraft zlib 代码在另一端解压缩该数据。 另一端是 J2ME 应用程序，因此我依赖第三方 zip 解压缩代码而不是标准 Java 库。
我的问题是有些文件可以正常压缩和解压缩，而其他文件则不能。
对于没有的，数据第一个字节的压缩方法似乎是“5”。
从我对 zlib 的阅读中，我了解到默认值“8”表示默认的 deflate 压缩方法。 任何其他值对于解压缩器来说似乎都是不可接受的。
我想知道的是：
- “5”代表什么？
- 为什么 DeflaterOutputStream 有时会使用不同的压缩方法？
- 我可以以某种方式阻止它这样做吗？
- 是否有另一种方法来生成仅使用默认压缩方法的紧缩数据？
I am using DeflaterOutputStream to compress data as a part of a proprietary archive file format. I'm then using jcraft zlib code to decompress that data on the other end. The other end is a J2ME application, hence my reliance on third party zip decompression code and not the standard Java libraries.
My problem is that some files zip and unzip just fine, and others do not.
For the ones that do not, the compression method in the first byte of the data seems to be '5'.
From my reading up on zlib, I understand that a default value of '8' indicates the default deflate compression method. Any other value appears to be unacceptable to the decompressor.
What I'd like to know is:
- What does '5' indicate?
- Why does DeflaterOutputStream use different compression methods some of the time?
- Can I stop it from doing that somehow?
- Is there another way to generate deflated data that uses only the default compression method?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它可能有助于准确地确定您正在查看的内容。
在整个数据之前，通常有一个两字节的 ZLIB 标头。 据我所知，第一个字节的低 4 位应始终为 8。 如果你在 nowrap 模式下初始化你的 Deflater，那么你根本不会得到这两个字节（尽管你的其他库肯定不会得到它们）。
然后，在每个单独的数据块之前，有一个 3 位块头（注意，定义为位数，而不是整数字节）。 可以想象，您可以有一个以字节 5 开头的块，这表示压缩块是最终块，或者以字节 8 开头，这将是非压缩的非最终块。
当您创建 DefalterOutputStream 时，您可以将 Deflater 或您的选择传递给构造函数，并且在该 Defalter 上，您可以设置一些选项。 级别本质上是压缩在查找数据中的重复模式时使用的前瞻量； 有时，您可以尝试将其设置为非默认值，看看它是否对您的解压缩器是否可以应对有任何影响。
在某些特殊情况下可以使用策略设置（请参阅 setStrategy() 方法）来告诉 deflater 仅应用霍夫曼压缩。 当您已经转换数据以使值的频率接近 2 的负幂（即霍夫曼编码最适合的分布）时，这有时会很有用。 我不希望此设置影响库是否可以读取您的数据，但偶尔您可能会尝试更改此设置。
如果它有帮助，我写了一些关于 配置 Deflater 的内容，包括对转换后的数据使用仅霍夫曼压缩。 我必须承认，无论您选择什么选项，我真的希望您的图书馆能够读取数据。 如果您确实确定压缩数据是正确的（即 ZLIB/Inflater 可以重新读取您的文件），那么您可能会考虑使用另一个库......！
哦，并说明出血很明显，但无论如何我都会提到这一点，如果您的数据已修复，您当然可以将其放入罐子中，并且它会有效地“免费”放气/充气。 讽刺的是，您的 J2ME 设备必须能够解码 zlib 压缩数据，因为这本质上就是 jar 的格式...
It might help to hone down exactly what you're looking at.
Before the whole of your data, there's usually a two-byte ZLIB header. As far as I'm aware, the lower 4 bits of the first byte of these should ALWAYS be 8. If you initialise your Deflater in nowrap mode, then you won't get these two bytes at all (though your other library must then be expecting not to get them).
Then, before each individual block of data, there's a 3-bit block header (notice, defined as a number of bits, not a whole number of bytes). Conceivably, you could have a block starting with byte 5, which would indicate a compressed block that is the final block, or with byte 8, which would be a non-compressed, non-final block.
When you create your DeflaterOutputStream, you can pass in a Deflater or your choosing to the constructor, and on that Defalter, there are some options you can set. The level is essentially the amount of look-ahead that the compression uses when looking for repeated patterns in the data; on the offchance, you might try setting this to a non-default value and see if it makes any difference to whether your decompresser can cope.
The strategy setting (see the setStrategy() method) can be used in some special circumstances to tell the deflater to only apply huffman compression. This can occasionally be useful in cases where you have already transformed your data so that frequencies of values are near negative powers of 2 (i.e. the distribution that Huffman coding works best on). I wouldn't expect this setting to affect whether a library can read your data, but juuust on the offchance, you might just try changing this setting.
In case its helpful, I've written a little bit about configuring Deflater, including the use of huffman-only compression on transformed data. I must admit, whatever options you choose, I'd really expect your library to be able to read the data. If you're really sure your compressed data is correct (i.e. ZLIB/Inflater can re-read your file), then you might consider just using another library...!
Oh, and stating the bleeding obvious but I'll mention it anyway, if your data is fixed you can of course just stick it in the jar and it'll effectively be deflated/inflater "for free". Ironically, your J2ME device MUST be able to decode zlib-compressed data, because that's essentially the format the jar is in...