久久精品国产成人,国产女优一区,宅男精品视频

无损数据压羃

swo — Mon, 21 Aug 2006 06:20:00 GMT

数据压羃的�v源要比计��机的�v源早得多�Q�数据压�~�技术在计算机技术的萌芽时期��已�l�被提上了议事日�E�，军事�U�学家、数学家、电子学家一直在研究有关信息如何被高效存储和传递的问题。随着信息论的产生和发展，数据压羃也由热门话题演变成了真正的技术�?br />
数据压羃可分成两�U�类型，一�U�叫做无损压�~�，另一�U�叫做有损压�~��?br />�? 损压�~�是指��用压�~�后的数据进行重�?或者叫做还原，解压�~?�Q�重构后的数据与原来的数据完全相同；无损压羃用于要求重构的信号与原始信号完全一致的�? 合。磁盘文件的压羃��是一个很常见的例子。根据目前的技术水�q�I��无损压羃��法一般可以把普通文件的数据压羃到原来的1/2�?/4�?br />有损压羃是指使用压羃后的数据�q�行重构�Q�重构后的数据与原来的数据有所不同�Q�但不会让�h对原始资�?br />�? 辄��信息造成误解。有损压�~�适用于重构信号不一定非要和原始信号完全相同的场合。例如，囑փ�和声音的压羃��可以采用有损压�~�，因�ؓ其中包含的数据往往多于我们的视觉系�l�和听觉�pȝ��所能接收的信息�Q�丢掉一些数据而不至于对声��x��者图像所表达的意思��生误解，但可大大提高压羃比�?br />
压羃技术大致可以按照以下的�Ҏ��分类�Q?br />                                                                                       压羃技�?br />                                                                                               |
                                                                         /------------------------------\
                                                        通用无损数据压羃             多媒体数据压�~?大多为有损压�~?
                                                                       |                                                         |
                                                          /----------------\                  /------------------------------------\
                                                  ��Z��l�计          ��Z��字典   音频压羃         囑փ�压羃               视频压羃
                                                   模型的压         模型的压         |                         |                                 |
                                                  �~�技�?            �~�技�?        MP3�{?    /-------------------\            AVI
                                                        |                         |                               二�?灰度彩色矢量       MPEG2�{?br />                                                    /------\         /-------------\                    囑փ� 囑փ� 囑փ� 囑փ�
                                            Huffman ��术 LZ77 LZ78 LZW                     |         |         |        \
                                            �~�码     �~�码     \-------------/                传真�?FELICS GIF         PostScript
                                                |             |                     |                         标准     JPEG�{?JPEG�{?Windows WMF�{?br />                                   UNIX�?          接近无损       PKZIP、LHarc、ARJ�?br />                                   的COMPACT 压羃极限        UNIX下的COMPRESS
                                   �E�序�{�           �?的高�U�应用    程序等

通用无损数据压羃的历�?br />�U�学家在研究中发玎ͼ�大多��C��息的表达都存在着一定的冗余度，通过采用一定的模型和编码方法，可以
降低�q�种冗余度。贝��实验室�?Claude Shannon �?MIT �?R.M.Fano 几乎同时提出了最早的对符可��行有
效编码从而实现数据压�~�的 Shannon-Fano �~�码�Ҏ��?br />
D.A.Huffman �?952�q�第一�ơ发表了他的论文“最��冗余代码的构造方法�?A Method for the Construction of Minimum Redundancy Codes)。从此，数据压羃开始在商业�E�序中实现�ƈ被应用在许多技术领域。UNIX �pȝ��上一个压�~�程�?COMPACT ��是 Huffman 0 阶自适应�~�码的具体实现�?0 �q�代初，Huffman�~�码又在CP/M 和DOS �pȝ��中实玎ͼ�其代表程序叫 SQ。在数据压羃领域�Q�Huffman 的这一论文事实上开创了数据压羃技术一个值得回忆的时代，60 �q�代�?0 �q�代乃至 80 �q�代的早期，数据压羃领域几乎一直被 Huffman �~�码及其分支所垄断。如果不是后面将要提到的那两个以色列人，也许我们今天�q�要�? Huffman�~�码�?0 �?1 的组合中��连忘返�?br />
80�q�代�Q�数学家们不满��?Huffman �~�码中的某些致命��q��Q�他们从新的角度入手�Q�遵�?Huffman �~�码的主导思想�Q�设计出另一�U�更为精��，更能接近信息��Z��“熵”极限的�~�码�Ҏ��——算术编码。凭借算术编码的�_�֦�设计和卓��表玎ͼ��Z��l�于可以向着数据�? �~�的极限前进了。可以证明，��术�~�码得到的压�~�效果可以最大地减小信息的冗余度�Q�用最��量的符��L��表辑֎�始信息内宏V��当�Ӟ��术�~�码同时也给�E�序员和�? ��机带来了新的挑战：要实现和�q�行��术�~�码�Q�需要更��苦的�~�程力_��和更加快速的计算机系�l�。也��是�Q�在同样的计��机�pȝ��上，��术�~�码虽然可以得到最好的压羃效果�Q�但却要消耗也许几十倍的计算时。这��是��Z��么算术编码不能在我们日常使用的压�~�工具中实现的主要原因�?br />
那么�Q�能不能既在压羃�? 果上��越 Huffman�Q�又不增加程序对�pȝ��资源和时间的需求呢�Q�我们必��L��谢下面将要介�l�的两个以色列�h。直�?1977 �q�_��数据压羃的研�I�工作主要集中于��c��字�W�和单词频率以及�l�计模型�{�方面，研究者们一直在�l�尽脑汁��Z��用Huffman�~�码的程序找出更快、更好的改进�? 法�?977 �q�以后，一切都改变了�?br />
1977 �q�_��以色列�h Jacob Ziv �?Abraham Lempel 发表了论文“顺序数据压�~�的一个通用��法�?A Universal Alogrithem for Sequential Data Compression)�?978 �q�_��他们发表了该论文的箋��“通过可变比率�~�码的独立序列的压羃�?Compression of Individual Sequences via Variable-Rate Coding)。在�q�两��论文中提出的压�~�技术分别被�U�Cؓ LZ77 �?LZ78 (不知��Z��么，作者名字的首字母被倒置�?。简单地��_��q�两�U�压�~�方法的思�\完全不同于从 Shannon �?Huffman 到算术压�~�的传统思�\�Q��h们将��Z��q�一思�\的编码方法称作“字典”式�~�码。字典式�~�码不但在压�~�效果上大大��过�? Huffman�Q�而且�Q�对于好的实玎ͼ�其压�~�和解压�~�的速度也异常惊人�?br />
1984 �q�_��Terry Welch 发表了名为“高性能数据压羃技术�?A Technique for High-Performance Data Compression)的论文，描述了他�?Sperry Research Center(现在是Unisys的一部分)的研�I�成果。他实现了LZ78 ��法的一个变�U?—�?LZW。LZW �l�承�?LZ77 �?LZ78 压羃效果好、速度快的优点�Q�而且在算法描�q�C��更容易被��Z��接受�Q�有的研�I�者认为是�׃�� Welch 的论文比 Ziv �?Lempel 的更�Ҏ��理解�Q�，实现也比较简单。不久，UNIX 上出��C��使用 LZW ��法�?Compress �E�序�Q�该�E�序性能优良�Q��ƈ有高水��^的文档，很快成�ؓ�?UNIX 世界的压�~�程序标准。紧随其后的�?MS-DOS 环境下的ARC�E�序( System Enhancement Associates, 1985 )�Q�还有象 PKWare、PKARC �{�仿制品。LZ78和LZW一旉��l�治了UNIX和DOS两大�q�_��?br />
80 �q�代中期以后�Q��h们对 LZ77 �q�行了改�q�，随之诞生了一�Ҏ��们今天还在大量��用的压羃�E�序。Haruyasu Yoshizaki(Yoshi)的LHarc和Robert Jung的ARJ是其中两个著名的例子。LZ77得以和LZ78、LZW一起垄断当今的通用数据压羃领域�?br />
目前�Q�基于字典方式的压羃已经有了一个被�q�泛认可的标准，从古老的PKZip到现在的WinZip�Q�特别是�?br />着Internet上文件传输的��行�Q�ZIP 格式成�ؓ了事实上的标准，没有哪一�U�通用的文件压�~�、归档系�l�不�?br />�?ZIP 格式。本章主要介�l�目前用得最多和技术最成熟的无损压�~�编码技术，包括包含霍夫�?Huffman)�~�码、算术编码、RLE�~�码和词典编�?。注意有一部分压羃��法受到��国专利法的保护�Q�例�?LZW ��法的某些部分和高阶��术压羃��法的某些细节等�Q��?br />
4.1 仙农-范诺与霍夫曼�~�码
4.1.1 仙农-范诺�Q�Shannon-Fano�Q�编�?br />仙农-范诺�~�码��法需要用��C��面两个基本概念：
1. Entropy(�?
(1) 熉|��信息量的度量�Ҏ��Q�表�C�Z��条信息中真正需要编码的信息量。事件发生的可能性越��（数学上就
是概率越��）�Q�表�C�某一事�g出现的消息越多�?br />(2) 某个事�g的信息量用Ii=-log2 pi表示�Q�有时称为surprise�Q�，其中pi为第i个事件的概率�Q? pi 1�Ҏ��?为底�Ӟ��늚�单位�?bits"�?br />2. 信源S的熵
按照仙农(Shannon)的理论，信源S的熵定义�?br />其中pi是符号si在S中出现的概率�Q�log2(1/ pi)表示包含在si中的信息量，也就是编码si所需要的位数�?br />例如�Q�一�q�用256�U�灰度表�C�的囑փ��Q�如果每一个象素点灰度的概率均为pi=1/256�Q�编码每一个象素点��需
�?位。（最大熵分布�Q?br />最��熵分布�Q?除了一个符号外其余�W�号的概率全�?�Q�H�Q?bits.�Q�定�?log20�Q?�Q?br />
例如�Q�对下面�q�条只出��C�� a b c 三个字符的字�W�串�Q�aabbaccbaa�Q�字�W�串长度�?10�Q�字�W?a b c �?br />别出��C�� 5 3 2 �ơ，�?a b c 在信息中出现的概率分别�ؓ 0.5 0.3 0.2�Q�他们的熵分别�ؓ�Q?br />Ea = -log2(0.5) = 1
Eb = -log2(0.3) = 1.737
Ec = -log2(0.2) = 2.322
整条信息的熵也即表达整个字符串需要的位数为：
Ea * 5 + Eb * 3 + Ec * 2 = 14.855 �?br />如果用计��机中常用的 ASCII �~�码�Q�表�C�Z��面的字符串需要整�?0位！信息��Z��么能被压�~�而不丢失�?br />有的信息内容呢？��单地�Ԍ��用较��的位数表示较频�J�出现的�W�号�Q�这��是数据压羃的基本准则。（怎样�?0
1 �q�样的二�q�制数码表示零点几个二进制位呢？��实很困难，但不是没有办法。一旦找��C��准确表示零点几个
二进制位的方法，��接�q�无损压�~�的极限了。）
[�?.1] 有一�q?0个象素组成的灰度囑փ��Q�灰度共�?�U�，分别用符号A、B、C、D和E表示�Q?0个象素中�?br />现灰度A的象素数�?5个，出现灰度B的象素数�?个，出现灰度C的象素数�?个等�{�，如表4-01所�C��?br />如果�?个位表示�q?个等�U�的灰度��|��也就是每个象素用3位表�C?�{�长�~�码)�Q�编码这�q�图像��d��需�?20
位�?br />�?-01 �W�号在图像中出现的数�?br />按照仙农理论�Q�这�q�图像的熵�ؓ H(S)=(15/40)×log2(40/15) + (7/40)×log2(40/7) +�?+ (5/40)
×log2(40/5) = 2.196
�q�就是说每个�W�号�?.196位表�C�，40个象素需�?7.84位�?br />最早阐�q�和实现�q�种�~�码的是Shannon(1948�q?和Fano(1949�q?�Q�因此被�U�Cؓ仙农-范诺(Shannon-Fano)��?br />法。这�U�方法采用从上到下的�Ҏ��q�行�~�码�?br />首先按照�W�号出现的频度或概率排序�Q�例如，A�Q�B�Q�C�Q�D和E�Q�如�?-02所�C��?br />然后使用递归�Ҏ��分成两个部分�Q�每一部分��h��q�似相同的次敎ͼ�如图4-01所�C��?br />按照�q�种�Ҏ��q�行�~�码得到的��M��Cؓ91�Q�实际的压羃比约�?.3 : 1�?br />�?-02 Shannon-Fano��法举例�?br />�W?�?A B C D E
出现的次�?15 7 7 6 5
�W�号出现的次�?pi) log2(1/pi) 分配的代�?需要的位数
A 15 (0.375) 1.4150 00 30
B 7 (0.175) 2.5145 01 14
C 7 (0.175) 2.5145 10 14
D 6 (0.150) 2.7369 110 18
E 5 (0.125) 3.0000 111 15
�W?4 ��?br />4
�?-01 仙农-范诺��法�~�码举例
4.1.2 霍夫�?Huffman)�~�码
霍夫曼在1952�q�提��Z��另一�U�编码方法，即从下到上的�~�码�Ҏ��。现以一个具体的例子说明它的�~�码�?br />骤：
(1) 初始化，�Ҏ��W�号概率的大��按由大到小��序对符可��行排序，如表4-03和图4-02所�C��?br />(2) 把概率最��的两个�W�号�l�成一个节点，如图4-02中的D和E�l�成节点P1�?br />(3) 重复步骤2�Q�得到节点P2、P3和P4�Q��Ş成一��“树”，其中的P4�U�Cؓ根节炏V�?br />(4) 从根节点P4开始到相应于每个符��L��“树叶”，从上��C��标上�?�?上枝)或者�?�?下枝)�Q�至于哪
个�ؓ�?”哪个�ؓ�?”则无关紧要�Q�最后的�l�果仅仅是分配的代码不同�Q�而代码的�q�_��长度是相同的�?br />(5) 从根节点P4开始顺着树枝到每个叶子分别写出每个符��L��代码�Q�如�?-03所�C��?br />(6) 按照仙农理论�Q�这�q�图像的熵�ؓ
H(S)=(15/39)×log2(39/15) + (7/39)×log2(39/7) + �?+ (5/39)×log2(39/5) = 2.1859
压羃�?.37:1�?br />�?-03 霍夫曼编码�D�?br />�?-02 霍夫曼编码方�?br />霍夫曼码的码长虽然是可变的，但却不需要另外附加同步代码（前缀代码�Q�。例如，码串中的�W?位�ؓ0�Q?br />那末肯定是符号A�Q�因��C�其他符��L��代码没有一个是�?开始的�Q�因此下一位就表示下一个符号代码的�W?
�W�号出现的次�?pi) log2(1/pi) 分配的代�?需要的位数
A 15(0.3846) 1.38 0 15
B 7(0.1795) 2.48 100 21
C 6(0.1538) 2.70 101 18
D 6(0.1538) 2.70 110 18
E 5(0.1282) 2.96 111 15
�W?5 ��?br />4
位。同��P��如果出现�?10”，那么它就代表�W�号D。如果事先编写出一本解释各�U�代码意义的“词典”，即码
��，那么��可以根据码��一个码一个码��C��ơ进行译码�?br />与仙�?范诺�~�码相同�Q�这两种�Ҏ��都自含同步码�Q�在�~�码之后的码串中不需要另外添加标记符��P��卛_��
译码时分割符��L��Ҏ��代码�Q��?br />采用霍夫曼编码时有两个问题值得注意�Q?br />①霍夫曼码没有错误保护功能，在译码时�Q�如果码串中没有错误�Q�那么就能一个接一个地正确译出代码�?br />但如果码串中有错误，哪怕仅仅是1位出现错误，不但�q�个码本�w�译错，更糟�p�的是一错一大串�Q�全�׃��套，
�q�种现象�U�Cؓ错误传播(error propagation)。计��机对这�U�错误也无能为力�Q�说不出错在哪里�Q�更谈不上去
�U�正它�?br />②霍夫曼码是可变长度码，因此很难随意查找或调用压�~�文件中间的内容�Q�然后再译码�Q�这��需要在存储
代码之前加以考虑�?br />��管如此�Q�霍夫曼码还是得到广泛应用�?霍夫曼编码方法的�~�码效率比仙�?范诺�~�码效率高一些�?br />4.2 ��术�~�码
��术�~�码在图像数据压�~�标�?如JPEG�Q�JBIG)中扮演了重要的角艌Ӏ�在��术�~�码中，消息�?�?之间的实
数进行编码，��术�~�码用到两个基本的参敎ͼ��W�号的概率和�~�码间隔。信源符��L��概率军_��压羃�~�码的效率，
也决定编码过�E�中信源�W�号的间隔，而这些间隔包含在0�?之间。编码过�E�中的间隔决定了�W�号压羃后的�?br />出。算术编码器的编码过�E�可用下面的例子加以解释�?br />[�?.2] 假设信源�W�号为{00, 01, 10, 11}�Q�这些符��L��概率分别为{ 0.1, 0.4, 0.2, 0.3 }�Q�根据这�?br />概率可把间隔[0, 1)分成4个子间隔�Q�[0, 0.1), [0.1, 0.5), [0.5, 0.7), [0.7, 1)�Q�其中[x,y)表示半开�?br />间隔�Q�即包含x不包含y。上面的信息可综合在�?-04中�?br />�?-04 信源�W�号�Q�概率和初始�~�码间隔
如果二进制消息序列的输入为：10 00 11 00 10 11 01。编码时首先输入的符��h��10�Q�找到它的编码范�?br />是[0.5, 0.7)。消息中�W�二个符�?0的编码范围是[0, 0.1)�Q�因此就取[0.5, 0.7)的第一个十分之一作�ؓ新间
隔[0.5, 0.52)。依此类推，�~�码�W?个符�?1时取新间隔�ؓ[0.514, 0.52)�Q�编码第4个符�?0�Ӟ��取新间隔�?br />[0.514, 0.5146)�Q��?。消息的�~�码输出可以是最后一个间隔中的�Q意数。整个编码过�E�如�?-03所�C��?br />�W�号 00 01 10 11
概率 0.1 0.4 0.2 0.3
初始�~�码间隔 [0, 0.1) [0.1, 0.5) [0.5, 0.7) [0.7, 1)
�W?6 ��?br />4
�?-03 ��术�~�码�q�程举例
�q�个例子的编码和译码的全�q�程分别表示在表4-05和表4-06中�?br />�Ҏ��上面所丄��例子�Q�可把计��过�E��ȝ��如下�?br />考虑一个有M个符号i=(1,2,�?M)的字�W�表集，假设概率p( i)=pi�Q��?br />。输入符��L��xn表示�Q�第n个子间隔的范围用
表示。其中l0=0�Q�d0=1和p0=0�Q�ln表示间隔左边界的�?rn 表示�?br />隔右边界的��|��dn=rn-ln表示间隔长度。编码步骤如下：
步骤1�Q�首先在1�?之间�l�每个符号分配一个初始子间隔�Q�子间隔的长度等于它的概率，初始子间隔的�?br />围用I1=[l1�Q�r1)=[ �Q?)表示。��od1=r1-l1�Q�L=l1和R=r1�?br />步骤2�Q�L和R的二�q�制表达式分别表�C�Zؓ�Q?br />�?br />其中ui 和vi �{�于�?”或者�?”�?br />①如果u1
≠v1 �Q�不发送�Q何数据，转到步骤3�Q?br />②如果u1=v1�Q�就发送二�q�制�W�号u1�?br />比较u2
和v2�Q�如果u2≠v2 �Q�不发送�Q何数据，转到步骤3�Q?br />如果u2=v2�Q�就发送二�q�制�W�号u2�?br />�?br />�q�种比较一直进行到两个�W�号不相同�ؓ止，然后�q�入步骤3�?br />步骤3�Q�n�?�Q�读下一个符受��假讄��n个输入符号�ؓxn= i�Q�按照以前的步骤把这个间隔分成如下所�C�的
子间隔：
�W?7 ��?br />4
令L=ln�Q�R=rn �?dn=rn-ln�Q�然后�{到步�?�?br />�?-05 �~�码�q�程
�?-06 译码�q�程
[�?.3] 假设�?个符��L��信源�Q�它们的概率如表4-07所�C�：
�?-07 �W�号概率
输入序列为xn�Q?2�Q?1�Q?3�Q�…。它的编码过�E�如�?-04所�C�，现说明如下�?br />输入�W?个符��h��x1= 2�Q�可知i=2�Q�定义初始间隔＝[0.5, 0.75)�Q�由此可�?br />d1=0.25�Q�左双��界的二进制数分别表示为：L�Q?.5=0.1(B)�Q�R�Q?.7�Q?.11�?(B) 。按照步�?�Q�u1=v1�Q�发
�?。因u2≠v2�Q�因此�{到步�?�?br />输入�W?个字�W�x2= 1�Q�i=1�Q�它的子间隔�Q�[0.5, 0.625)�Q�由此可
得d2=0.125。左双��界的二进制数分别表示为：L�Q?.5=0.100 �?(B)�Q�R�Q?.101�?(B)。按照步�?�Q?br />u2=v2=0�Q�发�?�Q�而u3和v3不相同，因此在发�?之后��p�{到步�?�?br />输入�W?个字�W�，x3= 3�Q�i=3�Q�它的子间隔�Q�[0.59375, 0.609375)
�Q�由此可得d3=0.015625。左双��界的二进制数分别表示为：L�Q?.59375=0.10011 (B)�Q�R�Q?br />步骤输入�W�号 �~�码间隔 �~�码判决
1 10 [0.5, 0.7) �W�号的间隔范围[0.5, 0.7)
2 00 [0.5, 0.52) [0.5, 0.7)间隔的第一�?/10
3 11 [0.514, 0.52) [0.5, 0.52)间隔的最后三�?/10
4 00 [0.514, 0.5146) [0.514, 0.52)间隔的第一�?/10
5 10 [0.5143, 0.51442) [0.514, 0.5146)间隔的第五个1/10开始，二个1/10
6 11 [0.514384, 0.51442 [0.5143, 0.51442)间隔的最�?�?/10
7 01 [0.5143836, 0.514402) [0.514384, 0.51442)间隔�?�?/10�Q�从�W?�?/10开�?br />8 从[0.5143876, 0.514402)中选择一个数作�ؓ输出�Q?.5143876
步骤间隔译码�W�号译码判决
1 [0.5, 0.7) 10 0.51439在间�?[0.5, 0.7)
2 [0.5, 0.52) 00 0.51439在间�?[0.5, 0.7)的第1�?/10
3 [0.514, 0.52) 11 0.51439在间隔[0.5, 0.52)的第7�?/10
4 [0.514, 0.5146) 00 0.51439在间隔[0.514, 0.52)的第1�?/10
5 [0.5143, 0.51442) 10 0.51439在间隔[0.514, 0.5146)的第5�?/10
6 [0.514384, 0.51442) 11 0.51439在间隔[0.5143, 0.51442)的第7�?/10
7 [0.51439, 0.5143948) 01 0.51439在间隔[0.51439, 0.5143948)的第1�?/10
8 译码的消息：10 00 11 00 10 11 01
信源�W�号ai 1 2 3 4
概率pi p1=0.5 p2=0.25 p3=0.125 p4=0.125
初始�~�码间隔 [0, 0.5) [0.5, 0.75) [0.75, 0.875) [0.875, 1)
�W?8 ��?br />4
0.609375=0.100111 (B)。按照步�?�Q�u3=v3=0�Q�u4=v4=1�Q�u5=v5=1�Q�但u6和v6不相同，因此在发�?11之后转到
步骤3�?br />�?br />发送的�W�号是：10011…。被�~�码的最后的�W�号是结束符受��?br />�?-04 ��术�~�码概念
��p��个例子而言�Q�算术编码器接受的第1位是�?”，它的间隔范围��限制在[0.5, 1)�Q�但在这个范围里�?br />3�U�可能的码符2�Q?3�?�Q�因此第1位没有包含��够的译码信息。在接受�W?位之后就变成�?0”，它落�?br />[0.5, 0.75)的间隔里�Q�由于这两位表示的符号都指向2开始的间隔�Q�因此就可断定第一个符��h��2。在接受
每位信息之后的译码情况如下表4-08所�C��?br />�?-08 译码�q�程�?br />在上面的例子中，我们假定�~�码器和译码器都知道消息的长度，因此译码器的译码�q�程不会无限制地�q�行
下去。实际上在译码器中需要添加一个专门的�l�止�W�，当译码器看到�l�止�W�时��停止译码�?br />在算术编码中需要注意的几个问题�Q?br />(1) �׃��实际的计��机的精度不可能无限长，�q�算中出现溢出是一个明昄��问题�Q�但多数机器都有16位�?br />32位或�?4位的�_�ֺ��Q�因此这个问题可使用比例�~�放�Ҏ��解决�?br />(2) ��术�~�码器对整个消息只��生一个码字，�q�个码字是在间隔[0, 1)中的一个实敎ͼ�因此译码器在接受
到表�C��个实数的所有位之前不能�q�行译码�?br />(3) ��术�~�码也是一�U�对错误很敏感的�~�码�Ҏ��Q�如果有一位发生错误就会导致整个消息译错�?br />��术�~�码可以是静态的或者自适应的。在静态算术编码中�Q�信源符��L��概率是固定的。在自适应��术�~�码
中，信源�W�号的概率根据编码时�W�号出现的频�J�程度动态地�q�行修改�Q�在�~�码期间估算信源�W�号概率的过�E�叫
做徏模。需要开发动态算术编码的原因是因��Z��先知道精��的信源概率是很隄��Q�而且是不切实际的。当压羃
消息�Ӟ��我们不能期待一个算术编码器获得最大的效率�Q�所能做的最有效的方法是在编码过�E�中估算概率。因
此动态徏模就成�ؓ��定�~�码器压�~�效率的关键�?br />接受的数�?间隔译码输出
1 [0.5, 1) -
0 [0.5, 0.75) 2
0 [0.5, 0.609375) 1
1 [0.5625, 0.609375) -
1 [0.59375, 0.609375) 3
�?�?�?br />�W?9 ��?br />4
4.3 RLE�~�码
在一�q�图像中�l�常包含有许多颜色相同的囑֝�。在�q�些囑֝�中，许多行上都具有相同的颜色�Q�或者在一�?br />上有许多�q�箋的像素都��h��相同的颜色倹{��在�q�种情况下就不需要存储每一个像素的颜色��|��而仅仅存储一�?br />像素的颜色��|��以及��h��相同颜色的像素数目就可以�Q�或者存储一个像素的颜色��|��以及��h��相同颜色值的�?br />数。这�U�压�~�编码称��E�编�?run length encoding�Q�RLE)�Q�具有相同颜色�ƈ且是�q�箋的像素数目称��E?br />长度�?br />假定有一�q�灰度图像，�W�n行的像素值如�?-05所�C�：
�?-05 RLE�~�码的概�?br />用RLE�~�码�Ҏ��得到的代码�ؓ�Q?0315084180。代码中用黑体表�C�的数字是行�E�长度，黑体字后面的数字�?br />表像素的颜色倹{��例如黑体字50代表有连�l?0个像素具有相同的颜色��|��它的颜色值是8�?br />�Ҏ��RLE�~�码前后的代码数可以发现�Q�在�~�码前要�?3个代码表�C��一行的数据�Q�而编码后只要�?1个代
码表�C�Z��表原来的73个代码，压羃前后的数据量之比�U��ؓ7:1�Q�即压羃比�ؓ7:1。这说明RLE��实是一�U�压�~�技
术，而且�q�种�~�码技术相当直观，也非常经��?br />译码时按照与�~�码旉��用的相同规则�q�行�Q�还原后得到的数据与压羃前的数据完全相同�?br />RLE所能获得的压羃比有多大�Q�这主要是取决于囑փ�本��n的特炏V��如果图像中��h��相同颜色的图像块��?br />大，囑փ�块数目越��，获得的压�~�比��p��高。反之，压羃比就��小�?br />RLE压羃�~�码��其适用于计��机生成的图像，对减��图像文件的存储�I�间非常有效。然而，RLE寚w��色丰�?br />的自然图像就昑־�力不从心�Q�在同一行上��h��相同颜色的连�l�像素往往很少�Q�而连�l�几行都��h��相同颜色值的
�q�箋行数��更��。如果仍然��用RLE�~�码�Ҏ��Q�不仅不能压�~�图像数据，反而可能��原来的图像数据变得更
大。请注意�Q�这�q�不是说RLE�~�码�Ҏ��不适用于自然图像的压羃�Q�相反，在自然图像的压羃中还真少不了RLE�Q?br />只不�q�是不能单纯使用RLE一�U�编码方法，需要和其他的压�~�编码技术联合应用�?br />4.4 词典�~�码
有许多场合，开始时不知道要�~�码数据的统计特性，也不一定允�怽�事先知道它们的统计特性。因此，�?br />们提��Z��许许多多的数据压�~�方法，��可能获得最大的压羃比。这些技术统�U�Cؓ通用�~�码技术。词典编�?br />(Dictionary Encoding)技术就属于�q�一�c�R�?br />4.4.1 词典�~�码的思想
词典�~�码(dictionary encoding)的根据是数据本��n包含有重复代码这个特性。例如文本文件和光栅囑փ�
��具有这�U�特性。词典编码法的种�c�d��多，归纳��h��大致有两�c�R�?br />�W�一�c�词典算法是企图查找正在压羃的字�W�序列是否在以前输入的数据中出现�q�，然后输出仅仅是指向早
期出现过的字�W�串的“指针”。这�U�编码概念如�?-06所�C��?br />�W?10 ��?br />4
�?-06 �W�一�c�词典法�~�码概念
�q�里所指的“词典”是指用以前处理�q�的数据来表�C�编码过�E�中遇到的重复部分。这�cȝ��码算法都是以
Abraham Lempel和Jakob Ziv�?977�q�开发和发表的称为LZ77��法为基��的，例如1982�q�由Storer和Szymanski
改进的称为LZSS��法 �?br />�W�二�c�词典算法是企图从输入的数据中创��Z��个“短语词�?dictionary of the phrases)”，�q�种短语
不一定是��h��具体含义的短语，可以是�Q意字�W�的�l�合。编码过�E�中遇到已经在词�怸�出现的“短语”时�Q�编
码器��p��个词�怸�的短语的“烦引号”，而不是短语本�w�。这个概念如�?-07所�C��?br />�?-07 �W�二�c�词典法�~�码概念
J.Ziv和A.Lempel�?978�q�首�ơ发表了介绍�q�种�~�码�Ҏ��的文章。在他们的研�I�基��上，Terry A.Weltch
�?984�q�发表了改进�q�种�~�码��法的文章，因此把这�U�编码方法称为LZW(Lempel-Ziv Walch)压羃�~�码�Q�在�?br />速硬盘控制器�?首先应用了这�U�算法�?br />4.4.2 LZ77��法
��Z��更好地说明LZ77��法的原理，首先介绍��法中用到的几个术语�Q?br />(1) 输入数据��?input stream)�Q�要被压�~�的字符序列�?br />(2) 字符(character)�Q�输入数据流中的基本单元�?br />(3) �~�码位置(coding position)�Q�输入数据流中当前要�~�码的字�W�位�|�，指前向缓冲存储器中的开始字
�W��?br />(4) 前向�~�冲存储�?Lookahead buffer)�Q�存放从�~�码位置到输入数据流�l�束的字�W�序列的存储器�?br />(5) �H�口(window)�Q�指包含W个字�W�的�H�口�Q�字�W�是从编码位�|�开始向后数�Q�也��是最后处理的W个字
�W?�?滑动�H�口)
(6) 指针(pointer)�Q�指向窗口中的匹配串的开始位�|�且含长度的指针�?br />LZ77�~�码��法的核心是查找从前向缓冲存储器开始的与窗口中最长的匚w��丌Ӏ�编码算法的具体执行步骤�?br />下：
�W?11 ��?br />4
(1) 把编码位�|�设�|�到输入数据��的开始位�|��?br />(2) 查找�H�口中最长的匚w��丌Ӏ?br />(3) 以�?Pointer, Length) Character”三元组的格式输出，其中Pointer是指向窗口中匚w��串的指针�Q?br />Length表示匚w��字符的长度，Characters是前向缓冲存储器中的不匹配的�W?个字�W�。没有匹配的字符串时�Q?br />输出�?0, 0) Character�?br />(4) 如果前向�~�冲存储器不是空的，则把�~�码位置和窗口向前移(Length+1)个字�W�，然后�q�回到步�?�?br />[�?.4] 待编码的数据��如�?-09所�C�，�~�码�q�程如表4-10所�C�。现作如下说明：
(1) “步骤”栏表示�~�码步骤�?br />(2) “位�|�”栏表示�~�码位置�Q�输入数据流中的�W?个字�W��ؓ�~�码位置1�?br />(3) “匹配串”栏表示�H�口中找到的最长的匚w��丌Ӏ?br />(4) “字�W�”栏表示匚w��之后在前向缓冲存储器中的�W?个字�W��?br />(5) “输出”栏以�?Back_chars, Chars_length) Explicit_character”格式输出。其中，
(Back_chars, Chars_length)是指向匹配串的指针，告诉译码器“在�q�个�H�口中向后退Back_chars个字�W�然�?br />拯��Chars_length个字�W�到输出”，Explicit_character是真实字�W�。例如，�?-10中的输出�?5,2) C”告
诉译码器回退5个字�W�，然后拯��2个字�W�“AB�?br />�?-09待编码的数据��?br />�?-10 �~�码�q�程
4.4.3 LZSS��法
LZ77通过输出真实字符解决了在�H�口中出现没有匹配串的问题，但这个解��x��案包含有冗余信息。冗余信
息表现在两个斚w��Q�一是空指针�Q�二是编码器输出的字�W�可能包含在下一个匹配串中的字符�?br />LZSS��法以比较有效的�Ҏ��解决�q�个问题�Q�思想是如果匹配串的长度比指针本��n的长�?�Q�最��匹配串�?br />度）长就输出指针�Q�否则就输出真实字符。由于输出的压羃数据��中包含有指针和字符本��n�Q��ؓ了区分它们就
需要有额外的标志位�Q�即ID位�?br />LZSS�~�码��法的具体执行步骤如下：
(1) 把编码位�|�置于输入数据流的开始位�|��?br />(2) 在前向缓冲存储器中查找与�H�口中最长的匚w��?br />�?Pointer �Q?匚w��串指针�?br />�?Length �Q?匚w��串长度�?br />(3) 判断匚w��串长度Length是否大于�{�于最��匹配串长度(Length≥MIN_LENGTH)�Q?br />如果“是”：输出指针�Q�然后把�~�码位置向前�U�d��Length个字�W��?br />位置 1 2 3 4 5 6 7 8 9
字符 A A B C B B A B C
步骤位置匚w��?字符输出
1 1 -- A (0,0) A
2 2 A B (1,1) B
3 4 -- C (0,0) C
4 5 B B (2,1) B
5 7 A B C (5,2) C
�W?12 ��?br />4
如果“否”：输出前向�~�冲存储器中的第1个字�W�，然后把编码位�|�向前移动一个字�W��?br />(4) 如果前向�~�冲存储器不是空的，��p��回到步骤2�?br />[�?.5] �~�码字符串如�?-11所�C�，�~�码�q�程如表4-12所�C�。现说明如下�Q?br />(1) “步骤”栏表示�~�码步骤�?br />(2) “位�|�”栏表示�~�码位置�Q�输入数据流中的�W?个字�W��ؓ�~�码位置1�?br />(3) “匹配”栏表示�H�口中找到的最长的匚w��丌Ӏ?br />(4) “字�W�”栏表示匚w��之后在前向缓冲存储器中的�W?个字�W��?br />(5) “输出”栏的输��Zؓ�Q?br />�?如果匚w��串本�w�的长度Length≥MIN_LENGTH�Q�输出指向匹配串的指针，格式�?Back_chars,
Chars_length)。该指针告诉译码器“在�q�个�H�口中向后退Back_chars个字�W�然后拷贝Chars_length个字�W�到
输出”�?br />�?如果匚w��串本�w�的长度Length≤MIN_LENGTH�Q�则输出真实的匹配串�?br />�?-11 输入数据��?br />�?-12 �~�码�q�程(MIN_LENGTH = 2)
在相同的计算环境下，LZSS��法比LZ77可获得比较高的压�~�比�Q�而译码同��L��单。这也就是�ؓ什么这�U�算
法成为开发新��法的基��Q�许多后来开发的文档压羃�E�序都��用了LZSS的思想。例如，PKZip, ARJ, LHArc�?br />ZOO�{�等�Q�其差别仅仅是指针的长短和窗口的大小�{�有所不同�?br />LZSS同样可以和熵�~�码联合使用�Q�例如ARJ��׃��霍夫曼编码联用，而PKZip则与Shannon-Fano联用�Q�它的后
�l�版本也采用霍夫曼编码�?br />4.4.4 LZ78��法
在介�l�LZ78��法之前�Q�首先说明在��法中用到的几个术语和符��P��
(1) 字符��?Charstream)�Q�要被编码的数据序列�?br />(2) 字符(Character)�Q�字�W�流中的基本数据单元�?br />(3) 前缀(Prefix)�Q?在一个字�W�之前的字符序列�?br />(4) �~�-�W�串(String)�Q�前�~��Q�字�W��?br />(5) 码字(Code word)�Q�码字流中的基本数据单元�Q�代表词�怸�的一串字�W��?br />(6) 码字��?Codestream)�Q?码字和字�W�组成的序列�Q�是�~�码器的输出�?br />(7) 词典(Dictionary)�Q?�~�-�W�串表。按照词�怸�的烦引号�Ҏ��条缀-�W�串(String)指定一个码�?Code
位置 1 2 3 4 5 6 7 8 9 10 11
字符 A A B B C B B A A B C
步骤位置匚w��?输出
1 1 -- A
2 2 A A
3 3 -- B
4 4 B B
5 5 -- C
6 6 B B (3,2)
7 8 A A B (7,3)
8 11 C C
�W?13 ��?br />4
word)�?br />(8) 当前前缀(Current prefix)�Q�在�~�码��法中��用，指当前正在处理的前缀�Q�用�W�号P表示�?br />(9) 当前字符(Current character)�Q�在�~�码��法中��用，指当前前�~�之后的字�W�，用符号C表示�?br />(10) 当前码字(Current code word)�Q?在译码算法中使用�Q�指当前处理的码字，用W表示当前码字�Q?br />String.W表示当前码字的缀-�W�串�?br />1. �~�码��法
LZ78的编码思想是不断地从字�W�流中提取新的缀-�W�串(String)�Q�通俗地理解�ؓ新“词条”，然后用“代
号”也��是码字(Code word)表示�q�个“词条”。这样一来，对字�W�流的编码就变成了用码字(Code word)��L��
换字�W�流(Charstream)�Q�生成码字流(Codestream)�Q�从而达到压�~�数据的目的�?br />在编码开始时词典是空的，不包含�Q何缀-�W�串(string)。在�q�种情况下编码器��p��Z��个表�C�空字符�?br />的特�D�码�?例如�?�?和字�W�流�?Charstream)的第一个字�W�C�Q��ƈ把这个字�W�C��d��到词�怸�作�ؓ一个由一
个字�W�组成的�~�-�W�串(string)。在�~�码�q�程中，如果出现�c�M��的情况，也照此办理�?br />在词�怸�已经包含某些�~�-�W�串(String)之后�Q�如果“当前前�~�P +当前字符C”已�l�在词典中，��q��字符C
来扩展这个前�~��Q�这��L��扩展操作一直重复到获得一个在词典中没有的�~�-�W�串(String)为止。此时就输出�?br />�C�当前前�~�P的码�?Code word)和字�W�C�Q��ƈ把P+C��d��到词�怸��Q�然后开始处理字�W�流(Charstream)中的下一
个前�~��?br />LZ78�~�码器的输出是码�?字符(W,C)对，每次输出一对到码字��中�Q��ƈ用字�W�C扩展与码字W相对应的�~�-
�W�串(String)�Q�生成新的缀-�W�串(String)�Q�然后添加到词典中�?br />LZ78�~�码的具体算法如下：
步骤1�Q?在开始时�Q�词典和当前前缀P都是�I�的�?br />步骤2�Q?当前字符C �Q? 字符��中的下一个字�W��?br />步骤3�Q?判断P+C是否在词�怸��Q?br />(1) 如果“是”：用C扩展P�Q�让P �Q? P+C �Q?br />(2) 如果“否”：
�?输出与当前前�~�P相对应的码字和当前字�W�C�Q?br />�?把字�W�串P+C ��d��到词�怸��?br />�?令P �Q? �I�倹{�?br />(3) 判断字符��中是否�q�有字符需要编�?br />�?如果“是”：�q�回到步�?�?br />�?如果“否”：若当前前�~�P不是�I�的�Q�输出相应于当前前缀P的码字，然后�l�束�~�码�?br />2. 译码��法
在译码开始时译码词典是空的，它将在译码过�E�中从码字流中重构。每当从码字��中��d��一对码�?字符
(W,C)�Ҏ��Q�码字就参考已�l�在词典中的�~�-�W�串�Q�然后把当前码字的缀-�W�串string.W 和字�W�C输出到字�W�流
(Charstream)�Q�而把当前�~�-�W�串(string.W+C)��d��到词�怸�。在译码�l�束之后�Q�重构的词典与编码时生成�?br />词典完全相同�?br />LZ78译码的具体算法如下：
步骤1�Q?在开始时词典是空的�?br />步骤2�Q?当前码字W �Q? 码字��中的下一个码字�?br />步骤3�Q?当前字符C �Q? 紧随码字之后的字�W��?br />步骤4�Q?把当前码字的�~�-�W�串(string.W)输出到字�W�流(Charstream)�Q�然后输出字�W�C�?br />步骤5�Q?把string.W+C��d��到词�怸��?br />步骤6�Q?判断码字��中是否�q�有码字要译
�W?14 ��?br />4
(1) 如果“是”，��p��回到步骤2�?br />(2) 如果“否”，则结束�?br />[�?.6] �~�码字符串如�?-13所�C�，�~�码�q�程如表4-14所�C�。现说明如下�Q?br />(1) “步骤”栏表示�~�码步骤�?br />(2) “位�|�”栏表示在输入数据中的当前位�|��?br />(3) “词典”栏表示��d��到词�怸�的缀-�W�串�Q�缀-�W�串的烦引等于“步骤”序受��?br />(4) “输出”栏�?当前码字W, 当前字符C)��化�ؓ(W, C)的�Ş式输出�?br />�?-13 �~�码字符�?br />�?-14 �~�码�q�程
与LZ77相比�Q�LZ78的最大优�Ҏ��在每个编码步骤中减少了缀-�W�串(String)比较的数目，而压�~�率与LZ77
�c�M��?br />4.4.5 LZW��法
在LZW��法中��用的术语与LZ78使用的相同，仅增加了一个术语—前�~��?Root)�Q�它是由单个字符�l�成�?br />�~�-�W�串(String)。在�~�码原理上，LZW与LZ78相比有如下差别：
�?LZW只输��Z��表词�怸�的缀-�W�串(String)的码�?code word)。这��意呛_��开始时词典不能是空的，�?br />必须包含可能在字�W�流出现中的所有单个字�W�，卛_��~��?Root)�?br />�?�׃��所有可能出现的单个字符都事先包含在词典中，每次�~�码开始时都��用一个字�W�前�~�(onecharacter
prefix)�Q�因此在词典中增加的�W?个缀-�W�串有两个字�W��?br />现将LZW�~�码��法和译码算法介�l�如下�?br />1. �~�码��法
LZW�~�码是围�l�称��典的转换表来完成的。这张�{换表存放�U�Cؓ前缀(Prefix)的字�W�序列，�q��ؓ每个�?br />��分配一个码�?Code word)�Q�或者叫做序��P��如表4-15所�C�。这张�{换表实际上是�?位ASCII字符集进行扩
充，增加的符��L��来表�C�在文本或图像中出现的可变长度ASCII字符丌Ӏ�扩充后的代码可�?位�?0位�?1位�?br />12位甚��x��多的位来表示。Welch的论文中用了12位，12位可以有4096个不同的12位代码，�q�就是说�Q��{换表
�?096个表��，其中256个表��用来存攑ַ�定义的字�W�，剩下3840个表��用来存攑։��~�(Prefix)�?br />�?-15 词典
位置 1 2 3 4 5 6 7 8 9
字符 A B B C B C A B A
步骤位置词典输出
1 1 A (0,A)
2 2 B (0,B)
3 3 B C (2,C)
4 5 B C A (3,A)
5 8 B A (2,A)
码字(Code word) 前缀(Prefix)
1
�W?15 ��?br />4
LZW�~�码�?软�g�~�码器或��g�~�码�?��是通过��理�q�个词典完成输入与输��Z��间的转换。LZW�~�码器的�?br />入是字符��?Charstream)�Q�字�W�流可以是用8位ASCII字符�l�成的字�W�串�Q�而输出是用n�?例如12�?表示的码
字流(Codestream)�Q�码字代表单个字�W�或多个字符�l�成的字�W�串�?br />LZW�~�码器��用了一�U�很实用的分�?parsing)��法�Q�称��婪分析算�?greedy parsing algorithm)。在
贪婪分析��法中，每一�ơ分析都要串行地��查来自字�W�流(Charstream)的字�W�串�Q�从中分解出已经识别的最�?br />的字�W�串�Q�也��是已经在词�怸�出现的最长的前缀(Prefix)。用已知的前�~�(Prefix)加上下一个输入字�W�C�?br />��是当前字符(Current character)作�ؓ该前�~�的扩展字�W�，形成新的扩展字符东y��—缀-�W�串(String)�Q?br />Prefix+C。这个新的缀-�W�串(String)是否要加到词�怸��Q�还要看词典中是否存有和它相同的�~�-�W�串String�?br />如果有，那么�q�个�~�-�W�串(String)��变成前�~�(Prefix)�Q��l�输入新的字�W�，否则��把�q�个�~�-�W�串(String)
写到词典中生成一个新的前�~�(Prefix)�Q��ƈ分配�l�一个代码�?br />LZW�~�码��法的具体执行步骤如下：
步骤1�Q?开始时的词典包含所有可能的�?Root)�Q�而当前前�~�P是空的；
步骤2�Q?当前字符(C) �Q?字符��中的下一个字�W�；
步骤3�Q?判断�~�-�W�串P+C是否在词�怸�
(1) 如果“是”：P �Q? P+C // (用C扩展P) �Q?br />(2) 如果“否�?br />�?把代表当前前�~�P的码字输出到码字��?
�?把缀-�W�串P+C��d��到词�?
�?令P �Q? C //(现在的P仅包含一个字�W�C);
步骤4�Q?判断码字��中是否�q�有码字要译
(1) 如果“是”，��p��回到步骤2�Q?br />(2) 如果“否�?br />�?把代表当前前�~�P的码字输出到码字��?
�?�l�束�?br />LZW�~�码��法可用伪码表示。开始时假设�~�码词典包含若干个已�l�定义的单个码字。例如，256个字�W�的�?br />字，用伪码可以表�C�成�Q?br />�?�?br />193 A
194 B
�?�?br />255
�?�?br />1305 abcdefxyF01234
�?�?br />Dictionary[j] �?all n single-character�Q?j�Q?, 2�Q?…，n
j �?n+1
Prefix �?read first Character in Charstream
while((C �?next Character)!=NULL)
�W?16 ��?br />4
2. 译码��法
LZW译码��法中还用到另外两个术语�Q?br />�?当前码字(Current code word)�Q�指当前正在处理的码字，用cW表示�Q�用string.cW表示当前�~�-�W�串�Q?br />�?先前码字(Previous code word)�Q�指先于当前码字的码字，用pW表示�Q�用string.pW表示先前�~�-�W?br />丌Ӏ?br />LZW译码��法开始时�Q�译码词�怸��~�码词典相同�Q�它包含所有可能的前缀�?roots)。LZW��法在译码过�E?br />中会��C��先前码字(pW)�Q�从码字��中��d��前码�?cW)之后输出当前�~�-�W�串string.cW�Q�然后把用string.cW�?br />�W�一个字�W�扩展的先前�~�-�W�串string.pW��d��到词�怸��?br />LZW译码��法的具体执行步骤如下：
步骤1�Q?在开始译码时词典包含所有可能的前缀�?Root)�?br />步骤2�Q?cW �Q? 码字��中的第一个码字�?br />步骤3�Q?输出当前�~�-�W�串string.cW到码字流�?br />步骤4�Q?先前码字pW �Q? 当前码字cW�?br />步骤5�Q?当前码字cW �Q? 码字��中的下一个码字�?br />步骤6�Q?判断当前�~�-�W�串string.cW是否在词�怸�
(1) 如果“是”，则：
�?把当前缀-�W�串string.cW输出到字�W�流�?br />�?把先前缀-�W�串string.pW + 当前前缀-�W�串string.cW的第一个字�W�C��d��到词典�?br />(2) 如果“否”，则：
�?输出先前�~�-�W�串string.pW + 先前�~�-�W�串string.pW的第一个字�W�到字符��，
�?把它��d��到词�怸��?br />步骤7�Q?判断码字��中是否�q�有码字要译
(1) 如果“是”，��p��回到步骤4�?br />(2) 如果“否�? �l�束�?br />LZW译码��法可用伪码表示如下�Q?br />Codestream �?cW for Prefix
Dictionary[j] �?all n single-character�Q?j�Q?, 2�Q?…，n
j �?n+1
cW �?first code from Codestream
Charstream �?Dictionary[cW]
pW �?cW
While((cW �?next Code word)!=NULL)
�W?17 ��?br />4
[�?.7] �~�码字符串如�?-16所�C�，�~�码�q�程如表4-17所�C�。现说明如下�Q?br />(1) “步骤”栏表示�~�码步骤�Q?br />(2) “位�|�”栏表示在输入数据中的当前位�|�；
(3) “词典”栏表示��d��到词�怸�的缀-�W�串�Q�它的烦引在括号中；
(4) “输出”栏表示码字输出�?br />�?-16 被编码的字符�?br />�?-17 LZW的编码过�E?br />�?-18解释了译码过�E�。每个译码步骤译码器��M��个码字，输出相应的缀-�W�串�Q��ƈ把它��d��到词�怸��?br />例如�Q�在步骤4中，先前码字(2)存储在先前码�?pW)中，当前码字(cW)�?4)�Q�当前缀-�W�串string.cW是输�?br />(“A B�?�Q�先前缀-�W�串string.pW ("B")是用当前�~�-�W�串string.cW ("A")的第一个字�W�，其结�?"B A")
��d��到词�怸��Q�它的烦引号�?6)
�?-18 LZW的译码过�E?br />LZW��法得到普遍采用�Q�它的速度比��用LZ77��法的速度快，因�ؓ它不需要执行那么多的缀-�W�串比较�?br />位置 1 2 3 4 5 6 7 8 9
字符 A B B A B A B A C
步骤位置词典输出
(1) A
(2) B
(3) C
1 1 (4) A B (1)
2 2 (5) B B (2)
3 3 (6) B A (2)
4 4 (7) A B A (4)
5 6 (8) A B A C (7)
6 -- -- -- (3)
步骤代码词典输出
(1) A
(2) B
(3) C
1 (1) -- -- A
2 (2) (4) A B B
3 (2) (5) B B B
4 (4) (6) B A A B
5 (7) (7) A B A A B A
6 (3) (8) A B A C C
�W?18 ��?br />4
作。对LZW��法�q�一步的改进是增加可变的码字长度�Q�以及在词典中删除老的�~�-�W�串。在GIF囑փ�格式和UNIX
的压�~�程序中已经采用了这些改�q�措施之后的LZW��法�?br />LZW��法取得了专利，专利权的所有者是��国的一个大型计��机公司—Unisys(优利�pȝ��公司)�Q�除了商�?br />软�g生��公司之外�Q�可以免费��用LZW��法�?/font>

swo 2006-08-21 14:20 发表评论

gzip

swo — Mon, 21 Aug 2006 03:18:00 GMT

�Q�注�Q�以下关于技术细节的描述是以 gzip 的公开源代码�ؓ基础的，如果需要完整的代码�Q�可以在 gzip 的官方网�?www.gzip.org下蝲。下面提到的每一个问题，都首先介�l�最直观��单的解决�Ҏ��Q�然后指��U�方法的弊端所在，最后介�l?span lang="EN-US"> gzip 采用的做法，�q�样也许能��读者对 gzip 看似复杂、不直观的做法的意义有更好的理解。）
最直观的搜索方式是��序搜烦�Q�以待压�~�部分的�W�一个字节与�H�口中的每一个字节依�ơ比较，当找��C��个相�{�的字节�Ӟ��再比较后�l�的字节…�?遍历了窗口后得出最长匹配�?span lang="EN-US">gzip 用的是被�U�C��?/span>哈希�?span lang="EN-US">�?/span>的方法来实现较高效的搜烦�?span lang="EN-US">�?/span>哈希�Q?span lang="EN-US">hash�Q?span lang="EN-US">�?/span>是分散的意思，把待搜烦的数据按照字节值分散到一个个�?/span>�?span lang="EN-US">�?/span>中，搜烦时再�Ҏ��字节值到相应�?span lang="EN-US">�?/span>�?span lang="EN-US">�?/span>中去��L��。短语式压羃的最短匹配�ؓ 3 个字节，gzip �?span lang="EN-US"> 3 个字节的��g��为哈希表的烦引，�?span lang="EN-US"> 3 个字节共�?span lang="EN-US"> 2 �?span lang="EN-US"> 24 �ơ方�U�取��|��需�?span lang="EN-US"> 16M 个桶�Q�桶里存攄��是窗口中的位�|��|��H�口的大��ؓ 32K�Q�所以每个桶臛_��要有大于两个字节的空��_��哈希表将大于 32M�Q�作�?span lang="EN-US"> 90 �q�代开发的�E�序�Q�这个要求是太大了，而且随着�H�口的移动，哈希表里的数据会不断�q�时�Q�维护这么大的表�Q�会降低�E�序的效率，gzip 定义哈希表�ؓ 2 �?span lang="EN-US"> 15 �ơ方�Q?span lang="EN-US">32K�Q�个�Ӟ��q�设计了一个哈希函数把 16M �U�取值对应到 32K 个桶中，不同的��D��对应到相同的桶中是不可避免的�Q�哈希函数的��d��?span lang="EN-US">

1.使各�U�取值尽可能均匀地分布到各个桶中�Q�避免许多不同的值集中到某些桶中�Q�而另一些是�I�桶�Q��搜烦的效率降低�?/span>

2.函数的计��尽可能地简单，因�ؓ每次 �?/span>插入�?/span>�?span lang="EN-US">�?/span>搜寻�?/span>哈希表都要执行哈希函敎ͼ�哈希函数的复杂度直接影响�E�序的执行效率，�Ҏ��惛_��的哈希函数是�?span lang="EN-US"> 3 个字节的左边�Q�或双��Q?span lang="EN-US">15 位二�q�制��|��但这样只要左边（或右边）2 个字节相同，��׃��被放到同一个桶中，�?span lang="EN-US"> 2 个字节相同的概率是比较高的，不符�?span lang="EN-US">�?/span>�q�_��分布�?/span>的要求�?span lang="EN-US">

gzip 采用的算法是�Q?span lang="EN-US">A(4,5) + A(6,7,8) ^ B(1,2,3) + B(4,5) + B(6,7,8) ^ C(1,2,3) + C(4,5,6,7,8) �Q�说明：A �?span lang="EN-US"> 3 个字节中的第 1 个字节，B 指第 2 个字节，C 指第 3 个字节，A(4,5) 指第一个字节的�W?span lang="EN-US"> 4,5 位二�q�制码，“^�?/span>是二�q�制位的异或操作�Q?span lang="EN-US">�?�?/span>�?span lang="EN-US">�?/span>�q�接�?/span>而不�?span lang="EN-US">�?/span>�?span lang="EN-US">�?/span>�Q?span lang="EN-US">“^�?/span>优先�?span lang="EN-US">�?�?/span>�Q�这样�� 3 个字节都��量�?/span>参与�?/span>到最后的�l�果中来�Q�而且每个�l�果�?span lang="EN-US"> h 都等�?span lang="EN-US"> ((�?span lang="EN-US">1�?span lang="EN-US">h << 5) ^ c)取右 15 位，计算也还��单�?span lang="EN-US">
哈希表的具体实现也值得探讨,因�ؓ无法预先知道每一�?span lang="EN-US">�?/span>�?span lang="EN-US">�?/span>会存攑֤��个元素�Q�所以最��单的�Q�会惛_��用链表来实现�Q�哈希表里存攄��每个桶的�W�一�?元素�Q�每个元素除了存攄��自��n的��|��q�存攄��一个指针，指向同一个桶中的下一个元素，可以��着指针链来遍历该桶中的每一个元素，插入元素�Ӟ��先用哈希函数 ��出该放到第几个桶中�Q�再把它挂到相应链表的最后�?/span>

�q�个�Ҏ��的缺�Ҏ��频繁地申请和释放内存会降低运行速度�Q�内存指针的存放占据了额外的内存开销�?/span>

有更��内存开销和更快速的�Ҏ��来实现哈希表�Q��ƈ且不需要频�J�的内存甌��和释放：gzip 在内存中甌��了两个数�l�，一个叫 head[]�Q�一个叫 pre[]�Q�大��都�?span lang="EN-US"> 32K�Q�根据当前位�|?span lang="EN-US"> strstart 开始的 3 个字节，用哈希函数计��出�?span lang="EN-US"> head[] 中的位置 ins_h�Q�然后把 head[ins_h] 中的��D��?span lang="EN-US"> pre[strstart]�Q�再把当前位�|?span lang="EN-US"> strstart 记入 head[ins_h]�?/span>

随着压羃的进行，head[]里记载着最�q�的可能的匹配的位置�Q�如果有匚w��的话�Q?span lang="EN-US">head[ins_h]不�ؓ 0�Q�，pre[]中的所有位�|�与原始数据的位�|�相对应�Q�但每一个位�|�保存的值是前一个最�q�的可能的匹配的位置�?/span>

�Q?span lang="EN-US">�?/span>可能的匹�?span lang="EN-US">�?/span>是指哈希函数计算出的 ins_h 相同。）��着 pre[] 中的指示找下去，直到遇到 0�Q�可以得到所有匹配在原始数据中的位置�Q?span lang="EN-US">0 表示不再有更�q�的匚w��?span lang="EN-US">
　　接下来很自然地要观察 gzip 具体是如何判断哈希表中数据的�q�时�Q�如何清理哈希表的，因�ؓ pre[] 里只能存�?span lang="EN-US"> 32K 个元素，所以这��工作是必须要做的�?span lang="EN-US">
　　gzip 从原始文件中��d��两个�H�口大小的内容（�?span lang="EN-US"> 64K 字节�Q�到一块内存中�Q�这块内存也是一个数�l�，�U�C�� Window[]�Q�申�?span lang="EN-US"> head[]�?span lang="EN-US">pre[] �q�清�Ӟ��strstart �|��ؓ 0�?/span>

然后 gzip �Ҏ��索边插入�Q�搜索时通过计算 ins_h�Q�检�?span lang="EN-US"> head[] 中是否有匚w��Q�如果有匚w��Q�判�?span lang="EN-US"> strstart �?span lang="EN-US"> head[] 中的位置是否大于 1 个窗口的大小�Q�如果大�?span lang="EN-US"> 1 个窗口的大小�Q�就不到 pre[] 中去搜烦了，因�ؓ pre[] 中保存的位置更远了，如果不大于，��顺着 pre[] 的指�C�到 Window[] 中逐个匚w��位置开始，逐个字节与当前位�|�的数据比较�Q�以扑և�最长匹配，pre[] 中的位置也要判断是否��出一个窗口，如遇到超��Z��个窗口的位置或�?span lang="EN-US"> 0 ��׃��再找下去�Q�找不到匚w��p��出当前位�|�的单个字节到另外的内存�Q�输出方法在后文中会介绍�Q�，�q�把 strstart 插入哈希表，strstart 递增�Q�如果找��C��匚w��Q�就输出匚w��位置和匹配长度这两个数字到另外的内存中，�q�把 strstart 开始的�Q�直�?span lang="EN-US"> strstart + 匚w��长度为止的所有位�|�都插入哈希表，strstart += 匚w��长度。插入哈希表的方法�ؓ�Q?span lang="EN-US">
pre[strstart % 32K] = head[ins_h];
head[ins_h] = strstart;
�?以看出，pre[] 是��@环利用的�Q�所有的位置都在一个窗口以内，但每一个位�|�保存的��g��一定是一个窗口以内的�?/span>

在搜索时�Q?span lang="EN-US">head[] �?span lang="EN-US"> pre[] 中的位置值对应到 pre[] 时也�?span lang="EN-US"> % 32K。当 Window[] 中的原始数据��要处理完毕�Ӟ��要把 Window[] 中后一�H�的数据复制到前一�H�，再读�?span lang="EN-US"> 32K 字节的数据到后一�H�，strstart -= 32K�Q�遍�?span lang="EN-US"> head[]�Q�值小于等�?span lang="EN-US"> 32K 的，�|��ؓ 0�Q�大�?span lang="EN-US"> 32K 的，-= 32K�Q?span lang="EN-US">pre[] �?span lang="EN-US"> head[] 一样处理。然后同前面一样处理新一�H�的数据�?span lang="EN-US">
　　分析�Q�现在可�?看到�Q�虽�?span lang="EN-US"> 3 个字节有 16M �U�取��|��但实际上一个窗口只�?span lang="EN-US"> 32K 个取值需要插入哈希表�Q�由于短语式重复的存在，实际只有 < 32K �U�取值插入哈希表�?span lang="EN-US"> 32K �?span lang="EN-US">�?/span>�?span lang="EN-US">�?/span>中，而且哈希函数又符�?span lang="EN-US">�?/span>�q�_��分布�?/span>的要求，所以哈希表中实际存在的�?/span>冲突�?/span>一般不会多�Q�对搜烦效率的媄响不大。可以预计，�?span lang="EN-US">�?/span>一般情�?span lang="EN-US">�?/span>下，�?�?span lang="EN-US">�?/span>�?span lang="EN-US">�?/span>中存攄��数据�Q�正是我们要扄��?/span>

哈希表在各种搜烦��法中，实现相对的比较简单，�Ҏ��理解�Q?span lang="EN-US">�?/span>�q�_��搜烦速度�?/span>最快，哈希函数的设计是搜烦速度的关键，只要�W�合�?/span>�q�_��分布�?/span>�?span lang="EN-US">�?/span>计算��?span lang="EN-US">�?/span>�Q�就常常能成��U�搜索算法中的首选，所以哈希表是最��行的一�U�搜索算法�?/span>

但在某些�Ҏ��情况下，它也有缺点，�? 如：1.当键�?span lang="EN-US"> k 不存在时�Q�要求找出小�?span lang="EN-US"> k 的最大键码或大于 k 的最��键码，哈希表无法有效率地满��U�要求�?span lang="EN-US">2.哈希表的�?/span>�q�_��搜烦速度�?/span>是徏立在概率论的基础上的�Q�因��Z��先不能预知待搜烦的数据集合，我们只能�?/span>�?�?span lang="EN-US">�?/span>搜烦速度�?span lang="EN-US">�?/span>�q�_��?span lang="EN-US">�?/span>�Q�而不�?span lang="EN-US">�?/span>保证�?/span>搜烦速度�?span lang="EN-US">�?/span>上限�?/span>。在同�h�c�L��命攸关的应用中�Q�如�ȝ��或宇航领域）�Q�将是不合适的�?/span>

�q�些情况及其他一些特�D�情况下�Q�我们必��L��助其�?span lang="EN-US">�?/span>�q�_��速度�?/span>较低�Q�但能满��相应的�Ҏ��要求的算法。（见《计��机�E�序设计艺术》第3�?排序与查找）。幸�?span lang="EN-US">�?/span>在窗口中搜烦匚w��字节�?span lang="EN-US">�?/span>不属于特�D�情��c�?span lang="EN-US">

旉��与压�~�率的��^衡：
gzip 定义了几�U�可供选择�?span lang="EN-US"> level�Q�越低的 level 压羃旉��快但压�~�率��低�Q�越高的 level 压羃旉��慢但压�~�率��高�?span lang="EN-US">
不同�?span lang="EN-US"> level 对下面四个变量有不同的取��|��

nice_length
max_chain
max_lazy
good_length

nice_length�Q?前面说过�Q�搜索匹配时�Q�顺着 pre[] 的指�C�到 Window[] 中逐个匚w��位置开始，扑և�最长匹配，但在�q�过�E�中�Q�如果遇��C��个匹配的长度辑ֈ�或超�q?span lang="EN-US"> nice_length�Q�就不再试图��L��更长的匹配。最低的 level 定义 nice_length �?span lang="EN-US"> 8�Q�最高的 level 定义 nice_length �?span lang="EN-US"> 258�Q�即一个字节能表示的最大短语匹配长�?span lang="EN-US"> 3 + 255�Q��?span lang="EN-US">

max_chain�Q�这个��D��定了��着 pre[] 的指�C�往前回溯的最大次数。最低的 level 定义 max_chain �?span lang="EN-US"> 4�Q�最高的 level 定义 max_chain �?span lang="EN-US"> 4096。当 max_chain �?span lang="EN-US"> nice_length 有冲�H�时�Q�以先达到的为准�?/span>

swo 2006-08-21 11:18 发表评论

swo — Sat, 19 Aug 2006 06:54:00 GMT

gzip 使用deflate��法�q�行压羃。zlib�Q�以及图形格式png�Q��用的压羃��法也是deflate��法。从gzip的源码中�Q�我们了解到�? defalte��法的原理和实现。我阅读的gzip版本�? gzip-1.2.4。下面我们将要对deflate��法做一个分析和说明。首先简单介�l�一下基本原理，然后详细的介�l�实现�?br />
1 gzip 所使用压羃��法的基本原�?/b>

gzip 对于要压�~�的文�g�Q�首先��用LZ77��法的一个变�U�进行压�~�，对得到的�l�果再��用Huffman�~�码的方法（实际上gzip�Ҏ��情况�Q�选择使用静�? Huffman�~�码或者动态Huffman�~�码�Q�详�l�内容在实现中说明）�q�行压羃。所以明白了LZ77��法和Huffman�~�码的压�~�原理，也就明白�? gzip的压�~�原理。我们来对LZ77��法和Huffman�~�码做一个简单介�l��?br />
1.1 LZ77��法��?br />
�q�一��法是由Jacob Ziv �?Abraham Lempel �?1977 �q�提出，所以命名�ؓ LZ77�?br />
1.1.1 LZ77��法的压�~�原�?br />
�? 果文件中有两块内容相同的话，那么只要知道前一块的位置和大��，我们��可以确定后一块的内容。所以我们可以用�Q�两者之间的距离�Q�相同内容的长度�Q�这样一�? 信息�Q�来替换后一块内宏V��由于（两者之间的距离�Q�相同内容的长度�Q�这一对信息的大小�Q�小于被替换内容的大��，所以文件得��C��压羃�?br />
下面我们来�D一个例子�?br />
有一个文件的内容如下
http://jiurl.yeah.net http://jiurl.nease.net

其中有些部分的内容，前面已经出现�q�了�Q�下面用()括�v来的部分��是相同的部分�?br />http://jiurl.yeah.net (http://jiurl.)nease(.net)

我们使用 (两者之间的距离�Q�相同内容的长度) �q�样一对信息，来替换后一块内宏V�?br />http://jiurl.yeah.net (22,13)nease(23,4)

(22,13)中，22为相同内容块与当前位�|�之间的距离�Q?3为相同内容的长度�?br />(23,4)中，23为相同内容块与当前位�|�之间的距离�Q?为相同内容的长度�?br />�׃��Q�两者之间的距离�Q�相同内容的长度�Q�这一对信息的大小�Q�小于被替换内容的大��，所以文件得��C��压羃�?br />
1.1.2 LZ77使用滑动�H�口��L��匚w��?br />
LZ77��法使用"滑动�H�口"的方法，来寻找文件中的相同部分，也就是匹配串。我们先对这里的串做一个说明，它是指一个�Q意字节的序列�Q�而不仅仅是可以在文本文�g中显�C�出来的那些字节的序列。这里的串强调的是它在文件中的位�|�，它的长度随着匚w��的情况而变化�?br />
LZ77 从文件的开始处开始，一个字节一个字节的向后�q�行处理。一个固定大��的�H�口�Q�在当前处理字节之前�Q��ƈ且紧挨着当前处理字节�Q�，随着处理的字节不断的向后�? 动，��p��在阳光下�Q�飞机的影子滑过大地一栗��对于文件中的每个字节，用当前处理字节开始的�Ԍ��和窗口中的每个串�q�行匚w��Q�寻找最长的匚w��丌Ӏ�窗口中的每�? 串指�Q�窗口中每个字节开始的丌Ӏ�如果当前处理字节开始的串在�H�口中有匚w��Ԍ��q��(之间的距��，匚w��长度) �q�样一对信息，来替换当前串�Q�然后从刚才处理完的串之后的下一个字节，�l�箋处理。如果当前处理字节开始的串在�H�口中没有匹配串�Q�就不做改动的输出当前处�? 字节�?br />
处理文�g中第一个字节的时候，�H�口在当前处理字节之前，也就是还没有滑到文�g上，�q�时�H�口中没有�Q何内容，被处理的字节��׃��不做改动的输出。随着处理的不断向后，�H�口��来��多的滑入文�Ӟ��最后整个窗口滑入文�Ӟ��然后整个�H�口在文件上向后滑动�Q�直到整个文件结束�?br />
1.1.3 使用LZ77��法�q�行压羃和解压羃

�? 了在解压�~�时�Q�可以区分“没有匹配的字节”和“（之间的距��，匚w��长度�Q�对”，我们�q�需要在每个“没有匹配的字节”或者“（之间的距��，匚w��长度�Q�对”之前，放上一位，来指明是“没有匹配的字节”，�q�是“（之间的距��，匚w��长度�Q�对”。我们用0表示“没有匹配的字节”，�?表示“（之间的距��，匚w��长度�Q? 对”�?br />
实际中，我们��固定（之间的距��，匚w��长度�Q�对中的�Q�“之间的距离”和“匹配长度”所使用的位数。由于我们要固定“之间的距离”所使用的位敎ͼ�所以我们才使用了固定大��的�H�口�Q�比如窗口的大小�?2KB�Q�那么用15位（2^15=32K�Q�就可以保存0-32K范围的�Q何一个倹{��实�? 中，我们�q�将限定最大的匚w��长度�Q�这样一来，“匹配长度”所使用的位��C��固定了�?br />
实际中，我们�q�将讑֮�一个最��匹配长度，只有当两个串的匹配长度大于最��匹配长度时�Q�我们才认�ؓ是一个匹配。我们�D一个例子来说明�q�样做的原因。比如，“距��Z��?5位，“长度”��?位，那么“（之间�? 距离�Q�匹配长度）对”将使用23位，也就是差1�?个字节。如果匹配长度小�?个字节的话，那么用“（之间的距��，匚w��长度�Q�对”进行替换的话，不但没有压羃�Q�反而会增大�Q�所以需要一个最��匹配长度�?br />
压羃�Q?br />
从文件的开始到文�g�l�束�Q�一个字节一个字节的向后�q�行处理。用当前处理字节开始的�Ԍ��和滑动窗口中的每个串�q�行匚w��Q�寻找最长的匚w��丌Ӏ�如果当前处理字节开始的串在�H�口中有匚w��Ԍ��先输出一个标志位�Q�表明下面是一�? (之间的距��，匚w��长度) 对，然后输出(之间的距��，匚w��长度) 对，然后从刚才处理完的串之后的下一个字节，�l�箋处理。如果当前处理字节开始的串在�H�口中没有匹配串�Q�就先输��Z��个标志位�Q�表明下面是一个没有改动的�? 节，然后不做改动的输出当前处理字节，然后�l�箋处理当前处理字节的下一个字节�?br />
解压�~�：

从文件开始到文�g�l�束�Q�每�ơ先�? 一位标志位�Q�通过�q�个标志位来判断下面是一�?之间的距��，匚w��长度) 对，�q�是一个没有改动的字节。如果是一个（之间的距��，匚w��长度�Q�对�Q�就��d��固定位数的（之间的距��，匚w��长度�Q�对�Q�然后根据对中的信息�Q�将匚w��串输出到当前位置。如果是一个没有改动的字节�Q�就��d��一个字节，然后输出�q�个字节�?br />
我们可以看到�Q�LZ77压羃旉��要做大量的匹配工作，而解压羃旉��要做的工作很��，也就是说解压�~�相对于压羃��快的多。这对于需要进行一�ơ压�~�，多次解压�~�的情况�Q�是一个巨大的优点�?br />

1.2 Huffman�~�码��?br />
1.2.1 Huffman�~�码的压�~�原�?br />
�? 们把文�g中一定位长的值看作是�W�号�Q�比如把8位长�?56�U��|��也就是字节的256�U�值看作是�W�号。我们根据这些符号在文�g中出现的频率�Q�对�q�些�W�号重新 �~�码。对于出现次数非常多的，我们用较��的位来表示�Q�对于出现次数非常少的，我们用较多的位来表示。这样一来，文�g的一些部分位数变��了�Q�一些部分位数变多了�Q�由于变��的部分比变大的部分多，所以整个文件的大小�q�是会减��，所以文件得��C��压羃�?br />
1.2.2 Huffman�~�码使用Huffman树来产生�~�码

�? �q�行Huffman�~�码�Q�首先要把整个文件读一遍，在读的过�E�中�Q�统计每个符��P��我们把字节的256�U�值看作是256�U�符��P��的出现次数。然后根据符��L�� 出现�ơ数�Q�徏立Huffman树，通过Huffman树得到每个符��L��新的�~�码。对于文件中出现�ơ数较多的符��P��它的Huffman�~�码的位数比较少。对于文件中出现�ơ数较少的符��P��它的Huffman�~�码的位数比较多。然后把文�g中的每个字节替换成他们新的编码�?br />
建立Huffman树：

把所有符��L��成是一个结点，�q�且该结点的��gؓ它的出现�ơ数。进一步把�q�些�l�点看成是只有一个结点的树�?br />
每次从所有树中找出值最��的两个树，��两个树徏立一个父�l�点�Q�然后这两个树和它们的父�l�点�l�成一个新的树�Q�这个新的树的��gؓ它的两个子树的值的和。如此往复，直到最后所有的树变成了一��|��。我们就得到了一��Huffman树�?br />
通过Huffman树得到Huffman�~�码�Q?br />
�q�棵Huffman树，是一��二叉树�Q�它的所有叶子结点就是所有的�W�号�Q�它的中间结�Ҏ��在��生Huffman树的�q�程中不断徏立的�?br />
我们在Huffman树的所有父�l�点到它的左子结点的路径上标�?�Q�右子结点的路径上标�?�?br />
现在我们从根节点开始，到所有叶子结点的路径�Q�就是一�?�?的序列。我们用根结点到一个叶子结点�\径上�?�?的序列，作�ؓ�q�个叶子�l�点的Huffman�~�码�?br />

我们来看一个例子�?br />
有一个文件的内容如下
abbbbccccddde

我们�l�计一下各个符��L��出现�ơ数�Q?br />
a b c d e
1 4 4 3 1

建立Huffman树的�q�程如下图所�C?

通过最�l�的Huffman树，我们可以得到每个�W�号的Huffman�~�码�?br />
a �?110
b �?00
c �?01
d �?10
e �?111

我们可以看到�Q�Huffman树的建立�Ҏ��׃��证了�Q�出现次数多的符��P��得到的Huffman�~�码位数��，出现�ơ数��的�W�号�Q�得到的Huffman�~�码位数多�?br />
各个�W�号的Huffman�~�码的长度不一�Q�也��是变长�~�码。对于变长编码，可能会遇��C��个问题，��是重新�~�码的文件中可能会无法如区分�q�些�~�码�?br />比如�Q�a的编码�ؓ000�Q�b的编码�ؓ0001�Q�c的编码�ؓ1�Q�那么当遇到0001�Ӟ��׃��知道0001代表ac�Q�还是代表b。出现这�U�问题的原因是a的编码是b的编码的前缀�?br />�׃��Huffman�~�码为根�l�点到叶子结点�\径上�?�?的序列，而一个叶子结点的路径不可能是另一个叶子结点�\径的前缀�Q�所以一个Huffman�~�码不可能�ؓ另一个Huffman�~�码的前�~��Q�这��׃��证了Huffman�~�码是可以区分的�?br />
1.2.3 使用Huffman�~�码�q�行压羃和解压羃

��Z��在解压羃的时候，得到压羃时所使用的Huffman树，我们需要在压羃文�g中，保存树的信息�Q�也��是保存每个�W�号的出现次数的信息�?br />
压羃�Q?br />
��L��Ӟ��l�计每个�W�号的出现次数。根据每个符��L��出现�ơ数�Q�徏立Huffman树，得到每个�W�号的Huffman�~�码。将每个�W�号的出现次数的信息保存在压�~�文件中�Q�将文�g中的每个�W�号替换成它的Huffman�~�码�Q��ƈ输出�?br />
解压�~�：

得到保存在压�~�文件中的，每个�W�号的出现次数的信息。根据每个符��L��出现�ơ数�Q�徏立Huffman树，得到每个�W�号的Huffman�~�码。将压羃文�g中的每个Huffman�~�码替换成它对应的符��P��q�输出�?br />
2 gzip 所使用压羃��法的实�?/b>

我们��gzip的实现分成很多个部分�Q�一个个来说明，�q�样做的原因见本文最后一部分�?br />gzip 中所使用的各�U�实现技巧的出处或者灵感，gzip 的作者在源码的注释中�q�行了说明�?br />
2.1 ��L��匚w��串的实现

��Z��个串��L��匚w��串需要进行大量的匚w��工作�Q�而且我们�q�需要�ؓ很多很多个串��L��匚w��丌Ӏ�所�?gzip 在寻扑֌�配串的实��C��使用哈希表来提高速度�?br />
要达到的目标是，对于当前�Ԍ��我们要在它之前的�H�口中，��L��每一个匹配长度达到最��匹配的�Ԍ��q�找出匹配长度最长的丌Ӏ?br />
�?gzip 中，最��匹配长度�ؓ3�Q�也��是��_��两个�Ԍ��最��要�?个字节相同，才能��作匚w��。�ؓ什么最��匹配长度�ؓ3�Q�将在后面说明�?br />
gzip 寚w��到的每一个串�Q�首先会把它插入��C��个“字典”中。这样当以后有和它匹配的�Ԍ��可以直接从“字典”中查出�q�个丌Ӏ?br />
�? 入不是�ؕ插，查也不是乱查。插入的时候，使用�q�个插入串的前三个字节，计算出插入的“字典”位�|�，然后把插入串的开始位�|�保存在�q�个“字典”位�|�中。查�? 的时候，使用查出串的前三个字节，计算出“字典”位�|�，�׃��插入和查��Z��用的是同一�U�计��方法，所以如果两个串的前三个字节相同的话�Q�计��出的“字典”位 �|�肯定是相同的，所以就可以直接在该“字典”位�|�中�Q�取��Z��前插入时�Q�保存进�ȝ��那个串的开始位�|�。于是查��Z��Q�就扑ֈ�了一个串�Q�而这个串的前三个字节�? 自己的一��P��其实只是有极大的可能是一��L��Q�原因后面说明）�Q�所以就扑ֈ�了一个匹配串�?br />
如果有多个串�Q�他们的前三个字节都相同�Q�那么他们的“字典”位�|�，也都是相同的�Q�他们将被链成一条链�Q�放在那个“字典”位�|�上。所以，如果一个串�Q�查��C��一个“字典”位�|�，也就查到了一个链�Q�所有和它前三个字节相同的串�Q�都在这个链上�?br />
�? ��是��_��当前串之前的所有匹配串被链在了一个链上，攑֜�某个“字典”位�|�上。而当前串使用它的前三个字节，�q�行某种计算�Q�就可以得到�q�个“字典”位�|�（�? ��C��“字典”位�|�之后，它首先也把自己链入到�q�个链上�Q�，也就扑ֈ�了链有它的所有匹配串的链�Q�所以要找最长的匚w��Q�也��是遍历�q�个链上的每一个串�Q�看和哪个串的匹配长度最大�?br />
下面我们更具体的说明�Q�寻扑֌�配串的实现�?br />
我们前面所说的“字典”，是一个数�l�，叫做head[]�Q��ؓ什么叫head,后面�q�行说明�Q��?br />我们前面所说的“字典”位�|�，攑֜�一个叫做ins_h的变量中�?br />我们前面所说的链，是在一个叫做prev[]的数�l�中�?br />
插入�Q?br />
当前字节为第 strstart 个字节。通过�W�strstart,strstart+1,strstart+2,�q�三个字节，使用一个设计好的哈希函数算出ins_h�Q�也��是插入的位�|�。然后将当前字节的位�|�，即strstart�Q�保存在head[ins_h]中�?br />注意�?strstart,strstart+1,strstart+2,�q�三个字节（也就是strstart开始处的串的头三个字节�Q�也��是当前字节和之后的两个字节�Q�确定了ins_h。head[ins_h]中保存的又是strstart�Q�也��是�q�个串开始的位置�?br />
判断是否有匹配：

�? 前串的前三个字节�Q��用哈希函数算出ins_h�Q�这时如果head[ins_h]的��g��为空的话�Q�那么head[ins_h]中的��|��便是之前保存在这�? 的另一个串的位�|�，�q�且�q�个串的前三个字节算出的ins_h�Q�和当前串的前三个字节算出的ins_h相同。也��是说有可能有匹配。如果head [ins_h]的��gؓ�I�的话，那么肯定没有匚w��?br />
gzip所使用的哈希函敎ͼ�

gzip 所使用的哈希函敎ͼ�用三个字节来计算一个ins_h�Q�这是由于最��匹配�ؓ三个字节�?br />
对于相同的三个字节，通过哈希函数得到的ins_h必然是相同的�?br />而不同的三个字节�Q�通过哈希函数有可能得到同一个ins_h�Q�不�q�这�q�不要紧�Q?br />当gzip发现head[ins_h]不空后，也就是说有可能有匚w��串的话，会对链上的每一个串�q�行真正的串的比较�?br />
所以一个链上的�Ԍ��只是前三个字节用哈希函数��出的值相同，而�ƈ不一定前三个字节都是相同的。但是这样已�l�很大的�~�小了需要进行串比较的范围�?br />
我们来强调一下，前三个字节相同的�Ԍ��必然在同一个链上。在同一个链上的�Q�不一定前三个字节都相同�?br />
�? 同的三个字节有可能得到同一个结果的原因是，三个字节�Q�一�?4位，�?^24�U�可能倹{��而三个字节的哈希函数的计��结果�ؓ15位，�?^15�U�可能倹{�? 也就是说2^24�U��|��?^15�U��D��行对应，必然是多对一的，也就是说�Q�必然是有多�U�三个字节的��|��用这个哈希函数计��出的值都是相同的�?br />
而我们��用哈希函数的理由是，实际上，我们只是在一个窗口大��的范围内（后面��会看到�Q�寻扑֌�配串�Q�一个窗口的大小范围是很有限的，能出现的三个字节的值组合情况也是很有限的，��远�q�小�?^24�Q��用合适的哈希函数是高效的�?br />
前三个字节相同的所有的串所在的链：

head[ins_h] 中的��|��有两个作用。一个作用，是一个前三个字节计算�l�果为ins_h的串的位�|�。另一个作用，是一个在prev[]数组中的索引�Q�用�q�个索引在prev []中，��找到前一个前三个字节计算�l�果为ins_h的串的位�|�。即prev[head[ins_h]]的��|��不�ؓ�I�的话）为前一个前三个字节计算�l�果�? ins_h的串的位�|��?br />
prev[]的��|��也有两个作用。一个作用，是一个前三个字节计算�l�果为ins_h的串的位�|�。另一个作用，是一个在prev[]数组中的索引�Q�用�q�个索引在prev[]中，��找到前一个前三个字节计算�l�果为ins_h的串的位子哈。即prev[]的��|��不�ؓ�I�的话）为前一个三个字节计��结果�ؓins_h的串的位�|��?br />
直到prev[]为空�Q�表�C�链�l�束�?br />
我们来�D一个例子，�Ԍ��
0abcd abce,abcf_abcg

当处理到abcg的a�Ӟ��由abcg的abc��出ins_h�?br />�q�时的head[ins_h]中�ؓ 11�Q�即�?abcf abcg"的开始位�|��?br />�q�时的prev[11]中�ؓ 6�Q�即�?abce abcf abcg"的开始位�|��?br />�q�时的prev[6]中�ؓ 1�Q�即�?abcd abce abcf abcg"的开始位�|��?br />�q�时的prev[1]中�ؓ 0。表�C�链�l�束了�?br />
我们看到所有头三个字母为abc的串�Q�被铑֜�了一��P��从head可以一直找下去�Q�直到找�?�?br />
铄��建立�Q?br />
gzip 在每�ơ处理当前串的时候，首先用当前串的前三个字节计算出ins_h�Q�然后，��p��把当前的串也插入到相应的链中�Q�也��是把当前的串的位置�Q�保存到 head[ins_h] 中，而此�Ӟ��head[ins_h] 中（不空的话�Q��ؓ前一个串的开始位�|�。所以这时候需要把前一个串的位�|�，也就是原来的head[ins_h]攑օ�链中。于是把现在的head [ins_h]的��|��用当前串的位�|�做索引�Q�保存到 prev[] 中。然后再�?head[ins_h] 赋��gؓ当前串的位置�?br />
如果当前串的位置为strstart的话�Q�那么也��是
prev[strstart] = head[ins_h];
head[ins_h] = strstart;

��p��P��每次把一个串的位�|�加入到链中�Q�链��Ş成了�?br />
现在我们也就知道了，前三个字节计��得到同一ins_h的所有的串被铑֜�了一��P��head[ins_h]为链��_��prev[]数组中放着的更早的串的位置。head数组和prev数组的名字，也正反应了他们的作用�?br />
铄��特点�Q?br />
��向前（prev�Q�与当前处理位置之间的距��越大。比如，当前处理�Ԍ��出了ins_h�Q�而且head[ins_h]中的��g��I�，那么head[ins_h]��是��d��前处理串距离最�q�的一个可能的匚w��Ԍ��q�且��着prev[]向前所扑ֈ�的串�Q�越来距��越�q��?br />
匚w��串中的字节开始的串的插入�Q?br />
我们说过了，所有字节开始的�Ԍ��都将被插入“字典”。对于确定了的匹配串�Q�匹配串中的每个字节开始的�Ԍ��仍要被插入“字典”，以便后面串可以和他们�q�行匚w��?br />
注意�Q?br />
�? 于文件中的第0字节�Q�情况很�Ҏ��Q�它开始的串的位置�?。所以第0串的前三个字节计��出ins_h之后�Q�在head[ins_h]中保存的位置�?。而对是否有可能有匚w��的判断，��是通过head[ins_h]不�ؓ0�Q��ƈ且head[ins_h]的��gؓ一个串的开始位�|�。所以第0字节开始的�Ԍ��׃��其特�D? 性，��不会被用来匚w��Q�不�q�这�U�情况只会出现在�W?个字节，所以通常不会造成影响�Q�即使媄响，也会极小�?br />
例如�Q�文件内容�ؓ

jiurl jiurl

扑ֈ�的匹配情况如下，[]所括部分�?br />
jiurl j[iurl]

2.2 懒惰啊匹配（lazy match�Q?br />
�? 于当前字节开始的�Ԍ��L��C��最长匹配之后，gzip�q�不立即军_��使用�q�个串进行替换。而是看看�q�个匚w��长度是否满意�Q�如果匹配长度不满意�Q�而下一个字�? 开始的串也有匹配串的话�Q�那么gzip��找��C��一个字节开始的串的最长匹配，看看是不是比现在�q�个�ѝ��这叫懒惰啊匚w��。如果比现在�q�个长的话，��不使用�? 在的�q�个匚w��。如果比现在�q�个短的话，��确定��用现在的�q�个匚w��?br />
我们来�D个例子，�?br />
0abc bcde abcde

处理到第10字节�Ӟ��也就�?abcde"的a�Ӟ��扑ֈ�最长匹配的情况如下�Q�[]所括部分�?br />
0abc bcde [abc]de

�q�时�Q�再看看下一个字节，也就是第11字节的情况，也就�?abcde"的b�Q�找到最长匹配的情况如下�Q�[]所括部分�?br />
0abc bcde a[bcde]

发现�W�二�ơ匹配的匚w��长度大，��׃��使用�W�一�ơ的匚w��丌Ӏ�我们也看到了如果��用第一�ơ匹配的话，��错�q�更长的匚w��丌Ӏ?br />
在满��x��惰啊匚w��的前提条件下�Q�懒惰啊匚w��不限制次敎ͼ�一�ơ懒惰啊匚w��发现了更长的匚w��串之后，仍会再进行懒惰啊匚w��Q�如果这�ơ懒匚w��Q�发��C��更长的匹配串�Q�那么上一�ơ的懒匹配找到的匚w��串就不用了�?br />
�q? 行懒惰啊匚w��是有条�g的。进行懒惰啊匚w��必须满��两个条�g�Q�第一�Q�下一个处理字节开始的�Ԍ��要有匚w��Ԍ��如果下一个处理字节开始的串没有匹配串的话�Q�那�? ��q��定��用当前的匚w��Ԍ��不进行懒匚w��。第二，当前匚w��串的匚w��长度�Q�gzip不满意，也就是当前匹配长度小于max_lazy_match �Q�max_lazy_match在固定的压羃�U�别下，有固定的��|��?br />
讨论�Q?br />
我们可以看到了做另外一�ơ尝试的原因。如果当前串有匹配就使用了的话，可能错过更长匚w��的机会。��用懒惰啊匚w��会有所改善�?br />不过从我��单的分析来看�Q��用懒惰啊匚w��对压�~�率的改善似乎是非常有限的�?br />
2.3 大于64KB的文�Ӟ��H�口的实�?br />
�H�口的实玎ͼ�

实际中，当前�Ԍ��当前处理字节开始的�Ԍ��只是在它之前的窗口中��L��匚w��串的�Q�也��是说只是在它之前的一定大��的范围内寻扑֌�配串的。有�q�个限制的原因，��在后面说明�?br />
gzip 的窗口大��ؓ WSIZE�Q?2KB�?br />
内存中有一个叫window[]的缓冲区�Q�大��ؓ2个窗口的大小�Q�也��是64KB。文件的内容��被��d��q�个window[]中，我们在window[]上进行LZ77部分的处理，得到�l�果��放在其他缓冲区中�?br />
gzip 对window[]中的内容�Q�从开始处开始，一个字节一个字节的向后处理。有一个指针叫strstart�Q�其实是个烦引）�Q�指向当前处理字节，当当前处�? 字节开始的串没有匹配时�Q�不做改动的输出当前处理字节�Q�strstart向后�U�d��一个字节。当当前处理字节开始的串找��C��匚w��Ӟ��输出�Q�匹配长度，盔R��? ��）对，strstart向后�U�d��匚w��长度个字节。我们把strstart到window[]�l�束的这部分内容�Q�叫�?lookahead buffer�Q�超前查看缓冲区。这样叫的原因是�Q�在我们处理当前字节的时候，��需要读��Z��后的字节来进行串的匹配。在一个变量lookahead中，保存着��前查看�~�冲区所剩的字节数。lookahead�Q�最开始被初始化�ؓ整个��d��内容的大��，随着处理的进行，strstart不断后移�Q�超前查看缓冲区�? 断减��，lookahead的��g��不断的减��?br />
我们需要限制查扑֌�配串的范围�ؓ一个窗口的大小�Q�这么做的原因后面说明）�Q�也��是��_��只能在当前处理字节之前的32KB的范围内��L��匚w��丌Ӏ�而，�׃��处理是在2个窗口大��，也就�?4KB大小的缓冲区中进行的�Q�所以匹配链上的串与当前串之间的距离是很有可能超�q?2KB的。那么gzip是如何来实现�q�个限制的呢�Q?br />
gzip 通过匚w��时的判断条�g来实现这个限制。当当前串计��ins_h�Q�发现head[ins_h]��g��为空�Ӟ��head[ins_h]��Z��个串的开始位�|�）�Q�说明当前串有可能有匚w��Ԍ��把这个��g��存在 hash_head中。这时就要做一个限制范围的判断�Q�strstart - hash_head <= �H�口大小�Q�strstart-hash_head 是当前串和最�q�的匚w��串之间的距离�Q�（注意前面说过�Q�链头和当前串的距离最�q�，��向前（prev�Q�与当前处理位置之间的距��越大）�Q�也��是说要判断当前�? 和距��L��q�的匚w��串之间的距离是否在一个窗口的范围之内。如果不是的话，那么链上的其他串肯定更远�Q�肯定更不在一个窗口的范围之内�Q�就不进行匹配处理了�? 如果是在一个窗口的范围之内的话�Q�还需要在链上��L��最长的匚w��Ԍ��在和每个串进行比较的时候，也需要判断当前串和该串的距离是否��过一个窗口的范围�Q�超�q? 的话�Q�就不能�q�行匚w��?br />
实际中，gzip��Z��使代码简单点�Q�距��限制要比一个窗口的大小�q�要��一炏V�?br />
��于64KB的文�Ӟ��

初始化的时候，会首先从文�g中读64KB的内容到window[]中�?br />
对于��于64KB的文�Ӟ��整个文�g都被��d��到window[]中。在window[]上进行LZ77的处理，从开始直到文件结束�?br />
大于64KB的文�Ӟ��

�? 处理一个字节都要判�?lookahead < MIN_LOOKAHEAD �Q�也��是window中还没有处理的字节是否还够MIN_LOOKAHEAD �Q�如果不够的话，��׃��D�� fill_window()�Q�从文�g中读内容到window[]中。由于我们一�ơ最大可能��用的��前查看�~�冲区的大小为，最大匹配长度（258个字节，�? 面进行说明）加上最��匹配长度，也就是下一个处理字节开始的�Ԍ��可以扑ֈ�一个最大匹配长度的匚w��Q�发生匹配之后，�q�要预读一个最��匹配长度来计算之后�? ins_h�?br />
不管是大�?4KB的文�Ӟ��q�是��于64KB的文�Ӟ��随着处理的进行，最�l�都要到文�g的结束，在接�q�文件结束的时候，都会�? �?lookahead < MIN_LOOKAHEAD �Q�对于这�U�情况，fill_window() ��L��Ӟ��再��M��出文件内容了�Q�于是fill_window()会设�|�一个标志eofile�Q�表�C�文件就要结束了�Q�之后肯定会接着遇到 lookahead < MIN_LOOKAHEAD �Q�不�q�由于设�|�了 eofile 标志�Q�就不会再去试图��L��件到window[]中了�?br />
压羃开始之前的初始化，会从文�g中读�?4KB的内容到window[]中，�H�口大小�?2KB�Q�也��是��d��2�H�的内容到window[]中。我们把�W�一�H�的内容叫做w1_32k�Q�第二窗的内容叫做w2_32k�?br />
�? �~�不断进行，直到 lookahead < MIN_LOOKAHEAD�Q�也��是处理��C��64KB内容的接�q�结束部分，也就是如果再处理�Q�超前查看缓冲区中的内容��可能不够了。由�? lookahead < MIN_LOOKAHEAD �Q�将执行 fill_window()�?br />
fill_window() 判断是否压羃已经�q�行��C��2�H�内容快用完了，该把新的内容放进来了。如果是的话�Q?br />
fill_window() 把第二窗的内�?w2_32k�Q�复制到�W�一�H�中�Q�第一�H�中的内容就被覆盖掉了，然后对match_start,strstart之类的烦引，做修正�?br />然后更新匚w��铄��铑֤�数组�Q�head[]�Q�从头到��过一遍，如果�q�个头中保存的串的位�|�，在w2_32k中，��对�q�个串的位置做修正�?br />如果�q�个头中保存的串的位�|�，在w1_32k中，��׃��要了�Q�设为空�Q�因为第一�H�的内容我们已经覆盖掉了�?br />然后更新prev[]数组�Q�从头到��过一遍，如果某项的内容，在w2_32k中，��做修正。如果这��的内容�Q�在w1_32k中，��׃��要了�Q�设为空�Q�因为第一�H�的内容我们已经覆盖掉了�?br />
最后fill_window()从文件中再读��Z��H�内容，也就是读�?2KB的内容，复制到第二个�H�中�Q�注意第二个�H�口中原来的内容�Q�已�l�被复制��C��W�一个窗口中�?br />
��p��P��一�H�窗的处理，直到整个文�g�l�束�?br />
分析�Q?br />
�? �W�二�H�文件内容也快要处理完的时候，才会从文件中��d��新的内容。而这�Ӟ��W�一�H�中的所有串�Q�对于当前处理字节和之后的字节来��_��已经��出了一个窗口的�? ��，当前处理字节和之后的字节不能和第一�H�的串进行匹配了�Q�也��是说第一�H�的内容已经没有用了。所有插入字典的�W�一�H�的串也已经没有用了。所以覆盖第一�H? 的内�Ҏ��合理的，��字�怸��W�一�H�的串的开始位�|�都设�ؓ�I�Z��是合理的�?br />
��第二窗的内容复制到�W�一�H�中�Q�那么第二窗在字�怸�的所有烦引都需要做相应的修正�?br />
�? 于第二窗的内容已�l�复制到了第一�H�中�Q�所以我们可以将新的内容��d��到第二窗中，新的内容之前�?2KB的内容，��是原来的第二窗中的内容。而这�Ӟ��做过�? 正的字典中，仍然有原来第二窗中所有串的信息，也就是说�Q�新的内容，可以�l�箋利用前面一个窗口大��的范围之内的串�Q�进行压�~�，�q�也是合理的�?br />
2.4 其他问题1

�? 在来说明一下，��Z��么最��匹配长度�ؓ3个字节。这是由于，gzip 中，(匚w��长度�Q�相隔距��?对中�Q?匚w��长度"的范围�ؓ3-258�Q�也��是256�U�可能��|��需�?bit来保存�?盔R��距离"的范围�ؓ0-32K�Q�需�? 15bit来保存。所以一�?匚w��长度�Q�相隔距��?寚w��?3位，差一�?个字节。如果匹配串��于3个字节的话，使用(匚w��长度�Q�相隔距��?对进行替换，不但没有压羃�Q�反而还会增大。所以保�?匚w��长度�Q�相隔距��?�Ҏ��需要的位数�Q�决定了最��匹配长度至��要�?个字节�?br />
最大匹配长度�ؓ258的原因是�Q�综合各�U�因素，军_��?位来保存匚w��长度�Q?位的最大��gؓ255。实际中�Q�我们在(匚w��长度�Q�相隔距��?对中的“匹配长度”保存的是，实际匚w��长度-最��匹配长度，所�?55对应的实际匹配长度�ؓ258�?br />
在进行匹配时�Q�会对匹配长度进行判断，保证到达最大匹配长度时�Q�匹配就停止。也��是��_��即��有两个串的相同部分超�q�了最大匹配长度，也只匚w��到最大匹配长度�?br />
保存盔R��距离所用的位数和窗口大��是互相军_��的，�l�合两方面各�U�因素，��定了窗口大��，也就��定了保存相隔距��L��使用的位数�?br />
2.5 gzip �?LZ77部分的实现要�?br />
gzip �?LZ77 部分的实��C��要在函数 defalte() 中�?br />
所使用的缓冲区

window[] 用来放文件中��d��的内宏V�?br />
l_buf[]�Q�d_buf[]�Q�flag_buf[] 用来放LZ77压羃得到的结果�?br />l_buf[] 中的每个字节是一个没有匹配的字节�Q�或者是一个匹配的对中的匹配长�?3。l_buf[]��q��了inbuf[]�?br />d_buf[] 中的每个unsigned short�Q�是一个匹配的对中的相隔距��R�?br />flag_buf[] 中每位是一个标志，用来指示l_buf[]中相应字节是没有匚w��的字节，�q�是一个匹配的对中的匹配长�?3�?br />
prev[]�Q�head[] 用来存放字典信息。实际上 head 为宏定义 prev+WSIZE�?br />
初始化过�E�中�Q�调�?lm_init()�?br />lm_init() 中，从输入文件中��d��2个窗口大��，也就�?4KB的内容到window[]中。lookahead 中�ؓ�q�回的读入字节数。��用window中的头两个字节，UPDATE_HASH�Q�初始化ins_h�?br />
deflate() 中，一个处理��@环中�Q�首�?INSERT_STRING 把当前串插入字典�Q�INSERT_STRING 是一个宏�Q�作用就是用哈希函数计算当前串的ins_h�Q�然后把原来的head[ins_h]中的内容�Q�链入链中（攑ֈ�prev中）�Q�同时把原来的head [ins_h]保存在hash_head变量中，用来后面�q�行匚w��判断�Q�然后把当前串的开始位�|�，保存在head[ins_h]中�?br />
判断hash_head中保存的内容不�ؓ�I�，说明匚w��链上有内宏V��调�?longest_match () ��L��匚w��链上的最长匹配�?br />hash_head中保存的内容为空�Q�说明当前字节开始的�Ԍ��在窗口中没有匚w��?br />�׃��使用了lazy match�Q��得判断的情况更复杂�?br />
匚w��串的输出�Q�或者是没有匚w��的字节的输出�Q�都是调用函�?ct_tally()�?br />对于匚w��Ԍ��输出之后�Q�还需要�ؓ匚w��串中的每个字节��?INSERT_STRING�Q�把匚w��串中每个字节开始的串都插入到字�怸��?br />
ct_tally ()中，把传入的"没有匚w��的字�?或者是"匚w��长度-3"攑ֈ�l_buf[]中，然后��Z��后的Huffman�~�码做统计次数的工作�Q�如果传入的是匹配情况，传入的参��C��会有盔R��距离�Q�把盔R��距离保存在d_buf[]中。根据传入的参数�Q�可以判断是哪种情况�Q�然后设�|�一个变量中相应的标志位�Q�每8个标�? 位，也就是够一个字节，��׃��存到flag_buf[]中。还有一些判断，我们��在后面�q�行说明�?br />
2.6 分块输出

LZ77 压羃的结果放在，l_buf[]�Q�d_buf[]�Q�flag_buf[] 中�?br />对于 LZ77 的压�~�结果，可能使用一块输出或者分成多块输出（LZ77压羃一定的部分之后�Q�就�q�行一�ơ块输出�Q�输��Z��块）。块的大��不固定�?br />
输出的时候，会对LZ77的压�~�结果，�q�行Huffman�~�码�Q�最�l�把Huffman�~�码的结果输出到outbuf[]�~�冲��Z��?br />�q�行Huffman�~�码�Q��ƈ输出的工作，�?flush_block() 中进行�?br />
在ct_tally()中进行判断，如果满��一些条件的话，当从ct_tally()中返回之后，��׃��对现有的LZ77的结果，�q�行Huffman�~�码�Q�输出到一个块中�?br />在整个文件处理结束，deflate()函数要结束的时候，会把LZ77的结果，�q�行Huffman�~�码�Q�输出到一个块中�?br />
在ct_tally()中，每当l_buf[]中的字节敎ͼ�每个字节是一个没有匹配的字节或者一个匹配长度）增加0x1000�Q�也��是4096的时候。将估算压羃的情况，以判断现在结束这个块是否比较好，如果觉得比较好，��p��Z��个块。如果觉得不好，��先不输出�?br />
而当l_buf[]满了的时候，或者d_buf[]满了的时候，��肯定对现有的LZ77压羃的结果，�q�行Huffman�~�码�Q�输出到一个块中�?br />
�? 定输��Z��块的话，会只针对�q�一块的内容�Q�徏立Huffman树，�q�一块内容将会被�q�行Huffman�~�码压羃�Q��ƈ被输出到outbuf[]中。如果是动�? Huffman�~�码�Q�树的信息也被输出到outbuf[]中。输��Z��后，会调用init_block()�Q�初始化一个新块，重新初始化一些变量，包括动�? 树的�l�点被置0�Q�也��是��_��ؓ新块��来的Huffman树重新开始统计信息�?br />
输出块的大小是不固定的，首先在进行Huffman�~�码之前�Q�要输出的内容的大小��是不固定，要看情况�Q�进行Huffman�~�码之后�Q�就更不固定了�?br />块的大小不固定，那么解压�~�的时候，如何区分块呢。编码树中有一个表�C�块�l�束的结点，EOB�Q�在每次输出块的最后，输出�q�个�l�点的编码，所以解压羃的时候，当遇��C��q�个�l�点��p��明一个块�l�束了�?br />
每个块最开始的2位，用来指明本块使用的是哪种�~�码方式�Q?0表示直接存储�Q?1表示静态Huffman�~�码�Q?0表示动态Huffman�~�码。接下来�?位，指明本块是否是最后一块，0表示不是�Q?表示是最后一块�?br />
输出一个块�Q�对现在字典中的内容没有影响�Q�下一个块�Q�仍��用之前形成的字典，�q�行匚w��?br />

2.7 静态Huffman�~�码与动态Huffman�~�码

静态Huffman�~�码��是使用gzip自己预先定义好了一套编码进行压�~�，解压�~�的时候也使用�q�套�~�码�Q�这样不需要传递用来生成树的信息�?br />动态Huffman�~�码��是使用�l�计好的各个�W�号的出现次敎ͼ�建立Huffman树，产生各个�W�号的Huffman�~�码�Q�用�q��生的Huffman�~�码�q�行压羃�Q�这样需要传递生成树的信息�?br />
gzip 在�ؓ一块进行Huffman�~�码之前�Q�会同时建立静态Huffman树，和动态Huffman树，然后�Ҏ��要输出的内容和生成的Huffman树，计算�? 用静态Huffman树编码，生成的块的大��，以及计算使用动态Huffman树编码，生成块的大小。然后进行比较，使用生成块较��的�Ҏ��q�行 Huffman�~�码�?br />
对于静态树来说�Q�不需要传递用来生成树的那部分信息。动态树需要传递这个信息。而当文�g比较��的时候，传递生成树的信息得不偿失，反而会使压�~�文件变大。也��是说对于文件比较小的时候，��可能会出现使用静态Huffman�~�码比��用动态Huffman�~�码�Q�生成的块小�?br />
2.8 �~�码的��?br />
deflate ��法在Huffman树的基础上，又加入了几条规则�Q�我们把�q�样的树�U�C��deflate树，使得只要知道所有位长上的结点的个数�Q�就可以得到所有结点的�~? 码。这样做的原因是�Q�减��需要存攑֜�压羃压羃文�g中的用来生成树的信息。要惛_��明白�Q�deflate如何生成Huffman�~�码�Q�一定要弄明白一�? Huffman树，和deflate树的性质�Q�下面内�Ҏ��对Huffman树和deflate树做了些��单研�I�得到的�?br />
Huffman树的性质

1 叶子�l�点为n的话�Q�那么整颗树的�ȝ��点�ؓ 2n-1�?br />��单证明说明，先证�Q�最��的树，也就是只有三个结点，一个根节点�Q�两个叶子节点的树符合。然后在��M��W�合的树上做最��的��d��得到的树也符合。所以都�W�合�?br />
2 最左边的叶子结点的�~�码�?�Q�但是位长不一定�?br />
deflate中增加了附加条�g的huffman树的性质

1 同样位长的叶子结点的�~�码��gؓ�q�箋的，右面的��L��左面的大1�?br />
2 (n+1)位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的��gؓn位长最右面的叶子结点（也就是编码值最大的叶子�l�点�Q�的�?1�Q�然后变长一位（也就是左�U?位）�?br />
3 n位长的叶子结点，最右面的叶子结点（也就是编码值最大的叶子�l�点�Q�的��gؓ最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?加上 n位长的叶子结点的个数 �?1�?br />
4 (n+1)位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?�?n位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?加上 n位长的叶子结点的个数�Q�然后变长一位（也就是左�U?位）�?br />
�q�有一些树的性质�Q�比如，树的某一深度上最大可能编码数�?br />
从所有编码的位长�Q�得到所有编码的�~�码�Q?br />�l�计每个位长上的�~�码个数攑֜�bl_count[]中�?br />�Ҏ�� bl_count[] 中的��|��计算出每个位长上的最��编码��|��攑֜� next_code[] 中�?br />计算�Ҏ��为，code = (code + bl_count[bits-1]) << 1;
理由是deflate二叉树的性质�Q?n+1)位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?�?n位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?加上 n位长的叶子结点的个数�Q�然后变长一位（也就是左�U?位）�?br />
然后按照代码值的��序�Q��ؓ所有的代码�~�码�?br />�~�码�Ҏ��为，某一位长对应的next_code[n]�Q�最开始是�q�个位长上最左边的叶子结点的�~�码�Q�然�?+�Q�就是下一个该位长上下一个叶子结点的�~�码�Q�依�ơ类推，直到把这个位长上的叶子结点编码完。实际上的编码�ؓbi_reverse(next_code[])�?br />�q�样�~�码的理由是�Q�deflate二叉树的性质�?br />
2.9 5��|��

一共有5��|�� static_ltree[]�Q�static_dtree[]�Q�dyn_ltree[]�Q�dyn_dtree[]�Q�bl_tree[]�?br />
对于所有的树，一个叶子结点表�C�的�W�号的��gؓn的话�Q�那么这个符号对应的叶子�l�点攑֜� tree[n] 中，
比如 static_ltree 的叶子结�?a' 的��gؓ十进�?7�Q�那�?a'的叶子结点就攑֜� static_ltree[97] �?br />
static_ltree[] 静态Huffman�~�码�Ӟ��用来�Ҏ��有改动的字节和匹配长度进行编码的树�?br />static_dtree[] 静态Huffman�~�码�Ӟ��用来对相隔距��进行编码的树�?br />dyn_ltree[] 动态Huffman�~�码�Ӟ��用来�Ҏ��有改动的字节和匹配长度进行编码的树�?br />dyn_dtree[] 动态Huffman�~�码�Ӟ��用来对相隔距��进行编码的树�?br />bl_tree[] 动态Huffman�~�码�Ӟ��用来对解压羃时用来��生dyn_ltree[]和dyn_dtree[]的信息进行编码的树�?br />
静态树在初始化的时候，为每个叶子结点直接��生编码�?br />动态树�Q�每�ơ要输出一块的内容�Q�就�Ҏ��q�一块的内容�Q�生成动态树�Q�再�Ҏ��生成的动态树�Q��ؓ每个叶子�l�点产生�~�码�?br />
每次要输��Z��块的内容�Ӟ��会计��用静态树�~�码得到的块的大��，和用动态树�~�码得到的块的大��，然后谁��生的块小��q��谁�?br />
用静态编码的话，��׃��?static_ltree[]�Q�static_dtree[]�Q�来�q�行�~�码输出�?br />用动态编码的话，��׃��?dyn_ltree[]�Q�dyn_dtree[]�Q�bl_tree[] 来进行编码输出�?br />
2.10 叶子�l�点

ltree �Q�用来对没有改动的字节和匚w��长度�q�行�~�码的树�Q�静态，动态都一��P��的叶子结�?br />一�?L_CODES 个，也就�?86个�?br />0-255 256个叶子结点，是字节的256个�?br />256 1个叶子结点，�?END_BLOCK�Q�用来表�C�块�l�束的叶子结炏V�?br />257-285 29个叶子结点，是表�C�匹配长度的29个范围�?br />
dtree �Q�用来对盔R��距离�q�行�~�码的树�Q�静态，动态都一��P��的叶子结�?br />一�?D_CODES 个，也就�?0个�?br />0-29 30个叶子结点，是表�C�相隔距��ȝ��30个范围�?br />
bl_tree 的叶子结�?br />一�?BL_CODES 个，也就�?9个�?br />0-15 表示�~�码位长�?0-15�?br />16 复制之前的编码长�?-6�ơ。之后的两位指明重复�ơ数�?br />17 重复�~�码位长�?的，3-10�ơ，之后�?位指明重复次数�?br />18 重复�~�码位长�?的，11-138�ơ，之后�?位指明重复次数�?br />
2.11 静态Huffman�~�码

初始化base_length[],length_code[],base_dist[],dist_code[]�?br />
base_length[]为，29�?匚w��长度范围的，每个范围开始的长度倹{�?br />length_code[]为，256 个可能的匚w��长度所属的范围�?br />比如�Q�base_length[9]=0xa�Q�表�C�第9个范围的开始��gؓ0xa�?br />length_code[11]=9,表示匚w��长度�?1的匹配长度，属于�W?个范围�?br />
base_dist[],30�?匚w��距离范围的，每个范围的开始的��|��是每个范围内最��的倹{�?br />dist_code[],�q�个有点�Ҏ��Q�一共有32K个取��|��q�里把这32K�U��|��分成了两大类�Q?br />0-255�q?56个��gؓ一�c�，�q�时他们直接为dist_code[]的烦引�?br />256-32K��Z��c�，�q�时他们的去掉低7位，和最高位�Q�剩下的8位�ؓ索引�Q?位刚好烦�?56��V��能�q�么做的原因是，首先最�?2K的距��L��大需�?5位，所�?6位的最高位��M��会用�Q�其�ơ剩下这些范围的边界臛_��都�ؓ二进�? 000 0000 的整数倍�?br />比如匚w��距离�?10,��于256�Q�所以它属于�c?dist_code[10]=6�Q�第6�c�R�?br />�? 配距��Mؓ 10K �Q�大�?56�Q�所以它属于�c? dist_code[256+10K>>7]=dist_code[256+10240>>7]=dist_code[256+80] =dist_code[336]=0x1a=26�Q�属�?6�c�，26�cȝ��范围�?193-12288�Q?0240��是在这个范围内�?br />
指定了每个literal的位�ѝ��（一共将�?88个literal。包�?56个字节�?1个EOB+29个匹配长度范�?286个。多2个是��Z��满树。）�q�统计每个位长上的literal个数攑֜�bl_count[]中�?br />
�Ҏ�� bl_count[] 中的��|��计算出每个位长上的最��编码��|��攑֜� next_code[] 中�?br />计算�Ҏ��为，code = (code + bl_count[bits-1]) << 1;
理由是deflate二叉树的性质�Q?n+1)位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?�?n位长最左面的叶子结点（也就是编码值最��的叶子�l�点�Q�的�?加上 n位长的叶子结点的个数�Q�然后变长一位（也就是左�U?位）�?br />
然后从literal值的0�Q�到literal值的最大。�ؓ每个literal�~�码�?br />�~�码�Ҏ��为，某一位长对应的next_code[n]�Q�最开始是�q�个位长上最左边的叶子结点的�~�码�Q�然�?+�Q�就是下一个该位长上下一个叶子结点的�~�码�Q�依�ơ类推，直到把这个位长上的叶子结点编码完�?br />实际上的�~�码为bi_reverse(next_code[])�?br />比如
tree[n].Code = bi_reverse(next_code[len]++, len);

此时 next_code[len] ��gؓ 二进�?00110000 �?x30
tree[n].Code 最后被赋��gؓ 二进�?00001100 �?x0c

�q�样我们��得��C�� static_ltree[]�Q�它以literal的��gؓ索引�Q�存攄��literal对应的编码�?br />比如 'a' 的��gؓ十进�?7�Q?static_ltree[97].code=0x0089 static_ltree[97].len=8�?br />说明a的编码�ؓ二进�?10001001�?br />
为static_dtree �~�码。这个编码很��单，�׃��所有结炚w��?位长的（指定的）�Q�所以根据deflate二叉树性质�Q�最左边的叶子节点编码�ؓ0�Q�之后每�ơ加1卛_��Q�直到编�? 所有叶子结炏V��注意这里也要bi_reverse()一下。也��是��_��~�码�?从树根开始到一个叶子结点的路径对应的位��?的逆位��?br />
用Huffman�~�码对LZ77处理�l�果�q�行�~�码输出�?br />
�q�时�Q?br />l_buf[]中每个字节�ؓliteral或�?匚w��长度-MIN_MATCH�?br />d_buf[]为匹配距��，每项�?6位�?br />flag_buf[]中每位�ؓ指示inbuf[]中对应字节�ؓliteral�q�是匚w��长度-MIN_MATCH 的标志，比如
flag_buf�W�i位�ؓ1�Q�说明inbuf[i]为匹配长�?MIN_MATCH�?br />
��d��flag_buf中的每一位，�q�行判断�?br />如果�?�Q�表�C�对应的l_buf中的那个字节为literal�?br />如果�?�Q�表�C�对应的l_buf中的那个字节为匹配长�?MIN_MATCH�?br />
对于literal�Q�就用l_buf[]的这个值做索引�Q�在static_ltree中得到编码，和编码长度，然后输出�q�个�~�码�?br />
�? �? 匚w��长度-MIN_MATCH�Q�就用l_buf[]的这个值做索引�Q�在length_code[]中首先得到这个匹配长度所在的范围�Q�一共有29个范围�? 也就是说匚w��长度-MIN_MATCH 取��D��围�ؓ (3..258)�Q�一共有256�U�可能的倹{��这256�U�可能��|��被分配在�?9个范围中�?br />
我们用l_buf[]的这个值做索引�Q�在length_code[]中得到这个匹配长度所在的范围�?br />
然后�?范围�?256+1 得到该范围所对应�?literal。用�q�个literal做烦引，在static_ltree中得到编码，和编码长度，然后输出�q�个�~�码�?br />
然后�?范围�?做烦引，�?extra_lbits[] 中得到该范围的附加位的位敎ͼ�如果附加位位��C��?�Q?br />��p��出附加位。附加位�?inbuf[]中的那个��|��是匚w��长度-MIN_MATCH 减去 �q�个范围的对应的 base_length[]�?br />
然后从d_buf[]中取出，匚w��距离�?br />当匹配距��d��?56�Ӟ��用匹配距��d��索引�Q�在dist_code中取出对应的范围倹{�?br />当匹配距��M��于256�Ӟ��用匹配距��d��U?位，也就是用�?位，做烦引，在dist_code+256中取出对应的范围倹{�?br />
对匹配距��，匚w��距离的取��D��围�ؓ�Q?1..32,768)�Q�一共有32k�U�可能的倹{�?br />分成�?0个范围。由于匹配距��ȝ��取��D��围�ؓ�Q?1..32,768)�Q�所以匹配距��M��?5位�?br />
然后用距��ȝ��范围值做索引�Q�在static_dtree[] 中得到编码，和编码长度。然后输��个编码�?br />然后用距��ȝ��范围值做索引�Q�在extra_dbits[] 中得到该范围的附加位的位敎ͼ�如果附加位位��C��?�Q?br />��p��出附加位。输出的附加位�ؓ dist-base_dist[code]�?br />
比如�Q�取��Z��个dist�?0。dist_code[10]=6�Q�说明属于第6个范围�?br />然后�?extra_dbits,extra_dbits[6]=2�Q�说明有两个extra bits�?br />local int near extra_dbits[D_CODES] /* extra bits for each distance code */
= {0,0,0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8,9,9,10,10,11,11,12,12,13,13};
首先输出 static_dtree[6].len位的位流�Q�static_dree[6].code。（static_dtree的位镉K��?�Q?br />然后输出 extra_dbits[6]位的位流�Q?0-base_dist[6]=10-8=2=二进制的10�?br />
发送完inbuf中的每个字节之后�Q�最后发�?END_BLOCK 的编码�?br />
2.12 动态Huffman�~�码

��定所有literal�Q�匹配长度范��_��和匹配距��范围的出现�ơ数�?br />在进行LZ77压羃的过�E�中�Q�每��定一个literal或者匹配，都会调用 ct_tally()�?br />�?ct_tally() 中，如果是一个literal�Q�就 dyn_ltree[lc].Freq++�?br />如果是一个匹配，��?dyn_ltree[length_code[lc]+LITERALS+1].Freq++�Q�dyn_dtree[d_code(dist)].Freq++�?br />
调用 build_tree() 建立 literal和匹配长度范��_��也就是dyn_ltree的叶子结点，�?86个）的树�Q��ƈ��Z��们（literal和匹配长度范��_��~�码�?br />生成树中�Q�heap[]是用来辅助生成树的缓冲区�?br />
首先把tree[]中所有出现次��C��?的��|��也就是烦引，比如tree[0x61]��׃ؓ'a'的对应项�Q�，攑ֈ�heap[]中�?br />
tree[] 的元素个��Cؓ 2*L_CODES+1�Q�L_CODES为叶子结点的个数�Q?86�?br />由Huffman二叉树性质�Q�叶子结点�ؓn,那么�q�棵树的�ȝ��点�ؓ2n-1�?br />
tree[] ��用来保存生成的树。tree[]的前L_CODES ��，用来存放叶子�l�点。比�?a'的结点信息，攑֜�tree[0x61]中。L_CODES 之后的项用来放中间结炏V�?br />
heap[] ��用来放生成树的�q�程中��生的临时内容。heap[]的大��也�?2*L_CODES+1 。它的前 L_CODES 用来�?br />生成树过�E�中的结点，最开始是叶子�l�点�Q�随着生成树的�q�行�Q�两个叶子结点被弄掉�Q�放入他们的中间�l�点。后 L_CODES �Q�从后向前用。在生成树的�q�程中，所有结点（根，中间�Q�叶子）都将按权值大��顺序放在这里�?br />��来生成位长�Ӟ��需要��用�?br />
pqdownheap(tree, SMALLEST); 的作用就是将heap中的�l�点中，扑և�freq最��的那个�Q�放在heap[1]中�?br />
生成树的�q�程为，每次从heap中找��Z��个最��的�l�点�Q�然后给他们弄一个父�l�点。�ƈ把他们的tree[]的相应内�Ҏ��向他们的父结炏V�?br />�q�在heap中删掉这两个�l�点�Q�而把他们的父�l�点加入到heap中�?br />
heaplen 为heap中结点的个数�Q�每�ơ由于要�?个结点，�?个结点，所以每�ơ会使heaplen--�Q�也��是�l�点数变��一个�?br />
�{�到heaplen�Q�也��是�l�点敎ͼ��于2�Ӟ��说明树已�l�要弄好了�?br />
树生成好之后�Q�tree[]中的�?freq �?dad 都被讄��好了�Q�调�?gen_bitlen()�Q��ؓ他们生成位长�?br />
gen_bitlen()中，

从根开始，根的位长�?�Q�向下，为每个结点设�|�位�ѝ�?br />
判断是否为叶子结点，判断的方法是�Q�看是否大于最大代码，�q�里最大代码是286�?br />
当遇到叶子结�Ҏ��Q�进行动态编码整个文件的��M��长的计算�Q�和�q�行静态编码整个文件的��M��长的计算�?br />bl_count[bits]++; 用来一会儿产生�~�码�?br />�׃��在叶子结点的freq域中保存着�q�个�l�点的出现次敎ͼ�现在又有了位长，所以可以计��该�l�点的动态位�ѝ�?br />而所有的�l�点的动态位长篏加在一起就是��M��ѝ�?br />有了出现�ơ数�Q�对于静态，�l�点位长是设定好的，也同样可以进行计��?br />
最后调�?gen_codes()�Q��ؓ所有叶子结点��生编码。和静态Huffman中的�Ҏ��是相同的�?br />
调用 build_tree() 建立匚w��距离范围�Q�也��是dyn_dtree的叶子结点，�?0个）的树�Q��ƈ��Z��们（匚w��距离范围�Q�编码。和生成dyn_ltree的方法是相同的�?br />
调用 build_bl_tree() 为l�Q�literal&匚w��长度�Q�和d�Q�匹配距��）的位长数�l?生成树，�q��ؓ�q�些位长�~�码�?br />
调用scan_tree�l�计一个树中的�~�码长度情况�?br />分别对dyn_ltree和dyn_dtree�q�行�l�计�?br />
scan_tree((ct_data near *)dyn_ltree, l_desc.max_code);
scan_tree((ct_data near *)dyn_dtree, d_desc.max_code);

�l�计�l�果攑֜� bl_tree[].Freq 中�?br />
弄明白了bl_tree[]中叶子结点的含义�Q�就很容易理解scan_tree中所作的工作�?br />比如 bl_tree[0].Freq 表示�~�码位长�?的编码个数�?br />bl_tree[10].Freq 表示�~�码位长�?0的编码个数�?br />bl_tree[16].Freq 表示 �q�箋几个�~�码长度的出��C��数都相同�Q�这�U�情�늚�出现�ơ数�?br />
最后调�?build_tree() 建立位长情况�Q�就是那19�U�情况）的树�Q��ƈ��Z��们（��是�?9�U�情况）�~�码�?br />
发送用bl_tree�~�码的结点位长数�l��?br />defalte��法中，只要知道了一个树的每个叶子结点的位长�Q�就可以得到该叶子结点的�~�码�?br />所以我们需要发送ltree�?86个叶子结点的位长�Q�我们需要发送dtree�?0个叶子结点的位长�?br />
首先发送三个树的最大叶子结点值的一个变形�?br />send_bits(lcodes-257, 5); 发送ltree有效最大叶子结点�?1-257
send_bits(dcodes-1, 5); 发送dtree有效最大叶子结点�?1-1
send_bits(blcodes-4, 4); 发送bl_tree有效最大叶子结点�?1-4�?br />ltree最大叶子结点��|��决定了我们��要发送的ltree的叶子结点位长数�l�的个数。只发送到有效最大叶子结�Ҏ��p��了�?br />比如�Q�ltree有效最大叶子结点��gؓ0x102的话�Q�那么我们只需要发送ltree中前0x103个的位长�Q��ƈ告诉解压�~�程序，发送了0x103个就行了�?br />
发�?bl_tree 的位长，注意发送的��序是按 bl_order[] 中规定的��序发送的�?br />
调用 send_tree() 先后发�?dyn_ltree,dyn_dtree 的位�ѝ�?br />
send_tree()中��用和scan_tree()中相同的�Ҏ��Q�首先看�q�些位长属于bl_tree�?9个叶子结点对应的19�U�情况中的哪一�U�，��定了是哪一�U�之后，
��按�q�种情况对应的叶子结点，在bl_tree中的�~�码�Q�发送这个编码。直到把�q�些位长都发完�?br />
用Huffman�~�码对LZ77处理�l�果�q�行�~�码输出。和静态Huffman�~�码时��用的�Ҏ��是相同的�?br />
2.13 要点

�W�一�Q�省��M��LZ77用来指明�?没有改动的字�?�q�是"匚w��的信息对"的那个标志位�?br />
�׃��gzip实现中，把匹配长度的范围和字节��|��做�ؓ不同的叶子结点进行编码。比如说�Q��gؓ1的字节，和一个��gؓ1的匹配长度，他们的��D��然相同，但是他们是不同的叶子�l�点�Q�他们的�~�码也是不同的。这样一来，解压�~�时�Q�就可以直接区分�Q�就不必再输出那个指�C�Z��了�?br />
�q�个节省对压�~�率的改善应该有不小的帮助�?br />
静态Huffman�~�码�Ӟ��~�码本��n不会起到什么压�~�作用，但是�q�会从这个节省中��L��?br />
�W�二�Q�叶子结�Ҏ��表示的内宏V�?br />
我们看到gzip的实��C��Q�叶子节�Ҏ��代表的内容各�U�各��P��不仅仅是一个固定的��|��而且有些代表了一个值的范围�Q�（然后用之后的更多的位来表�C��个范围中的一个��|��Q�而且�q�有代表情况的�?br />
�q�个实现�Ҏ��是相当不错的�Q�非常值得借鉴�?br />
解压�~�也不说了，原因看最后�?br />
2.14 匚w��延��到lookahead�?br />
可以�q�行�q�种压羃�Q�与解压�~�，关键是解压羃的处理中�Q�做了特别的处理�?br />
例，�?0aaaaa

�q�行lz77压羃�Ӟ��当今行到下面位置�?0a 当前位置->aaaa
匚w��会�g伸到lookahead中，�l�果��是 0a[匚w��长度4�Q�距��?]

解压�~�时�Q�首�?a被做为没有改动的字节解压出来�Q?br />然后解压发现[匚w��长度4�Q�距��?]�Q?br />�q�里��做一个判断，看有没有延��到lookahead中，如果有的话，��做特别的处理，一个字节一个字节的�q�行复制�?br />
3 最�?/b>

一个�h�Q�从找资料，到读资料�Q�到��d��源码�Q�到写这个东西，�׃��三周多的旉��Q�太慢了。中间到处找人希望可以一��h��搞，也没扄��。太慢了�Q�太花时间了�Q�而且一个�h�Q�而且。反正一惌��v�q�事�Q�就得泪水打湿了双眼�Q�泪�q�三巡以后，�q�得把脖子��长，头�Ԓ成一个角度，吟道:"我观古昔之英雄，��h��然诺杯酒中。义重生�? �ȝ��己，所以与人成大功"。哭也哭了，诗也念了�Q�回味一下这巨感人的一套，自己把自己又感动的不行，于是再来一遍。如此这般，一遍一遍，惨不忍睹。唉�Q�还是该�q�吗�q�吗��d��?br />
参考资料：
《数据压�~�技术原理与范例�?br />rfc1951

�Ƣ迎交流�Q�欢�q�交朋友�Q?br />�Ƣ迎讉K��
主页 http://jiurl.yeah.net http://jiurl.nease.net 论坛 http://jiurl.cosoft.org.cn/forum

f啊k�Q�不带你们这��L��啊，有好事不叫我�?

swo 2006-08-19 14:54 发表评论

lzw压羃��法的c语言实现

swo — Sat, 19 Aug 2006 01:45:00 GMT

�E�序�׃��个模块组成�?br />
(1)  lzw.h      定义了一些基本的数据�l�构�Q�常量，�q�有变量的初始化�{��?br />
#ifndef __LZW_H__
#define __LZW_H__
//------------------------------------------------------------------------------
#include
#include
#include
#include
//------------------------------------------------------------------------------
#define LZW_BASE    0x102//  The code base
#define CODE_LEN       12   //  Max code length
#define TABLE_LEN      4099 // It must be prime number and bigger than 2^CODE_LEN=4096.
       // Such as 5051 is also ok.
#define BUFFERSIZE     1024
//------------------------------------------------------------------------------
typedef struct
{
    HANDLE      h_sour;  // Source file handle.
    HANDLE      h_dest;  // Destination file handle.

    HANDLE      h_suffix; // Suffix table handle.
    HANDLE      h_prefix; // Prefix table handle.
    HANDLE      h_code;  // Code table handle.

    LPWORD      lp_prefix; // Prefix table head pointer.
    LPBYTE      lp_suffix; // Suffix table head pointer.
    LPWORD      lp_code; // Code table head pointer.

    WORD        code;
    WORD        prefix;
    BYTE        suffix;

    BYTE        cur_code_len; // Current code length.[ used in Dynamic-Code-Length mode ]

}LZW_DATA,*PLZW_DATA;

typedef struct
{
    WORD        top;
    WORD        index;

    LPBYTE      lp_buffer;
    HANDLE      h_buffer;

    BYTE        by_left;
    DWORD       dw_buffer;

    BOOL        end_flag;

}BUFFER_DATA,*PBUFFER_DATA;

typedef struct                  //Stack used in decode
{
WORD        index;
HANDLE      h_stack;
LPBYTE      lp_stack;

}STACK_DATA,*PSTACK_DATA;
//------------------------------------------------------------------------------
VOID stack_create( PSTACK_DATA stack )
{
stack->h_stack  = GlobalAlloc( GHND , TABLE_LEN*sizeof(BYTE) );
stack->lp_stack = GlobalLock( stack->h_stack );
stack->index = 0;
}
//------------------------------------------------------------------------------
VOID stack_destory( PSTACK_DATA stack )
{
GlobalUnlock( stack->h_stack );
    GlobalFree  ( stack->h_stack );
}
//------------------------------------------------------------------------------
VOID buffer_create( PBUFFER_DATA    buffer )
{
    buffer->h_buffer   = GlobalAlloc(  GHND,  BUFFERSIZE*sizeof(BYTE)  );
    buffer->lp_buffer  = GlobalLock( buffer->h_buffer );
    buffer->top        = 0;
    buffer->index      = 0;
    buffer->by_left    = 0;
    buffer->dw_buffer  = 0;
    buffer->end_flag   = FALSE;
}
//------------------------------------------------------------------------------
VOID buffer_destory( PBUFFER_DATA   buffer )
{
    GlobalUnlock( buffer->h_buffer );
    GlobalFree  ( buffer->h_buffer );
}
//------------------------------------------------------------------------------
VOID re_init_lzw( PLZW_DATA lzw )    //When code table reached its top it should
{                                    //be reinitialized.
    memset( lzw->lp_code, 0xFFFF, TABLE_LEN*sizeof(WORD) );
    lzw->code          = LZW_BASE;
    lzw->cur_code_len  = 9;
}
//------------------------------------------------------------------------------
VOID lzw_create(PLZW_DATA    lzw,    HANDLE h_sour,    HANDLE h_dest)
{
WORD i;
    lzw->h_code        = GlobalAlloc( GHND, TABLE_LEN*sizeof(WORD) );
    lzw->h_prefix      = GlobalAlloc( GHND, TABLE_LEN*sizeof(WORD) );
    lzw->h_suffix      = GlobalAlloc( GHND, TABLE_LEN*sizeof(BYTE) );
    lzw->lp_code       = GlobalLock( lzw->h_code   );
    lzw->lp_prefix     = GlobalLock( lzw->h_prefix );
    lzw->lp_suffix     = GlobalLock( lzw->h_suffix );
    lzw->code          = LZW_BASE;
    lzw->cur_code_len  = 9;
    lzw->h_sour        = h_sour;
    lzw->h_dest        = h_dest;
    memset( lzw->lp_code, 0xFFFF, TABLE_LEN*sizeof(WORD) );

}
//------------------------------------------------------------------------------
VOID lzw_destory(PLZW_DATA    lzw)
{
    GlobalUnlock( lzw->h_code   );
    GlobalUnlock( lzw->h_prefix );
    GlobalUnlock( lzw->h_suffix );

GlobalFree( lzw->h_code  );
    GlobalFree( lzw->h_prefix );
    GlobalFree( lzw->h_suffix );
}
//------------------------------------------------------------------------------
#endif

(2) fileio.h   定义了一些文件操�?br />
#ifndef __FILEIO_H__
#define __FILEIO_H__
//------------------------------------------------------------------------------
#include
#include
#include
//------------------------------------------------------------------------------
HANDLE  file_handle(CHAR* file_name)
{
    HANDLE h_file;
    h_file = CreateFile(file_name,
                       GENERIC_READ|GENERIC_WRITE,
                       FILE_SHARE_READ|FILE_SHARE_WRITE,
                       NULL,
                       OPEN_ALWAYS,
                       0,
                       NULL
                       );
    return h_file;
}
//------------------------------------------------------------------------------
WORD load_buffer(HANDLE h_sour, PBUFFER_DATA buffer)  // Load file to buffer
{
    DWORD ret;
    ReadFile(h_sour,buffer->lp_buffer,BUFFERSIZE,&ret,NULL);
    buffer->index = 0;
    buffer->top = (WORD)ret;
    return (WORD)ret;
}
//------------------------------------------------------------------------------
WORD empty_buffer( PLZW_DATA lzw, PBUFFER_DATA buffer)// Output buffer to file
{

    DWORD ret;
    if(buffer->end_flag) // The flag mark the end of decode
{
  if( buffer->by_left )
  {
   buffer->lp_buffer[ buffer->index++ ] = (BYTE)( buffer->dw_buffer >> 32-buffer->by_left )<<(8-buffer->by_left);
  }
}
WriteFile(lzw->h_dest, buffer->lp_buffer,buffer->index,&ret,NULL);
    buffer->index = 0;
    buffer->top = ret;
    return (WORD)ret;
}
//------------------------------------------------------------------------------
#endif

(3) hash.h  定义了压�~�时所用的码表操作函数�Q��ؓ了快速查找��用了hash��法�Q�还有处理hash冲突的函�?br />
#ifndef __HASH_H__
#define __HASH_H__
//------------------------------------------------------------------------------
#include
#include
#include
//------------------------------------------------------------------------------
#define   DIV       TABLE_LEN
#define   HASHSTEP  13         // It should bigger than 0.
//------------------------------------------------------------------------------
WORD get_hash_index( PLZW_DATA lzw )
{
    DWORD tmp;
    WORD result;
    DWORD prefix;
    DWORD suffix;
    prefix = lzw->prefix;
    suffix = lzw->suffix;
    tmp = prefix<<8 | suffix;
    result = tmp % DIV;
    return result;
}
//------------------------------------------------------------------------------
WORD re_hash_index( WORD hash ) // If hash conflict occured we must recalculate
{                               // hash index .
    WORD result;
    result = hash + HASHSTEP;
    result = result % DIV;
    return result;
}
//------------------------------------------------------------------------------
BOOL in_table( PLZW_DATA lzw ) // To find whether current code is already in table.
{
    BOOL result;
    WORD hash;

    hash = get_hash_index( lzw );
    if( lzw->lp_code[ hash ] == 0xFFFF )
    {
        result = FALSE;
    }
    else
    {
        if( lzw->lp_prefix[ hash ] == lzw->prefix &&
            lzw->lp_suffix[ hash ] == lzw->suffix )
        {
            result = TRUE;
        }
        else
        {
            result = FALSE;
            while( lzw->lp_code[ hash ] != 0xFFFF )
            {
                if( lzw->lp_prefix[ hash ] == lzw->prefix &&
                    lzw->lp_suffix[ hash ] == lzw->suffix )
                {
                        result = TRUE;
                        break;
                }
                hash = re_hash_index( hash );
            }
        }
    }
    return result;
}
//------------------------------------------------------------------------------
WORD get_code( PLZW_DATA lzw )
{
    WORD hash;
    WORD code;
    hash = get_hash_index( lzw );
    if( lzw->lp_prefix[ hash ] == lzw->prefix &&
        lzw->lp_suffix[ hash ] == lzw->suffix )
    {
        code = lzw->lp_code[ hash ];
    }
    else
    {
        while( lzw->lp_prefix[ hash ] != lzw->prefix ||
               lzw->lp_suffix[ hash ] != lzw->suffix )
        {
                hash = re_hash_index( hash );
        }
        code = lzw->lp_code[ hash ];
    }
    return code;
}
//------------------------------------------------------------------------------
VOID insert_table( PLZW_DATA lzw )
{

    WORD hash;
    hash = get_hash_index( lzw );
    if( lzw->lp_code[ hash ] == 0xFFFF )
    {
        lzw->lp_prefix[ hash ] = lzw->prefix;
        lzw->lp_suffix[ hash ] = lzw->suffix;
        lzw->lp_code[ hash ]   = lzw->code;
    }
    else
    {
        while( lzw->lp_code[ hash ] != 0xFFFF )
        {
                hash = re_hash_index( hash );
        }
        lzw->lp_prefix[ hash ] = lzw->prefix;
        lzw->lp_suffix[ hash ] = lzw->suffix;
        lzw->lp_code[ hash ]   = lzw->code;
    }

}
//------------------------------------------------------------------------------

#endif

(4) encode.h  压羃�E�序��d��?br />
#ifndef __ENCODE_H__
#define __ENCODE_H__
//------------------------------------------------------------------------------
#include
#include
#include

//------------------------------------------------------------------------------
VOID output_code( DWORD code ,PBUFFER_DATA out, PLZW_DATA lzw)
{
    out->dw_buffer |= code << ( 32 - out->by_left - lzw->cur_code_len );
    out->by_left += lzw->cur_code_len;

    while( out->by_left >= 8 )
    {
        if( out->index == BUFFERSIZE )
        {
            empty_buffer( lzw,out);
        }

        out->lp_buffer[ out->index++ ] = (BYTE)( out->dw_buffer >> 24 );
        out->dw_buffer <<= 8;
        out->by_left -= 8;
    }
}
//------------------------------------------------------------------------------
VOID do_encode( PBUFFER_DATA in, PBUFFER_DATA out, PLZW_DATA lzw)
{
    WORD prefix;
    while( in->index != in->top )
    {
        if( !in_table(lzw) )
        {
                // current code not in code table
                // then add it to table and output prefix

                insert_table(lzw);
                prefix = lzw->suffix;
                output_code( lzw->prefix ,out ,lzw );
                lzw->code++;

                if( lzw->code == (WORD)1<< lzw->cur_code_len )
                {
                    // code reached current code top(1<                     // then current code length add one
     lzw->cur_code_len++;
     if( lzw->cur_code_len == CODE_LEN + 1 )
     {
      re_init_lzw( lzw );
     }

                }
        }
        else
        {
                // current code already in code table
                // then output nothing
                prefix = get_code(lzw);

        }
        lzw->prefix = prefix;
        lzw->suffix = in->lp_buffer[ in->index++ ];
    }
}

//------------------------------------------------------------------------------
VOID encode(HANDLE h_sour,HANDLE h_dest)
{
    LZW_DATA        lzw;
    BUFFER_DATA     in ;
    BUFFER_DATA     out;

    BOOL first_run = TRUE;

    lzw_create( &lzw ,h_sour,h_dest );
    buffer_create( &in );
    buffer_create( &out );

    while( load_buffer( h_sour, &in ) )
    {
        if( first_run )
        {// File length should be considered  but here we simply
         // believe file length bigger than 2 bytes.
                lzw.prefix = in.lp_buffer[ in.index++ ];
                lzw.suffix = in.lp_buffer[ in.index++ ];
                first_run = FALSE;
        }
        do_encode(&in , &out, &lzw);
    }

output_code(lzw.prefix, &out , &lzw);
output_code(lzw.suffix, &out , &lzw);
out.end_flag = TRUE;
    empty_buffer( &lzw,&out);

    lzw_destory( &lzw );
    buffer_destory( &in );
    buffer_destory( &out );
}

//------------------------------------------------------------------------------

#endif

(5) decode.h  解压函数��d��?br />
#ifndef __DECODE_H__
#define __DECODE_H__
//------------------------------------------------------------------------------
#include
#include
#include
//------------------------------------------------------------------------------
VOID out_code( WORD code ,PBUFFER_DATA buffer,PLZW_DATA lzw,PSTACK_DATA stack)
{
WORD tmp;
if( code < 0x100 )
{
  stack->lp_stack[ stack->index++ ] = code;
}
else
{
   stack->lp_stack[ stack->index++ ] = lzw->lp_suffix[ code ];
   tmp = lzw->lp_prefix[ code ];
   while( tmp > 0x100 )
   {
    stack->lp_stack[ stack->index++ ] = lzw->lp_suffix[ tmp ];
    tmp = lzw->lp_prefix[ tmp ];
   }
   stack->lp_stack[ stack->index++ ] = (BYTE)tmp;

}

while( stack->index )
{
  if( buffer->index == BUFFERSIZE )
  {
   empty_buffer(lzw,buffer);
  }
  buffer->lp_buffer[ buffer->index++ ] = stack->lp_stack[ --stack->index ] ;
}
}
//------------------------------------------------------------------------------
VOID insert_2_table(PLZW_DATA lzw )
{

lzw->lp_code[ lzw->code ]   = lzw->code;
lzw->lp_prefix[ lzw->code ] = lzw->prefix;
lzw->lp_suffix[ lzw->code ] = lzw->suffix;
lzw->code++;

if( lzw->code == ((WORD)1<cur_code_len)-1 )
{
  lzw->cur_code_len++;
  if( lzw->cur_code_len == CODE_LEN+1 )
      lzw->cur_code_len = 9;
}
if(lzw->code >= 1< {
  re_init_lzw(lzw);
}

}
//------------------------------------------------------------------------------
WORD get_next_code( PBUFFER_DATA buffer , PLZW_DATA lzw )
{

BYTE next;
WORD code;
while( buffer->by_left < lzw->cur_code_len )
{
  if( buffer->index == BUFFERSIZE )
  {
   load_buffer( lzw->h_sour, buffer );
  }
  next = buffer->lp_buffer[ buffer->index++ ];
  buffer->dw_buffer |= (DWORD)next << (24-buffer->by_left);
  buffer->by_left   += 8;
}
code = buffer->dw_buffer >> ( 32 - lzw->cur_code_len );
buffer->dw_buffer <<= lzw->cur_code_len;
buffer->by_left    -= lzw->cur_code_len;

return code;
}
//------------------------------------------------------------------------------
VOID do_decode( PBUFFER_DATA in, PBUFFER_DATA out, PLZW_DATA lzw, PSTACK_DATA stack)
{
WORD code;
WORD tmp;
while( in->index != in->top  )
{
  code = get_next_code( in ,lzw );

  if( code < 0x100 )
  {
   // code already in table
   // then simply output the code
   lzw->suffix = (BYTE)code;
  }
  else
  {
   if( code < lzw->code  )
   {
    // code also in table
    // then output code chain

    tmp = lzw->lp_prefix[ code ];
    while( tmp > 0x100 )
    {
     tmp = lzw->lp_prefix[ tmp ];
    }
    lzw->suffix = (BYTE)tmp;
   }
   else
   {
    // code == lzw->code
    // code not in table
    // add code into table
    // and out put code
    tmp = lzw->prefix;
    while( tmp > 0x100 )
    {
     tmp = lzw->lp_prefix[ tmp ];
    }
    lzw->suffix = (BYTE)tmp;
   }
  }
  insert_2_table( lzw );
  out_code(code,out,lzw,stack);

  lzw->prefix = code;

}

}
//------------------------------------------------------------------------------
VOID decode( HANDLE h_sour, HANDLE h_dest )
{
    LZW_DATA        lzw;
    BUFFER_DATA     in ;
    BUFFER_DATA     out;
STACK_DATA      stack;
BOOL   first_run;

first_run = TRUE;

    lzw_create( &lzw ,h_sour,h_dest );
    buffer_create( &in );
    buffer_create( &out );
stack_create(&stack );

    while( load_buffer( h_sour, &in ) )
    {
  if( first_run )
  {
   lzw.prefix = get_next_code( &in, &lzw );
   lzw.suffix = lzw.prefix;
   out_code(lzw.prefix, &out, &lzw , &stack);
   first_run = FALSE;
  }
        do_decode(&in , &out, &lzw, &stack);
    }

    empty_buffer( &lzw,&out);

    lzw_destory( &lzw );
    buffer_destory( &in );
    buffer_destory( &out );
stack_destory( &stack);
}

#endif

2  下面�l�出一个应用上面模块的��单例�?br />
#include
#include
//------------------------------------------------------------------------------

#include "lzw.h"
#include "hash.h"
#include "fileio.h"
#include "encode.h"
#include "decode.h"

//------------------------------------------------------------------------------
HANDLE h_file_sour;
HANDLE h_file_dest;
HANDLE h_file;
CHAR*  file_name_in = "d:\\code.c";
CHAR*  file_name_out= "d:\\encode.e";
CHAR*  file_name    = "d:\\decode.d";

//------------------------------------------------------------------------------
int main(int argc, char *argv[])
{
    h_file_sour = file_handle(file_name_in);
    h_file_dest = file_handle(file_name_out);
    h_file     = file_handle(file_name);

  encode(h_file_sour, h_file_dest);
// decode(h_file_dest,h_file);

    CloseHandle(h_file_sour);
    CloseHandle(h_file_dest);
    CloseHandle(h_file);

  return 0;
}

3  后语

  之前研究gif文�g格式时偶然接触了lzw压羃��法�Q�于是就惌��己动手实现。从一开始看人家的原码，然后跟着模仿�Q�到现在用自��q��语言表达出来�Q�从理解原理��C��码的实现��p��了不��时间与�_�֊��Q�但是真正的快乐也就在这里，现在把她拿出来跟大家分��n也就是分享快乐�?img src ="http://m.shnenglu.com/swo2006/aggbug/11431.html" width = "1" height = "1" />

swo 2006-08-19 09:45 发表评论

Gzip Zlib PNG 压羃��法,源码详解

swo — Sat, 19 Aug 2006 00:51:00 GMT

我们对算法做三种�E�度的说明。第一�U�程度，对gzip所使用压羃��法基本原理的说明。第二种�E�度�Q�对gzip压羃��法实现�Ҏ��的说明。第三种�E�度�Q�对gzip实现源码�U�的说明�?br />　
　　1 gzip所使用压羃��法的基本原�?br /> 　　
　　gzip 对于要压�~�的文�g�Q�首先��用lz77��法�q�行压羃�Q�对得到的结果再使用huffman�~�码的方法进行压�~�。所以我们分别对lz77和huffman�~�码的原理进行说明�?br /> 　　

　　
　　2 gzip压羃��法实现�Ҏ��
　　
　　2.1 LZ77��法的gzip实现
　　
　　首先�Q�gzip 从要压羃的文件中��d��64KB的内容到一个叫window的缓冲区中。�ؓ了简单�v见，我们�?2KB以下文�g的压�~��ؓ例做说明。对于我们这里��?2KB 以下文�g�Q�gzip��整个文件读入到window�~�冲��Z��。然后��用一个叫strstart的变量在window数组中，�?开始一直向后移动�? strstart在每一个位�|�上�Q�都在它之前的区域中�Q�寻扑֒�当前strstart开始的串的�?个字节匹配的�Ԍ��q�试图从�q�些匚w��串中扑ֈ�最长的匚w�� 丌Ӏ?br /> 　　
　　如果当前的strstart开始的�Ԍ��可以扑ֈ�最��ؓ3个字节的匚w��串的话，当前的strstart开始的匚w��长度那么长的�Ԍ��会被一�?lt;匚w��长度,到匹配串开头的距离>�Ҏ��换�?br /> 　　
　　如果当前的strstart开始的�Ԍ��找不��C�Q何的最��ؓ3个字节的匚w��串的话，那么当前strstart的所在字节将不作改动�?br /> 　　
　　��Z��区分是一�?lt;匚w��长度,到匹配串开头的距离>对，�q�是一个没有被改动的字节，�q�需要�ؓ每一个没有被改动的字节或�?lt;匚w��长度,到匹配串开头的距离>对，另外再占用一
　　位，来进行区分。这位如果�ؓ1�Q�表�C�是一�?lt;匚w��长度,到匹配串开头的距离>对，�q�位如果�?�Q�表�C�是一个没有被改动的字节�?br /> 　　
　　现在来说明一下，��Z��么最��匹配�ؓ3个字节。这是由于，gzip 中，<匚w��长度,到匹配串开头的距离>对中�Q?匚w��长度"的范围�ؓ3-258�Q�也��是256�U�可能��|��需�?bit来保存�?到匹配串开头的距离"的范围�ؓ0-32K�Q�需�?5bit来保存。所以一�?lt;匚w��长度,到匹配串开头的距离>寚w��?3位，差一�?个字节。如果匹配串��于 3个字节的话，使用<匚w��长度,到匹配串开头的距离>对进行替换，不但没有压羃�Q�反而还会增大。所以保�?lt;匚w��长度,到匹配串开头的�? ��?gt;�Ҏ��需要的位数�Q�决定了最��匹配长度至��要�?个字节�?br /> 　　
　　下面我们��来介绍gzip如何实现��L��当前strstart开始的串的最长匹配串�?br /> 　　
　　如果每次为当前串��L��匚w��串时�Q�都要和之前的每个串的至��?个字节进行比较的话，那么比较量将是非帔R��常大的。�ؓ了提高比较速度�Q�gzip使用了哈�? 表。这是gzip实现LZ77的关键。这个哈希表是一个叫head的数�l�（后面我们��看��Cؓ什么这个缓冲区叫head�Q�。gzip对windows中的�? 个串�Q��用串的头三个字节�Q�也��是strstart,strstart+1,strstart+2�Q�用一个设计好的哈希函数来�q�行计算�Q�得��C��个插入位�|? ins_h。也��是用串的头三个字节来确定一个插入位�|�。然后把串的位置�Q�也��是 strstart的��|��保存在head数组的第ins_h��中。我们马上就可以看到��Z��么要�q�样做。head数组在没有插入�Q何值时�Q�全部�ؓ0�?br />
当某处的当前串的三个字节��定了一个ins_h�Q��ƈ把当时当前串的位�|�也��是当时的strstart保存在了head[ins_h]中。之后另一处，当另一处的当前串的头三个字节，再�ؓ那三个字节时�Q�再使用那个哈希函数来计��，�׃��是同��L��三个字节�Q�同��L��哈希函数�Q�得到的ins_h必然和前面得到的 ins_h是相同的。于是就会发现head[ins_h]不�ؓ0。这��p��明了�Q�有一个头三个字节和自��q��同的串把自己的位�|�保存在了这里，现在head [ins_h]中保存的��|��也就是那个串的开始位�|�，我们��可以找到那个串�Q�那个串臛_��?个字节和当前串的�?个字节相同（�E�后我们��可以看到这�U�说�? 不准��，�q�里是�ؓ了说明方便）�Q�我们可以找到那个串�Q�做�q�一步比较，看到底能有多长的匚w��?br /> 　　
　　我们现在来说明一下，相同的三个字节，通过哈希函数得到的ins_h必然是相同的。而不同的三个字节�Q�通过哈希函数有没有可能得到同一个ins_h�Q? 我没有对�q�个哈希函数做研�IӞ��q�不清楚�Q�不�q�一般的哈希函数都是�q�样的，所以极大可能这里的也会是这�U�情况，即不同的三个字节�Q�通过哈希函数有可能得到同一个ins_h�Q�不�q�这�q�不要紧�Q�我们发现有可能是匹配串之后�Q�还会进行串的比较�?br /> 　　
　　一个文件中�Q�可能有很多个串的头三个字节都是相同的，也就是说他们计算得到的ins_h都是相同的，如何能保证找��C��们中的每一个串呢？gzip使用一个链把他们链在一赗��gzip每次把当前串的位�|�插入head的当前串头三个字节算出的ins_h处时�Q�都会首先把原来的head[ins_h]的��|�� 保存��C��个叫prev的数�l�中�Q�保存的位置��在现在的strstart处。这样当以后某处的当前串计算出ins_h�Q�发现head[ins_h]不空�Ӟ�� 可以到prev[ head[ins_h] ]中找到更前一个的头三个字节相同的串的位置。对此我们�D例说明�?br /> 　　
　　例，�?br /> 　　0abcdabceabcfabcg
　　^^^^^^^^^^^^^^^^^
　　01234567890123456
　　
　　整个串被压羃�E�序处理之后�?br /> 　　
　　由abc��出ins_h�?br /> 　　�q�时的head[ins_h]中�ؓ 13,�?abcg"的开始位�|��?br /> 　　�q�时prev[13]中�ؓ 9�Q�即"abcfabcg"的开始位�|��?br /> 　　�q�时prev[9]中�ؓ 5�Q�即"abceabcfabcg"的开始位�|��?br /> 　　�q�时prev[5]中�ؓ 1�Q�即"abcdabceabcfabcg"的开始位�|��?br /> 　　�q�时prev[1]中�ؓ 0�?br /> 　　
　　我们看到所有头三个字母为abc的串�Q�被铑֜�了一��P��从head可以一直找下去�Q�直到找�?�?br /> 　　
　　现在我们也就知道了，三个字节通过哈希函数计算得到同一ins_h的所有的串被铑֜�了一��P��head[ins_h]为链��_��prev数组中放着的更早的丌Ӏ�这也就是head和prev名称的由
　　来�?br /> 　　
　　gzip��L��匚w��串的另外一个值得注意的实现是�Q��g�q�匹配。会�q�行两次��试。比如当前串为str,那么str发生匚w��以后�Q��ƈ不发生压�~�，�q�会对str+1串进行匹配，然后看哪�U?
　　匚w��效果好�?br /> 　　
　　例子 ...
　从这个例子中我们��q��C��做另外一�ơ尝试的原因。如果碰到的一个匹配就使用了的话，可能错过更长匚w��的机会。现在做两次会有所改善�?br /> 　　
　　...
　　
　　2.2 问题讨论
　　
　　我在�q�里对gzip压羃��法做出了一些说明，是希望可以和对gzip或者压�~�解压羃感兴��的朋友�q�行交流�?br /> 　　我对gzip的了解要比这里说的更多一些，也有更多的例子。如果哪位朋友愿意对下面的问题进行研�IӞ��以及其他压羃解压�~�的问题�q�行研究�Q�来�q�里 http://jiurl.cosoft.org.cn/forum/ 和我交流的话�Q�我也愿意就我知道的内容�q�行更多的说明�?br /> 　　
　　下面是几个问�?br /> 　　
　　�q�种匚w��法�Q�即�?个字�?最��匹�?来计��一个整敎ͼ�是否比用串比较来得高效，高效��C��么程度�?br /> 　　
　　哈希函数的讨论。不同的三个字节�Q�是否可能得到同一个ins_h。ins_h和计��它的三个字节的关系�?br /> 　　
　　几次延迟��试比较好？
　　
　　用�g�q�，两次��试是否对压�~�率的改善是非常有限的？
　　
　　影响lz77压羃率的因素�?br /> 　　
　　压羃的极限�?br /> 　　　　
　　2.3 ...
　　
　　3 gzip源码分析
　　
　　main() 中调用函�?treat_file() �?br /> 　　treat_file() 中打开文�g�Q�调用函�?zip()。注意这里的 work 的用法，�q�是一个函数指针�?br /> 　　zip() 中输出gzip文�g格式的头�Q�调�?bi_init�Q�ct_init�Q�lm_init�Q?br /> 　　其中在lm_init中将 head 初始化清0。初始化strstart�?。从文�g中读�?4KB的内容到window�~�冲��Z��?br /> 　　�׃��计算strstart=0时的ins_h�Q�需�?,1,2�q�三个字节和哈希函数发生关系�Q�所以在lm_init中，预读0,1两个字节�Q��ƈ和哈希函数发生关�p�R�?br /> 　　
　　然后lm_init调用 deflate()�?br /> 　　deflate() gzip的LZ77的实��C��要deflate()中�?br /> 　　...

swo 2006-08-19 08:51 发表评论

A Brief History of zlib

swo — Fri, 18 Aug 2006 08:23:00 GMT

A Brief History of zlib

The origins of zlib can be found in the history of Info-ZIP. Info-ZIP is loosely organized group of programmers who give the following reason for their existence:

Info-ZIP's purpose is to provide free, portable, high-quality versions of the Zip and UnZip compressor-archiver utilities that are compatible with the DOS-based PKZIP by PKWARE, Inc.

These free versions of Zip and UnZip are world class programs, and are in wide use on platforms ranging from the orphaned Amiga through MS-DOS PCs up to high powered RISC workstations. But these programs are designed to be used as command line utilities, not as library routines. People have found that porting the Info-ZIP source into an application could be a grueling exercise.

Fortunately for all of us, two of the Info-ZIP gurus took it upon themselves to solve this problem. Mark Adler and Jean-loup Gailly single-handedly created zlib, a set of library routines that provide a safe, free, and unpatented implementation of the deflate compression algorithm.

One of the driving reasons behind zlib's creation was for use as the compressor for PNG format graphics. After Unisys belatedly began asserting their patent rights to LZW compression, programmers all over the world were thrown into a panic over the prospect of paying royalties on their GIF decoding programs. The PNG standard was created to provide an unencumbered format for graphics interchange. The zlib version of the deflate algorithm was embraced by PNG developers, not only because it was free, but it also compressed better than the original LZW compressor used in GIF files.

zlib turns out to be good for more than graphics developers, however. The deflate algorithm makes an excellent general purpose compressor, and as such can be incorporated into all sorts of different software. For example, I use zlib as the compression engine in Greenleaf's ArchiveLib, a data compression library that work with ZIP archives. It's performance and compatibility mean I didn't have to reinvent the wheel, saving precious months of development time.

zlib's interface

As a library developer, I know that interfaces make or break a library. Performance issues are important, but if an awkward API makes it impossible to integrate a library into your program, you've got a problem.

zlib's interface is confined to just a few simple function calls. The entire state of a given compression or decompression session is encapsulated in a C structure of type z_stream, whose definition is shown in Figure 1.

typedef struct z_stream_s {
  Bytef *next_in;    /* next input byte */
  uInt avail_in;     /* number of bytes available at next_in */
  uLong total_in;    /* count of input bytes read so far */
  Bytef *next_out;   /* next output byte should be put there */
  uInt avail_out;    /* remaining free space at next_out */
  uLong total_out;   /* count of bytes output so far */
  char *msg;         /* last error message, NULL if no error */
  struct internal_state *state; /* not visible by applications*/
  alloc_func zalloc; /* used to allocate the internal state*/
  free_func zfree;   /* used to free the internal state */
  voidpf opaque;     /* private data passed to zalloc and zfree*/
  int data_type;     /* best guess about the data: ascii or binary*/
  uLong adler;       /* adler32 value of the uncompressed data */
  uLong reserved;    /* reserved for future use */
} z_stream;

Figure 1
The z_stream object definition

Using the library to compress or decompress a file or other data object consists of three main steps:

Creating a z_stream object.
Processing input and output, using the z_stream object to communicate with zlib.
Destroying the z_stream object.

An overview of the process is shown in Figure 2.

Figure 2
The compression or decompression process

Steps 1 and 3 of the compression process are done using conventional function calls. The zlib API, documented in header file zlib.h, prototypes the following functions for initialization and termination of the compression or decompression process:

deflateInit()
inflateInit()
deflateEnd()
inflateEnd()

Step 2 is done via repeated calls to either inflate() or deflate(), passing the z_stream object as a parameter. The entire state of the process is contained in that object, so there are no global flags or variables, which allows the library to be completely reentrant. Storing the state of the process in a single object also cuts down on the number of parameters that must be passed to the API functions.

When performing compression or decompression, zlib doesn't perform any I/O on its own. Instead, it reads data from an input buffer pointer that you supply in the z_stream object. You simply set up a pointer to the next block of input data in member next_in, and place the number of available bytes in the avail_in member. Likewise, zlib writes its output data to a memory buffer you set up in the next_out member. As it writes output bytes, zlib decrements the avail_out member until it drops to 0.

Given this interface, Step 2 of the compression process for an input file and an output file might look something like this:

z_stream z;
char input_buffer[ 1024 ];
char output_buffer[ 1024 ];
FILE *fin;
FILE *fout;
int status;
...
    z.avail_in = 0;
    z.next_out = output_buffer;
    z.avail_out = 1024;
    for ( ; ; ) {
        if ( z.avail_in == 0 ) {
            z.next_in = input_buffer;
            z.avail_in = fread( input_buffer, 1, 1024, fin );
        }
        if ( z.avail_in == 0 )
             break;
        status = deflate( &z, Z_NO_FLUSH );
        int count = 1024 - z.avail_out;
        if ( count )
            fwrite( output_buffer, 1, count, fout );
        z.next_out = output_buffer;
        z.avail_out = 1024;
    }

Figure 3
The code to implement file compression

This method of handling I/O frees zlib from having to implement system dependent read and write code, and it insures that you can use the library to compress any sort of input stream, not just files. It's simply a matter of replacing the wrapper code shown above with a version customized for your data stream.

Wrapping it up

zlib's versatility is one of its strengths, but I don't always need all that flexibility. For example, to perform the simple file compression task Scott asked about at the start of this article, it would be nice to just be able to call a single function to compress a file, and another function to decompress. To make this possible, I created a wrapper class called zlibEngine.

zlibEngine provides a simple API that automates the compression and decompression of files and uses virtual functions to let you customize your user interface to zlib. The class definition is shown in its entirety in Figure 4. There are two different groups of members that are important to you in ZlibEngine. The first is the set of functions providing the calling interface to the engine. The second is the set of functions and data members used to create a user interface that is active during the compression process.

class ZlibEngine : public z_stream {
    public :
        ZlibEngine();
            int compress( const char *input,
                          const char *output,
                          int level = 6 );
        int decompress( const char *input,
                        const char *output );
        void set_abort_flag( int i ){ m_AbortFlag = i; }
    protected :
        int percent();
        int load_input();
        int flush_output();
    protected :
        virtual void progress( int percent ){};
        virtual void status( char *message ){};
    protected :
        int m_AbortFlag;
        FILE *fin;
        FILE *fout;
        long length;
        int err;
        enum { input_length = 4096 };
        unsigned char input_buffer[ input_length ];
        enum { output_length = 4096 };
        unsigned char output_buffer[ output_length ];
};

Figure 4
The ZlibEngine wrapper class

The Calling API

There are three C++ functions that implement the API needed to perform simple compression and decompression. Before using the engine, you must call the constructor, the first function. Since ZlibEngine is derived from the z_stream object used as the interface to zlib, the constructor is in effect also creating a z_stream object that will be used to communicate with zlib. In addition, the constructor initializes some of the z_stream member variables that will be used in either compression or decompression.

The two remaining functions are nice and simple: compress() compresses a file using the deflate algorithm. An optional level parameter sets a compression factor between 9 (maximum compression) and 0 (no compression.) decompress() decompresses a file, as you would expect. The compression level parameter isn't necessary when decompressing, due to the nature of the deflate algorithm. Both of these functions return an integer status code, defined in the zlib header file zlib.h. Z_OK is returned when everything works as expected. Note that I added an additional code, Z_USER_ABORT, used for an end user abort of the compression or decompression process.

The wrapper class makes it much easier to compress or decompress files using zlib. You only need to remember three things:

Include the header file for the wrapper class, zlibengn.h.
Construct a ZlibEngine object.
Call the member functions compress() or decompress() to do the actual work.

This means you can now perform compression with code this simple:

#include 

int foo()
{
    ZlibEngine engine;
    return engine.compress( "INPUT.DAT", "INPUT.DA_");
}

That's about as simple as you could ask for, isn't it?

The User Interface API

The calling API doesn't really make much of a case for creating the ZlibEngine class. Based on what you've seen so far, the compress() and decompress() functions don't really need to be members of a class. In theory, a global compress() function could just instantiate a z_stream object when called, without the caller even being aware of it.

The reason for creating this engine class is found in a completely different area: the user interface. It's really nice to be able to track the progress of your compression job while it's running. Conventional C libraries have to make do with callback functions or inflexible standardized routines in order to provide feedback, but C++ offers a better alternative through the use of virtual functions.

The ZlibEngine class has two virtual functions that are used to create a useful user interface: progress() is called periodically during the compression or decompression process, with a single integer argument that tells what percentage of the input file has been processed. status() is called with status messages during processing.

Both of these virtual functions have access to the ZlibEngine protected data element, m_AbortFlag. Setting this flag to a non-zero value will cause the compression or decompression routine to abort immediately. This easily takes care of another sticky user interface problem found when using library code.

Writing your own user interface then becomes a simple exercise. You simply derive a new class from ZlibEngine, and define your own versions of one or both of these virtual functions. Instantiate an object of your class instead of ZlibEngine, and your user interface can be as spiffy and responsive as you like!

Command line compression

I wrote a simple command line test program to demonstrate the use of class ZlibEngine. zlibtest.cpp does a simple compress/decompress cycle of the input file specified on the command line. I implement a progress function that simply prints out the current percent towards completion as the file is processed:

class MyZlibEngine : public ZlibEngine {
    public :
        void progress( int percent )
        {
            printf( "%3d%%\b\b\b\b", percent );
            if ( kbhit() ) {
                getch();
                m_AbortFlag = 1;
            }
        } 
};

Since class ZlibEngine is so simple, the derived class doesn't even have to implement a constructor or destructor. The derived version of progress() is able to provide user feedback as well as an abort function with just a few lines of code. zlibtest.cpp is shown in its entirety in Listing 1.

The OCX

To provide a slightly more complicated test of class ZlibEngine, I created a 32 bit OCX using Visual C++ 4.1. The interface to an OCX is defined in terms of methods, events, and properties. ZlibTool.ocx has the following interface:

Properties:	InputFile
	OutputFile
	Level
	Status

Methods:	Compress()
	Decompress()
	Abort()

Events:	Progress()

(Note that I chose to pass status information from the OCX using a property, not an event.)

ZlibTool.ocx is a control derived from a standard Win32 progress bar. The progress care gets updated automatically while compressing or decompressing, so you get some user interface functionality for free. Using it with Visual Basic 4.0 or Delphi 2.0 becomes a real breeze. After registering the OCX, you can drop a copy of it onto your form and use it with a minimal amount of coding.

Both the source code for the OCX and a sample Delphi 2.0 program are available on the DDJ listing service. A screen shot of the Delphi program in action is shown in Figure 5.

Figure 5

The Delphi 2.0 OCX test program

Reference material

The source code that accompanies this article can be downloaded from this Web page. It contains the following source code collections:

The complete source for zlib
The Visual C++ 4.1 project for the ZlibTool OCX
The Delphi 2.0 project that exercises the OCX
The Console test program that exercises the ZlibEngine class

Each of the subdirectories contains a README.TXT file with documentation describing how to build and use the programs.

The source is split into two archives:

zlibtool.zip	All source code and the OCX file.
zlibdll.zip	The supporting MFC and VC++ DLLs. Many people will already have these files on their systems: MFC40.DLL, MSVCRT40.DLL, and OLEPRO32.DLL.

I haven't discussed the zlib code itself in this article. The best place to start gathering information about how to use zlib and the Info-ZIP products can be found on their home pages. Both pages have links to the most current versions of their source code as well:

Info-ZIP	http://www.info-zip.org
zlib	http://www.gzip.org/zlib

Once you download the Info-ZIP code, the quick start documentation is found in source file zlib.h. If you cook up any useful code that uses zlib, you might want to forward copies to Greg Roelofs for inclusion on the zlib home page. Greg maintains the zlib pages, and you can reach him via links found there.

Feel-good plug

zlib can do a lot more than just compress files. Its versatile interface can be used for streaming I/O, in-memory compression, and more. Since Jean-loup Gailly and Mark Adler were good enough to make this capable tool available to the public, it only makes sense that we take advantage of it. I know I have, and I encourage you to do the same.

swo 2006-08-18 16:23 发表评论

ZLIB Compressed Data Format Specification version 3.3

swo — Fri, 18 Aug 2006 06:40:00 GMT

ZLIB Compressed Data Format Specification version 3.3

Status of This Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

IESG Note:

   The IESG takes no position on the validity of any Intellectual
   Property Rights statements contained in this document.

Notices

   Copyright (c) 1996 L. Peter Deutsch and Jean-Loup Gailly

   Permission is granted to copy and distribute this document for any
   purpose and without charge, including translations into other
   languages and incorporation into compilations, provided that the
   copyright notice and this notice are preserved, and that any
   substantive changes or deletions from the original are clearly
   marked.

   A pointer to the latest version of this and related documentation in
   HTML format can be found at the URL
   <ftp://ftp.uu.net/graphics/png/documents/zlib/zdoc-index.html>.

Abstract

   This specification defines a lossless compressed data format.  The
   data can be produced or consumed, even for an arbitrarily long
   sequentially presented input data stream, using only an a priori
   bounded amount of intermediate storage.  The format presently uses
   the DEFLATE compression method but can be easily extended to use
   other compression methods.  It can be implemented readily in a manner
   not covered by patents.  This specification also defines the ADLER-32
   checksum (an extension and improvement of the Fletcher checksum),
   used for detection of data corruption, and provides an algorithm for
   computing it.

Table of Contents

   1. Introduction ................................................... 2
      1.1. Purpose ................................................... 2
      1.2. Intended audience ......................................... 3
      1.3. Scope ..................................................... 3
      1.4. Compliance ................................................ 3
      1.5.  Definitions of terms and conventions used ................ 3
      1.6. Changes from previous versions ............................ 3
   2. Detailed specification ......................................... 3
      2.1. Overall conventions ....................................... 3
      2.2. Data format ............................................... 4
      2.3. Compliance ................................................ 7
   3. References ..................................................... 7
   4. Source code .................................................... 8
   5. Security Considerations ........................................ 8
   6. Acknowledgements ............................................... 8
   7. Authors' Addresses ............................................. 8
   8. Appendix: Rationale ............................................ 9
   9. Appendix: Sample code ..........................................10

1. Introduction

   1.1. Purpose

      The purpose of this specification is to define a lossless
      compressed data format that:

          * Is independent of CPU type, operating system, file system,
            and character set, and hence can be used for interchange;

          * Can be produced or consumed, even for an arbitrarily long
            sequentially presented input data stream, using only an a
            priori bounded amount of intermediate storage, and hence can
            be used in data communications or similar structures such as
            Unix filters;

          * Can use a number of different compression methods;

          * Can be implemented readily in a manner not covered by
            patents, and hence can be practiced freely.

      The data format defined by this specification does not attempt to
      allow random access to compressed data.

   1.2. Intended audience

      This specification is intended for use by implementors of software
      to compress data into zlib format and/or decompress data from zlib
      format.

      The text of the specification assumes a basic background in
      programming at the level of bits and other primitive data
      representations.

   1.3. Scope

      The specification specifies a compressed data format that can be
      used for in-memory compression of a sequence of arbitrary bytes.

   1.4. Compliance

      Unless otherwise indicated below, a compliant decompressor must be
      able to accept and decompress any data set that conforms to all
      the specifications presented here; a compliant compressor must
      produce data sets that conform to all the specifications presented
      here.

   1.5.  Definitions of terms and conventions used

      byte: 8 bits stored or transmitted as a unit (same as an octet).
      (For this specification, a byte is exactly 8 bits, even on
      machines which store a character on a number of bits different
      from 8.) See below, for the numbering of bits within a byte.

   1.6. Changes from previous versions

      Version 3.1 was the first public release of this specification.
      In version 3.2, some terminology was changed and the Adler-32
      sample code was rewritten for clarity.  In version 3.3, the
      support for a preset dictionary was introduced, and the
      specification was converted to RFC style.

2. Detailed specification

   2.1. Overall conventions

      In the diagrams below, a box like this:

         +---+
         |   | <-- the vertical bars might be missing
         +---+

      represents one byte; a box like this:

         +==============+
         |              |
         +==============+

      represents a variable number of bytes.

      Bytes stored within a computer do not have a "bit order", since
      they are always treated as a unit.  However, a byte considered as
      an integer between 0 and 255 does have a most- and least-
      significant bit, and since we write numbers with the most-
      significant digit on the left, we also write bytes with the most-
      significant bit on the left.  In the diagrams below, we number the
      bits of a byte so that bit 0 is the least-significant bit, i.e.,
      the bits are numbered:

         +--------+
         |76543210|
         +--------+

      Within a computer, a number may occupy multiple bytes.  All
      multi-byte numbers in the format described here are stored with
      the MOST-significant byte first (at the lower memory address).
      For example, the decimal number 520 is stored as:

             0     1
         +--------+--------+
         |00000010|00001000|
         +--------+--------+
          ^        ^
          |        |
          |        + less significant byte = 8
          + more significant byte = 2 x 256

   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.

      CMF (Compression Method and flags)
         This byte is divided into a 4-bit compression method and a 4-
         bit information field depending on the compression method.

            bits 0 to 3  CM     Compression method
            bits 4 to 7  CINFO  Compression info

      CM (Compression method)
         This identifies the compression method used in the file. CM = 8
         denotes the "deflate" compression method with a window size up
         to 32K.  This is the method used by gzip and PNG (see
         references [1] and [2] in Chapter 3, below, for the reference
         documents).  CM = 15 is reserved.  It might be used in a future
         version of this specification to indicate the presence of an
         extra field before the compressed data.

      CINFO (Compression info)
         For CM = 8, CINFO is the base-2 logarithm of the LZ77 window
         size, minus eight (CINFO=7 indicates a 32K window size). Values
         of CINFO above 7 are not allowed in this version of the
         specification.  CINFO is not defined in this specification for
         CM not equal to 8.

      FLG (FLaGs)
         This flag byte is divided as follows:

            bits 0 to 4  FCHECK  (check bits for CMF and FLG)
            bit  5       FDICT   (preset dictionary)
            bits 6 to 7  FLEVEL  (compression level)

         The FCHECK value must be such that CMF and FLG, when viewed as
         a 16-bit unsigned integer stored in MSB order (CMF*256 + FLG),
         is a multiple of 31.

      FDICT (Preset dictionary)
         If FDICT is set, a DICT dictionary identifier is present
         immediately after the FLG byte. The dictionary is a sequence of
         bytes which are initially fed to the compressor without
         producing any compressed output. DICT is the Adler-32 checksum
         of this sequence of bytes (see the definition of ADLER32
         below).  The decompressor can use this identifier to determine
         which dictionary has been used by the compressor.

      FLEVEL (Compression level)
         These flags are available for use by specific compression
         methods.  The "deflate" method (CM = 8) sets these flags as
         follows:

            0 - compressor used fastest algorithm
            1 - compressor used fast algorithm
            2 - compressor used default algorithm
            3 - compressor used maximum compression, slowest algorithm

         The information in FLEVEL is not needed for decompression; it
         is there to indicate if recompression might be worthwhile.

      compressed data
         For compression method 8, the compressed data is stored in the
         deflate compressed data format as described in the document
         "DEFLATE Compressed Data Format Specification" by L. Peter
         Deutsch. (See reference [3] in Chapter 3, below)

         Other compressed data formats are not specified in this version
         of the zlib specification.

      ADLER32 (Adler-32 checksum)
         This contains a checksum value of the uncompressed data
         (excluding any dictionary data) computed according to Adler-32
         algorithm. This algorithm is a 32-bit extension and improvement
         of the Fletcher algorithm, used in the ITU-T X.224 / ISO 8073
         standard. See references [4] and [5] in Chapter 3, below)

         Adler-32 is composed of two sums accumulated per byte: s1 is
         the sum of all bytes, s2 is the sum of all s1 values. Both sums
         are done modulo 65521. s1 is initialized to 1, s2 to zero.  The
         Adler-32 checksum is stored as s2*65536 + s1 in most-
         significant-byte first (network) order.

   2.3. Compliance

      A compliant compressor must produce streams with correct CMF, FLG
      and ADLER32, but need not support preset dictionaries.  When the
      zlib data format is used as part of another standard data format,
      the compressor may use only preset dictionaries that are specified
      by this other data format.  If this other format does not use the
      preset dictionary feature, the compressor must not set the FDICT
      flag.

      A compliant decompressor must check CMF, FLG, and ADLER32, and
      provide an error indication if any of these have incorrect values.
      A compliant decompressor must give an error indication if CM is
      not one of the values defined in this specification (only the
      value 8 is permitted in this version), since another value could
      indicate the presence of new features that would cause subsequent
      data to be interpreted incorrectly.  A compliant decompressor must
      give an error indication if FDICT is set and DICTID is not the
      identifier of a known preset dictionary.  A decompressor may
      ignore FLEVEL and still be compliant.  When the zlib data format
      is being used as a part of another standard format, a compliant
      decompressor must support all the preset dictionaries specified by
      the other format. When the other format does not use the preset
      dictionary feature, a compliant decompressor must reject any
      stream in which the FDICT flag is set.

3. References

   [1] Deutsch, L.P.,"GZIP Compressed Data Format Specification",
       available in ftp://ftp.uu.net/pub/archiving/zip/doc/

   [2] Thomas Boutell, "PNG (Portable Network Graphics) specification",
       available in ftp://ftp.uu.net/graphics/png/documents/

   [3] Deutsch, L.P.,"DEFLATE Compressed Data Format Specification",
       available in ftp://ftp.uu.net/pub/archiving/zip/doc/

   [4] Fletcher, J. G., "An Arithmetic Checksum for Serial
       Transmissions," IEEE Transactions on Communications, Vol. COM-30,
       No. 1, January 1982, pp. 247-252.

   [5] ITU-T Recommendation X.224, Annex D, "Checksum Algorithms,"
       November, 1993, pp. 144, 145. (Available from
gopher://info.itu.ch). ITU-T X.244 is also the same as ISO 8073.

4. Source code

   Source code for a C language implementation of a "zlib" compliant
   library is available at ftp://ftp.uu.net/pub/archiving/zip/zlib/.

5. Security Considerations

   A decoder that fails to check the ADLER32 checksum value may be
   subject to undetected data corruption.

6. Acknowledgements

   Trademarks cited in this document are the property of their
   respective owners.

   Jean-Loup Gailly and Mark Adler designed the zlib format and wrote
   the related software described in this specification.  Glenn
   Randers-Pehrson converted this document to RFC and HTML format.

7. Authors' Addresses

   L. Peter Deutsch
   Aladdin Enterprises
   203 Santa Margarita Ave.
   Menlo Park, CA 94025

   Phone: (415) 322-0103 (AM only)
   FAX:   (415) 322-1734
   EMail: <ghost@aladdin.com>

   Jean-Loup Gailly

   EMail: <gzip@prep.ai.mit.edu>

   Questions about the technical content of this specification can be
   sent by email to

   Jean-Loup Gailly <gzip@prep.ai.mit.edu> and
   Mark Adler <madler@alumni.caltech.edu>

   Editorial comments on this specification can be sent by email to

   L. Peter Deutsch <ghost@aladdin.com> and
   Glenn Randers-Pehrson <randeg@alumni.rpi.edu>

8. Appendix: Rationale

   8.1. Preset dictionaries

      A preset dictionary is specially useful to compress short input
      sequences. The compressor can take advantage of the dictionary
      context to encode the input in a more compact manner. The
      decompressor can be initialized with the appropriate context by
      virtually decompressing a compressed version of the dictionary
      without producing any output. However for certain compression
      algorithms such as the deflate algorithm this operation can be
      achieved without actually performing any decompression.

      The compressor and the decompressor must use exactly the same
      dictionary. The dictionary may be fixed or may be chosen among a
      certain number of predefined dictionaries, according to the kind
      of input data. The decompressor can determine which dictionary has
      been chosen by the compressor by checking the dictionary
      identifier. This document does not specify the contents of
      predefined dictionaries, since the optimal dictionaries are
      application specific. Standard data formats using this feature of
      the zlib specification must precisely define the allowed
      dictionaries.

   8.2. The Adler-32 algorithm

      The Adler-32 algorithm is much faster than the CRC32 algorithm yet
      still provides an extremely low probability of undetected errors.

      The modulo on unsigned long accumulators can be delayed for 5552
      bytes, so the modulo operation time is negligible.  If the bytes
      are a, b, c, the second sum is 3a + 2b + c + 3, and so is position
      and order sensitive, unlike the first sum, which is just a
      checksum.  That 65521 is prime is important to avoid a possible
      large class of two-byte errors that leave the check unchanged.
      (The Fletcher checksum uses 255, which is not prime and which also
      makes the Fletcher check insensitive to single byte changes 0 <->
      255.)

      The sum s1 is initialized to 1 instead of zero to make the length
      of the sequence part of s2, so that the length does not have to be
      checked separately. (Any sequence of zeroes has a Fletcher
      checksum of zero.)

9. Appendix: Sample code

   The following C code computes the Adler-32 checksum of a data buffer.
   It is written for clarity, not for speed.  The sample code is in the
   ANSI C programming language. Non C users may find it easier to read
   with these hints:

      &      Bitwise AND operator.
      >>     Bitwise right shift operator. When applied to an
             unsigned quantity, as here, right shift inserts zero bit(s)
             at the left.
      <<     Bitwise left shift operator. Left shift inserts zero
             bit(s) at the right.
      ++     "n++" increments the variable n.
      %      modulo operator: a % b is the remainder of a divided by b.

      #define BASE 65521 /* largest prime smaller than 65536 */

      /*
         Update a running Adler-32 checksum with the bytes buf[0..len-1]
       and return the updated checksum. The Adler-32 checksum should be
       initialized to 1.

       Usage example:

         unsigned long adler = 1L;

         while (read_buffer(buffer, length) != EOF) {
           adler = update_adler32(adler, buffer, length);
         }
         if (adler != original_adler) error();
      */
      unsigned long update_adler32(unsigned long adler,
         unsigned char *buf, int len)
      {
        unsigned long s1 = adler & 0xffff;
        unsigned long s2 = (adler >> 16) & 0xffff;
        int n;

        for (n = 0; n < len; n++) {
          s1 = (s1 + buf[n]) % BASE;
          s2 = (s2 + s1)     % BASE;
        }
        return (s2 << 16) + s1;
      }

      /* Return the adler32 of the bytes buf[0..len-1] */

      unsigned long adler32(unsigned char *buf, int len)
      {
        return update_adler32(1L, buf, len);
      }

swo 2006-08-18 14:40 发表评论