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

Question

在程序中使用zlib，发现在scroll_to()和Linux Gtk::TextView上压缩"foo"的方式有一点差异。两者都减压回到了＃f;＆＃34;

我决定在我们的代码外面查看实现是否正确，并使用zlib存储库中的测试程序进行双重检查。我得到了同样的结果：

Linux：1F8B080000000000000A4BCBCF07002165738C03000000

Windows：1F8B08000000000000034BCBCF07002165738C03000000

这会产生什么影响呢？这是一个问题吗？

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

Answer 1

首先，如果它解压缩到压缩的内容，那么它不是问题。不同的压缩机，或不同设置的相同压缩机，甚至是相同设置但不同版本的相同压缩机，可以从同一输入产生不同的压缩输出。

其次，这种情况下的压缩数据是相同的。只有最后一个字节 压缩数据之前的gzip标头的不同之处。该字节标识原始操作系统。因此，它在Linux和Windows之间有所不同。

即使在同一操作系统上，标题也会有所不同，因为它带有修改日期和时间。但是，在您的两种情况下，修改日期和时间都被省略（设置为零）。

Answer 2

只是在这里添加到接受的答案。我很好奇并为自己尝试，保存原始数据并打开7zip：

窗：

Linux的：

您可以立即注意到唯一与主机操作系统不同的字段。

数据意味着什么

Header                 Data         Footer
1F8B080000000000000A | 4BCBCF0700 | 2165738C03000000

让我们打破它。

标题

首先，从this answer开始，我意识到它实际上是 gzip 而不是 zlib 标头：

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有更详细的格式摘要