为什么.NET的System.IO.Compression无法解压zlib流

最近在做一些算法深入测试的工作,碰到了一些小问题,写出来给一些后来的同学们参考吧。

比如,有一段Stream,我们明知道他是zlib compress的流,用Java的 java.util.zip.InflaterInputStream可以轻松解压。

但是,当我们用.NET的System.IO.Compression类的DeflateStream写相关代码的时候,发现无法解压,这是为什么呢?

其实问题在于System.IO.Compression的DeflateStream,DeflateStream压缩和解压都采用的是Raw Deflate Stream, 而并非标准的ZLib Stream。

那Raw Deflate Stream和标准的ZLib Stream区别又在哪呢?

首先说一下Zlib压缩数据的格式规范(RFC 1950):

https://www.rfc-editor.org/rfc/rfc1950

bash 复制代码
2.2. Data format

      A zlib stream has the following structure:

           0   1
         +---+---+
         |CMF|FLG|   (more-->)
         +---+---+

 (if FLG.FDICT set)

           0   1   2   3
         +---+---+---+---+
         |     DICTID    |   (more-->)
         +---+---+---+---+

         +=====================+---+---+---+---+
         |...compressed data...|    ADLER32    |
         +=====================+---+---+---+---+

      Any data which may appear after ADLER32 are not part of the zlib
      stream.


......

简而言之,ZLib压缩数据,需要标准的头和尾部数据。

其中头部2个字节,尾部4个字节。尤其是头数数据,表示压缩方法和模式:

先说头部2个字节:

bash 复制代码
0   1
+---+---+
|CMF|FLG|
+---+---+

1、第一个字节 CMF

其中前半个字节(高4位)表示 Compression method, 后半个字节(低4位)表示 Compression info。

2、第二个字节 FLG

第二个字节携带了3部分信息:

其实前5个字节(bits 0 ~ 4)表示 FCHECK------ check bits for CMF and FLG

第6个字节 ( bit 5) FDICK ------ preset dictionary

第7,8 个字节 FLEVEL ------ compression level

3、常见的几种头部信息:

bash 复制代码
78 01 - No Compression/low
78 9C - Default Compression
78 DA - Best Compression

而.NET的System.IO.Compression类的DeflateStream采集的Raw Deflate Stream并不包含这两部分信息,尤其是ZLib头部信息。

这时候再看我手上的代码,就几乎可以明白是什么原因无法解压了(以下信息为找印byte\[\]的hexdump信息):

bash 复制代码
compressed data hex: :
789c358e3d0b82501846fb0fcdfdb17e8df64aa91414514d41d11471c1ebc7626b9b4b7e5c1d52ca4baf0e0916a1ad5911677996f370005bdd0e601b455c87805f06b5528e3229c76a96811e11f93525fd62f174ae6ad12b8566cb30be0b0f04d74603a96b7b664013e34c5d23d67f1fbb6c59cf37c713a6e352b9095c84ed61058d49265c4da5c22987950021f12d474fc0272e09f6c9c7341997cc18194f7446633be49ec6a8a44594597e1e5ffe8df8064013858a

上面的数据前两个字节数据为0x78, 0x9c, 我们就可以看出他就是一串ZLib标准的压缩数据流,如果想用.NET的DeflateStream去解压这部分数据,也很简单------去掉ZLib的标准头部和尾部信息。

cs 复制代码
public static byte[] ZlibDecompress(byte[] data)
{
    using (MemoryStream decompressData = new MemoryStream())
    {
        data = data.Skip(2).ToArray();
        data = data.Take(data.Length - 4).ToArray();
        using (MemoryStream compressedStream = new MemoryStream(data))
        {
            using (DeflateStream deflateStream = new DeflateStream(compressedStream, CompressionMode.Decompress))
            {
                deflateStream.CopyTo(decompressData);
                utils.Bytes.PrintBytes("zlib decompress: ", decompressData.ToArray());
            }
        }
        return decompressData.ToArray();
    }
}

然后就解压成功了。

为什么没有讲尾部信息呢?因为尾部信息不重要,即使不去尾部信息,解压结果仍然一致:

至于压缩,因为DeflateStream的原因,压缩也是不会添加ZLib标准的头尾信息的,这点还是需要注意的。

下面是压缩代码:

cs 复制代码
public static void ZlibCompress(byte[] data)
{
    using (MemoryStream compressStream = new MemoryStream()) {
        using (MemoryStream memoryStream = new MemoryStream(data))
        {
            using (DeflateStream deflateStream = new DeflateStream(compressStream, CompressionMode.Compress))
            {
                memoryStream.CopyTo(deflateStream);
            }
            utils.Bytes.PrintBytes("deflateStream compress result: ", compressStream.ToArray());
        }
    }
    
}

压缩结果,可以看出缺少了原数据的头部2个字节和尾部4个字节的数据。

相关推荐
盒子69101 小时前
图生图大模型对于各种复杂的图片如何做负载均衡呢?
运维·负载均衡
2401_834636993 小时前
Linux 负载均衡全实战:Nginx+HAProxy+LVS 从原理到落地
linux·nginx·负载均衡
鹏大师运维8 小时前
为什么信创电脑装软件总提示“软件包架构不匹配”?
linux·运维·架构·国产化·麒麟·deb·统信uos
007张三丰9 小时前
软件测试专栏(11/20):测试框架开发:pytest深度解析与插件体系
运维·服务器·自动化测试·pytest·测试框架
weixin_6042366710 小时前
华三 路由器 极简核心配置
运维·服务器·网络·h3c·h3c路由器
鹤落晴春10 小时前
【Linux复习】管理SELinux安全性
linux·运维·服务器
yz_aiks10 小时前
Linux Jar包配置Systemd自启动实战:从排查到配置全流程
linux·python·jar·自启动·systemd
AI智图坊10 小时前
多件装组合SKU图的批量生产效率分析:从PS手工到AI自动化的工作流改造
大数据·运维·人工智能·gpt·ai作画·自动化·aigc
bjzhang7512 小时前
CentOS下安装MySQL详解
linux·mysql·centos
Jason_chen13 小时前
Linux 6.2 音频机制深度解析:AI驱动的低延迟音频与零信任音频安全架构
linux