代码之家  ›  专栏  ›  技术社区  ›  kealist

在Win32和Linux-64位之间使用zlib进行压缩的结果不一致

  •  5
  • kealist  · 技术社区  · 7 年前

    "foo" 在Windows上压缩 1F8B080000000000000A4BCBCF07002165738C03000000 和Linux 1F8B08000000000000034BCBCF07002165738C03000000 .都解压缩回“foo”

    Linux: echo -n foo| ./minigzip64 > text.txt'

    窗户: echo|set /p="foo" | minigzip > text.txt

    什么可以解释这种差异?这是个问题吗?

    1F8B 0800 0000 0000 000 *3/A* 4BCB CF07 0021 6573 8C03 0000 00

    2 回复  |  直到 7 年前
        1
  •  7
  •   Mark Adler    7 年前

    首先,如果它解压缩到被压缩的状态,那么这不是问题。不同的压缩机,或处于不同设置的同一压缩机,甚至具有相同设置但不同版本的同一压缩机,可以从相同输入产生不同的压缩输出。

    其次,这种情况下的压缩数据是相同的。只有最后一个字节

    即使在同一个操作系统上,标题也可能有所不同,因为它带有修改日期和时间。然而,在这两种情况下,修改日期和时间都被省略(设置为零)。

        2
  •  4
  •   Community Paul Sweatte    3 年前

    窗户:

    gzip-win

    Linux:

    gzip-linux

    您可以立即注意到,唯一不同的字段是 .

    数据的含义

    Header                 Data         Footer
    1F8B080000000000000A | 4BCBCF0700 | 2165738C03000000
    

    让我们把它分解一下。

    this answer 我意识到这实际上是一个 兹利布

    Level   ZLIB    GZIP 
      1   | 78 01 | 1F 8B 
      9   | 78 DA | 1F 8B 
    

    进一步的搜索让我找到了一篇关于 Gzip 这种情况下的值为:

    Offset   Size   Value   Description
    0      | 2    | 1f8b | Signature (or identification byte 1 and 2)
    2      | 1    | 08   | Compression Method (deflate)
    3      | 1    |      | Flags
    4      | 4    |      | Last modification time
    8      | 1    |      | Compression flags (or extra flags)
    9      | 1    | 0A   | Operating system (TOPS-20)
    

    页脚

    Offset   Size   Value    Description
    0      | 4    | 2165738C | Checksum (CRC-32) (Little endian)
    4      | 4    | 03       | Uncompressed data size Value in bytes.
    

    上次修改时间 操作系统 页脚中具有相同的校验和。

    IETF RFC 有更详细的格式摘要