gzip,deflate,zlib辨析

川长思鸟来 2022-07-16 06:42 262阅读 0赞

[deflate][](RFC1951):一种压缩[算法][Link 1]，使用LZ77和哈弗曼进行编码；  
[zlib][](RFC1950):一种格式，是对[deflate][]进行了简单的封装，他也是一个实现库(delphi中有[zlib][],[zlib][]ex)  
[gzip][](RFC1952):一种格式，也是对[deflate][]进行的封装。

[gzip][] = [gzip][]头 + deflate编码的实际内容 + gzip尾  
zlib = zlib头 + deflate编码的实际内容 + zlib尾

因最近在做一些关于网页解码方面的事情，压缩都是gzip,deflate.

deflate返回的就是zlib格式。浏览器可以解压，但ie系列要求必需是纯正的deflate格式，故解压时必须手动的添加一个头和尾，原来采集finance.sina.com.cn上的数据就是deflate格式，今天看了下，改用gzip压缩了。当时，只在deflate数据前加了两个字节：\#$78\#$9c，就可以用zlib解压了。

gzip格式和deflate相比，有了一些头信息：  
GZIP文件由1到多个“块”组成，实际上通常只有1块。每个块包含头、数据和尾三部分。块的概貌如下：

\+—+—+—+—+—+—+—+—+—+—+========//========+===========//==========+—+—+—+—+—+—+—+—+  
|ID1|ID2| CM|FLG| MTIME |XFL| OS| 额外的头字段 | 压缩的数据 | CRC32 | ISIZE |  
\+—+—+—+—+—+—+—+—+—+—+========//========+===========//==========+—+—+—+—+—+—+—+—+  
1. 头部分  
ID1与ID2：各1字节。固定值，ID1 = 31 (0×1F)，ID2 = 139(0×8B)，指示GZIP格式。  
CM：1字节。压缩方法。目前只有一种：CM = 8，指示DEFLATE方法。  
FLG：1字节。标志。  
bit 0 FTEXT – 指示文本数据  
bit 1 FHCRC – 指示存在CRC16头校验字段  
bit 2 FEXTRA – 指示存在可选项字段  
bit 3 FNAME – 指示存在原文件名字段  
bit 4 FCOMMENT – 指示存在注释字段  
bit 5-7 保留

MTIME：4字节。更改时间。UINX格式。  
XFL：1字节。附加的标志。当CM = 8时，XFL = 2 – 最大压缩但最慢的算法；XFL = 4 – 最快但最小压缩的算法  
OS：1字节。[操作系统][Link 2]，确切地说应该是文件系统。有下列定义：  
0 – FAT文件系统 (MS-DOS, OS/2, NT/Win32)  
1 – Amiga  
2 – VMS/OpenVMS  
3 – Unix  
4 – VM/CMS  
5 – Atari TOS  
6 – HPFS文件系统 (OS/2, NT)  
7 – Macintosh  
8 – Z-System  
9 – CP/M  
10 – TOPS-20  
11 – NTFS文件系统 (NT)  
12 – QDOS  
13 – Acorn RISCOS  
255 – 未知

额外的头字段：  
(若 FLG.FEXTRA = 1)

\+—+—+—+—+===============//================+  
|SI1|SI2| XLEN | 长度为XLEN字节的可选项 |  
\+—+—+—+—+===============//================+  
(若 FLG.FNAME = 1)

\+=======================//========================+  
| 原文件名(以NULL结尾) |  
\+=======================//========================+  
(若 FLG.FCOMMENT = 1)

\+=======================//========================+  
| 注释文字(只能使用iso-8859-1字符，以NULL结尾) |  
\+=======================//========================+  
(若 FLG.FHCRC = 1)

\+—+—+  
| CRC16 |  
\+—+—+  
存在额外的可选项时，SI1与SI2指示可选项ID，XLEN指示可选项字节数。如 SI1 = 0×41 (‘A’)，SI2 = 0×70 (‘P’)，表示可选项是Apollo文件格式的额外数据。

2. 数据部分  
DEFLATE数据格式，包含一系列子数据块。子块概貌如下：

\+……+……+……+=============//============+  
|BFINAL| BTYPE | 数据 |  
\+……+……+……+=============//============+  
BFINAL：1比特。0 – 还有后续子块；1 – 该子块是最后一块。  
BTYPE：2比特。00 – 不压缩；01 – 静态Huffman编码压缩；10 – 动态Huffman编码压缩；11 – 保留。  
各种情形的处理过程，请参考后面列出的RFC文档。

3. 尾部分  
CRC32：4字节。原始(未压缩)数据的32位校验和。  
ISIZE：4字节。原始(未压缩)数据的长度的低32位。  
GZIP中字节排列顺序是LSB方式，即Little-Endian，与ZLIB中的相反。

deflate使用inflateInit()，而gzip使用inflateInit2()进行初始化，比 inflateInit()多一个参数: -MAX\_WBITS，表示处理raw deflate数据。因为gzip数据中的zlib压缩数据块没有zlib header的两个字节。使用inflateInit2时要求zlib库忽略zlib header。在zlib手册中要求windowBits为8..15，但是实际上其它范围的数据有特殊作用，见zlib.h中的注释，如负数表示raw deflate。  
Apache的deflate变种可能也没有zlib header，需要添加假头后处理。即MS的错误deflate (raw deflate).zlib头第1字节一般是0×78, 第2字节与第一字节合起来的双字节应能被31整除，详见rfc1950。例如Firefox的zlib假头为0×7801，[Python][] zlib.compress()结果头部为0×789c。

注：以上文字属于多段摘抄，非原创。收录于此，感谢原作者们。

[deflate]: http://abingle.com/tag/deflate
[Link 1]: http://lib.csdn.net/base/datastructure
[zlib]: http://abingle.com/tag/zlib
[gzip]: http://abingle.com/tag/gzip
[Link 2]: http://lib.csdn.net/base/operatingsystem
[Python]: http://lib.csdn.net/base/python