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端口",如果我需要,我可以试试,但我宁愿使用内置/ OS功能,如果可能的话.

Answer 1

这里的数据格式是deflate,zlib和gzip都是相关的.

• 基数是deflate压缩数据格式,在RFC 1951中定义.因为它纯粹的形式通常是无用的,我们通常使用它周围的包装格式.

• 所述的gzip压缩数据格式(RFC 1952)是用于文件的压缩.它由一个头部组成,该头部具有文件名和一些属性的空间,一个deflate数据流,以及最后的CRC-32校验和(4个字节).(规范中的一个流中也支持多个这样的文件,但我认为这种情况并不经常使用.)

• 所述ZLIB压缩数据格式,定义在RFC 1950:它由更小的头部(2个或6字节),一个放气的数据流,并在最后一个阿德勒-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.