我有一个C应用程序,需要使用标准压缩格式的目录.
我想过使用zip格式.
因此,zlib显而易见.

我的问题是构建字典,即将包含一些zlib文件的目录压缩到标准zip文件.

我已经读过zlib做了但我不明白怎么做.我检查了minzip代码.它似乎使用gzip.我可以构建自己的格式,但我希望能够使用7z打开这些文件进行调试(以防万一).

我应该在zlib中使用什么来压缩目录？

[编辑]
在minzip中
我使用minzip压缩1个文件到它的gz版本 – >不拉链但对我很好. (我将在世界各种编译器上使用它 – 如果客户端平台出现问题,则标准格式更容易)

此外,主要有这个代码.它在文件列表上循环并将其写入输出.
但是档案中文件位置的信息在哪里？

do {        if (uncompr) {            if (copyout) {                file = gzopen(*argv,"rb");                if (file == NULL)                    fprintf(stderr,"%s: can't gzopen %s\n",prog,*argv);                else                    gz_uncompress(file,stdout);            } else {                file_uncompress(*argv);            }        } else {            if (copyout) {                FILE * in = fopen(*argv,"rb");                if (in == NULL) {                    perror(*argv);                } else {                    file = gzdopen(fileno(stdout),outmode);                    if (file == NULL) error("can't gzdopen stdout");                    gz_compress(in,file);                }            } else {                file_compress(*argv,outmode);            }        }    } while (argv++,--argc);

对不起,如果这很明显.

查看 minizip.c以获取如何使用minizip创建zip文件的示例. minizip位于zlib发行版的contrib目录中,这意味着它是第三方贡献的代码.它不是zlib库的一部分.

请注意,gzip不是zip. zlib格式不是zip.原始deflate数据不是zip.这些都是不同的格式.原始deflate数据是zip格式允许的压缩格式之一,实际上是最常见的. zlib对于处理zip文件非常有用,但它本身并不能这样做. zlib本身仅提供压缩和解压缩引擎以及CRC计算.

我有这个未压缩字节数组：

0E 7C BD 03 6E 65 67 6C 65 63 74 00 00 00 00 00 00 00 00 00 42 52 00 00 01 02 01
00 BB 14 8D 37 0A 00 00 01 00 00 00 00 05 E9 05 E9 00 00 00 00 00 00 00 00 00 00
00 00 00 00 01 00 00 00 00 00 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 05 00 00 01 00 00 00

我需要使用deflate算法(在zlib中实现)来压缩它,从C#中搜索到的等效项将使用GZipStream,但是我根本无法匹配压缩的结果.

这是压缩代码：

public byte[] compress(byte[] input)
{
    using (MemoryStream ms = new MemoryStream())
    {
        using (GZipStream deflateStream = new GZipStream(ms,CompressionMode.Compress))
        {
            deflateStream.Write(input,input.Length);
        }
        return ms.ToArray();
    }
}

以下是上述压缩码的结果：

1F 8B 08 00 00 00 00 00 04 00 ED BD 07 60 1C 49 96 25 26 2F 6D CA 7B 7F 4A F5 4A
D7 E0 74 A1 08 80 60 13 24 D8 90 40 10 EC C1 88 CD E6 92 EC 1D 69 47 23 29 AB 2A
81 CA 65 56 65 5D 66 16 40 CC ED 9D BC F7 DE 7B EF BD F7 DE 7B EF BD F7 BA 3B 9D
4E 27 F7 DF FF 3F 5C 66 64 01 6C F6 CE 4A DA C9 9E 21 80 AA C8 1F 3F 7E 7C 1F 3F
22 7E 93 9F F9 FB 7F ED 65 7E 51 E6 D3 F6 D7 30 CF 93 57 BF C6 AF F1 6B FE 5A BF
E6 AF F1 F7 FE 56 7F FC 03 F3 D9 AF FB 5F DB AF 83 E7 0F FE 35 23 1F FE BA F4 FE
AF F1 6B FC 1A FF 0F 26 EC 38 82 5C 00 00 00

这是我期待的结果：

78 9C E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03 4E 41 0C 0C 8C 4C 8C 0C BB 45 7A
CD B9 80 4C 90 18 EB 4B D6 97 0C 28 00 2C CC D0 C8 C8 80 09 58 21 B2 00 65 6B 08
C8

我做错了什么,有人可以帮助我吗？

首先,一些信息：DEFLATE是压缩算法,它在 RFC 1951中定义.DEFLATE分别在 RFC 1950和 1952中定义的ZLIB和GZIP格式中使用,它们本质上是DEFLATE字节流周围的薄包装.包装器提供元数据,例如文件的名称,时间戳,CRC或Adlers等等.

.NET的基类库实现了一个DeflateStream,它用于生成一个原始的DEFLATE bytestream,用于压缩.当用于解压缩时,会消耗原始DEFLATE bytestream. .NET还提供了一个GZipStream,它只是围绕该基础的GZIP包装器. .NET基类库中没有ZlibStream,没有任何产生或消耗ZLIB.有一些技巧要做,你可以搜索.

.NET中的放气逻辑表现出一种行为异常,其中先前压缩的数据实际上可以在“压缩”时显着增加.这是a Connect bug raised with Microsoft和has been discussed here on SO的来源.这可能是你看到的,就是无效的压缩. Microsoft已经拒绝了这个错误,因为当它节省空间是无效的时候,压缩流不是无效的,换句话说,它可以被任何兼容的DEFLATE引擎“解压缩”.

无论如何,像其他人一样,不同压缩机产生的压缩字节流可能不一定相同.这取决于它们的默认设置和压缩器的应用程序指定的设置.即使压缩字节流不同,它们仍然可以解压缩到相同的原始字节流.另一方面,你用来压缩的东西是GZIP,而你想要的就是ZLIB.当他们相关时,他们是不一样的;您不能使用GZipStream生成ZLIB bytestream.这是您看到的差异的主要来源.

我想你想要一个ZLIB流.

DotNetZip project中免费管理的Zlib实现了所有三种格式(DEFLATE,ZLIB,GZIP)的压缩流. DeflateStream和GZipStream的工作方式与.NET内建类的方法相同,并且有一个ZlibStream类,那就是你所想的.这些类都没有表现出我上面描述的行为异常.

在代码中,它看起来像这样：

byte[] original = new byte[] {
        0x0E,0x7C,0xBD,0x03,0x6E,0x65,0x67,0x6C,0x63,0x74,0x00,0x42,0x52,0x01,0x02,0xBB,0x14,0x8D,0x37,0x05,0xE9,0x81,0x00
    };

    var compressed = Ionic.Zlib.ZlibStream.CompressBuffer(original);

输出如下：

0000    78 DA E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03     x...........\...
0010    4E 41 0C 0C 8C 4C 8C 0C BB 45 7A CD 61 62 AC 2F     NA...L...Ez.ab./
0020    19 B0 82 46 46 2C 82 AC 40 FD 40 0A 00 35 25 07     ...FF,..@.@..5%.
0030    CE                                                  .

要解压缩,

var uncompressed = Ionic.Zlib.ZlibStream.UncompressBuffer(compressed);

你可以看到the documentation on the static CompressBuffer method.

编辑

提出了问题,为什么DotNetZip在前两个字节而不是78 9C时产生78 DA？差异是无关紧要的. 78 DA编码“最大压缩”,而78 9C编码“默认压缩”.正如你在数据中可以看到的,对于这个小样本,实际的压缩字节是完全一样的,不管是使用BEST还是DEFAULT.此外,解压缩期间不使用压缩级别信息.它对您的应用程序没有影响.

如果你不想要“最大”压缩,如果你设置得到78 9C作为前两个字节,即使没有关系,那么你不能使用CompressBuffer方便功能,它使用最好的封面下的压缩水平.相反,你可以这样做：

var compress = new Func<byte[],byte[]>( a => {
        using (var ms = new System.IO.MemoryStream())
        {
            using (var compressor =
                   new Ionic.Zlib.ZlibStream( ms,CompressionMode.Compress,CompressionLevel.Default )) 
            {
                compressor.Write(a,a.Length);
            }

            return ms.ToArray();
        }
    });

  var original = new byte[] { .... };
  var compressed = compress(original);

结果是：

0000    78 9C E3 AB D9 CB 9C 97 9A 9E 93 9A 5C C2 00 03     x...........\...
0010    4E 41 0C 0C 8C 4C 8C 0C BB 45 7A CD 61 62 AC 2F     NA...L...Ez.ab./
0020    19 B0 82 46 46 2C 82 AC 40 FD 40 0A 00 35 25 07     ...FF,..@.@..5%.
0030    CE                                                  .