Android InflaterInputStream 与流行的 ZLIB Windows 库相同吗？

Question

我正在尝试解压缩使用 Jean-loup Gailly 在 20 世纪 90 年代编写的 ZLIB 库压缩的数据。我认为它是一个流行的库（我看到很多程序都提供它使用的 zlib32.dll 文件），所以我希望有人对它足够熟悉来帮助我。我直接使用 compress() 函数，从我读到的内容来看，它使用 rfc-1951 DEFLATE 格式。

下面是我用来从流中读取一些压缩数据并将其解压缩的代码片段：

InputStream is = new ByteArrayInputStream(buf);

//GZIPInputStream gzis = new GZIPInputStream(is);

InflaterInputStream iis = new InflaterInputStream(is);

byte[] buf2 = new byte[uncompressedDataLength];

iis.read(buf2);

iis.read(buf2) 函数抛出“数据格式错误”的内部异常。我也尝试使用 GZIPInputStream，但这也会引发相同的异常。

“buf”变量的类型为 byte[]，我通过调试确认它与我的 C 程序从 ZLIB compress() 函数返回的内容相同（实际数据来自 TCP 上的服务器）。 “uncompressedDataLength”是 C 程序（服务器）提供的未压缩数据的已知大小。

有没有人尝试过使用这个库读取/写入数据，然后使用Java在Android上读取/写入相同的数据？

我确实在一些地方找到了引用的“ZLIB 的纯 Java 端口”，如果需要，我可以尝试一下，但如果可能的话，我宁愿使用内置/操作系统功能。

Answer 1

这里使用的数据格式 deflate、zlib 和 gzip 都是相关的。

• 基础是 deflate 压缩数据格式，在 RFC 中定义1951 年。
  由于它的纯粹形式通常毫无用处，因此我们通常使用包装格式。

  
  

• gzip 压缩数据格式 (RFC 1952 ）用于文件压缩。它由一个包含文件名和一些属性空间的标头、一个 deflate 数据流以及末尾的 CRC-32 校验和（4 个字节）组成。 （规范中还支持一个流中的多个此类文件，但我认为这并不经常使用。）

• zlib 压缩数据格式，在 RFC 1950：它由一个较小的标头（2或6个字节）、一个deflate数据组成流，末尾有一个 Adler-32 校验和（4 个字节）。 （Adler-32 校验和的计算速度比 gzip 中使用的 CRC-32 校验和更快。）它旨在用于某些其他协议内的数据压缩传输，或其他文件格式内的压缩存储。例如，它用于 PNG 文件格式内部。

zlib 库支持所有这些格式。 Java 的 java.util.zip 构建于 zlib 之上（作为 VM 实现/本机调用的一部分），并通过多个类公开对这些类的访问：

• Deflater 和 Inflater 类实现 - 取决于 nowrap 构造函数的参数 - zlib 或 deflate 数据格式。

  


• DeflaterOutputStream/DeflaterInputStream/InflaterInputStream/InflaterOutputStream 构建在 Deflater/Inflater 上。文档没有明确说明默认的 Inflater/Deflater 是否实现 zlib 或 deflate，但源代码显示它使用默认的 Deflater 或Inflater 构造函数，实现 zlib。

• GZipOutputStream/GZipInputStream 实现，顾名思义，gzip 格式。

我查看了zlib的 compress 函数的源代码，它似乎使用 zlib 格式。所以你的代码应该做正确的事情。确保前后没有丢失数据或不属于压缩数据块的附加数据。

免责声明：这是Java SE的状态，我想Android也类似，但我不能保证这一点。

您找到的 jzlib 库（我想）是 zlib 的 Java 重新实现，也实现了所有这些数据格式（最新更新中添加了 gzip）。对于交互式使用（在压缩方面），它是更可取的，因为它允许一些 java.util 的类不可能进行的刷新操作（除了使用一些解决方法，如更改压缩级别），并且它也可能更快，因为它避免了本机调用（总是有一些开销）。

PS：zip（或 pkzip）文件格式也相关：它在存档内的每个文件内部使用 deflate。