Managing Gigabytes--文本压缩

简介:

开门见山,文本压缩可以归纳为两大类, 符号方法和字典方法, 下面分别介绍下:


1)符号方法,symbolwise method
普通编码方式是每个字符都采用相同位数编码, 比如asc码, 每个字符都是8位编码。
那么现在要压缩,就是要用更少的位数来表示字符。显而易见, 我们只须用较小的位数来表示高概率字符, 用较长的位数来表示低概率字符,这样平均下来就可以实现压缩。


那么这里面就有两个点:
a)怎么来确定每个待编码字符的概率,这就是概率模型问题。
所谓概率模型就是为编码器提供的概率分布函数,我们必须保证编码器,和解码器使用相同的模型, 不然解出来的就不对了。
那么对于一个符号的编码位数是有个下限的, 和这个符合的信息量I(s)相关。
I(s)= -logPr[s] (Pr[s]就是s符合出现的概率)
所以对于”掷硬币面向上“这个事实,至少要用-log(1/2)=1位来编码。
那么对于字母表中每个符合的平均信息量称为”概率分布的熵(entropy)“, H = sum(Pr[s]*I[s])
假定符合以假设的概率值独立出现,H为压缩下限。即这是个理论极值,实际上不可能达到。
这也就是Claude Shannon著名的编码原理。

回到模型,可分为每个字符都当独立的符号来处理的0阶模型和仅考虑有限个前驱符号的m阶有限上下文模型。 
也可分为静态模型, 半静态模型, 和自适应模型。
静态模型就是不考虑正在编码的文本,只使用固定的模型,这个模型就适用于文本模式相对固定的任务。
半静态模型就先为要压缩的文件生成模型, 发送给解压方, 这个方法需要遍历两遍被压缩的文档, 所以这个solution明显不太好。
所以比较流行的是自适应模型,adaptive modeling,即以平缓的概率模型开始, 随着遇到的符号变多, 不断的调整。
自适应模型往往要解决零频问题,这个问题解决方法很多, 最简单的是默认每个字符在刚开始时已出现过一次。
这种模型的缺点是不能对文本进行随机访问, 必须从文本的开头开始解码,因为我们必须保证编码和解码时的context是相同的。

对于怎么建立符号概率模型, 也是有很多研究, 比如部分匹配模型(Prediction by Partial Matching, PPM)依据以前的字符做出预测, 动态马尔可夫模型基于有限状态机。
这些模型就不详细描述了, 有兴趣可以参看相关文献。

b)知道待编码字符的概率,怎么给它分配合适的编码, 这就是编码算法的问题。

哈夫曼编码
介绍编码算法当然先来看看哈夫曼编码, 这个号称是作者在研究生时为了避免参加科目考试而想出的算法,很简单也很高效。再一次对美国的教育环境表示深深的敬意和向往。
这类算法基本想法就是给高概率字符分配较少位数的编码。
这就有个问题, 如果每个字符的编码位数不一样, 那么我们怎么知道后一个字符的编码位数,肯定不能用个len去指定。
哈夫曼的方法是解决编码前缀的歧义性(ambiguity), 即前缀编码,就是说每个编码的前缀都是不同的
那么怎么去产生编码和怎么去解码呢?
哈夫曼树,通过哈夫曼树,从下到上进行编码, 从上到下进行解码。具体怎么构建哈夫曼树, 就不具体说了, 很简单。
再一次感叹此算法构思的巧妙和简单。
对于静态的概率分布, 哈夫曼算法是很好的, 但对于自适应模型,哈夫曼算法会耗费较多的内存或时间。
因为自适应模型在同一时间会使用许多不同的概率分布,依赖于被编码文本的上下文的不同。那么这样就要同时建立多颗哈夫曼树。

 

算术编码

那么对于自适应模型而言算术编码更受欢迎。
算术编码相对比较复杂,不过显著的优势是算术编码可以用低于一位的编码来表示高概率字符, 而哈夫曼编码对于每个字符至少要用一位来编码。
由于算术编码包含了各种不同的概率分布, 所以比较适合自适应模型。
但对于静态模型,还是哈夫曼编码要快许多。

算术编码的基本思想就是, 在编码过程中, 随着各个字符的出现不断缩小概率区间, 高概率字符不会大幅地缩短区间,而低概率字符会导致产生一个小的多的‘下一个’区间。
算术编码只有当编码完成时,才会一次性输出编码,编码值就是在最终的概率区间内任意选取一个值,区间越小,表示这个值所用的位数越多。
不好理解,就举个例子:
对于只有3个字符的字符集a,b,c, 对bccb进行编码
为解决零频问题, 开始假设a,b,c个出现过一次
编码前概率区间为[0,1],此时abc的概率都是1/3,所以abc各占概率区间的1/3, 如b的概率区间为[0.33, 0,66]
开始编码......
第一个字符b,所以概率区间缩短为[0.33, 0,66]
此时a:b:c的比例为1:2:1,所以各个字符的概率区间变为a = [0.333,0.416], b = [0.416, 0.583], c = [0.583, 0.666]
第二个字符c,所以概率区间缩短为[0.583, 0.666]
此时a:b:c的比例为1:2:2,所以各个字符的概率区间变为a = [0.583,0.600], b = [0.600, 0.633], c = [0.633, 0.666]
第三个字符c,所以概率区间缩短为[0.633, 0.666]
此时a:b:c的比例为1:2:3,。。。。。。
最终概率区间缩小至[0.639, 0.650]
所以0.64就可以作为bccb的编码。

而解码的过程就是照着编码的过程重做一遍即可,
解码前概率区间为[0,1],此时abc的概率都是1/3,所以abc各占概率区间的1/3, 如b的概率区间为[0.33, 0,66]
所以0.64落在了b的概率区间内, 第一个字符为b
概率区间缩短为[0.33, 0,66], 此时a:b:c的比例为1:2:1,所以各个字符的概率区间变为a = [0.333,0.416], b = [0.416, 0.583], c = [0.583, 0.666]
所以0.64落在了c的概率区间内, 第二个字符为c
。。。。。。最终完成解码。

区间中的数需要的多少位来表示和区间长度的负对数成正比。而最终的区间长度是已编码符合概率值的乘积(显而易见)。
而log(AB)= log(A)+log(B), 所以最终的区间长度的对数就等于所有已编码符号单独概率值的对数的和。所以具有概率Pr[s]的符号s对输出编码的贡献是-logPr[s], 与符号信息量相同。
所以算术编码的输出位数接近最优。


2)字典方法,dictionary method
字典模式很好理解, 用字典里面的码字来替换原文,如果这个码字比原文的位数少,那么就实现了压缩, 如果你的字典是独有的, 不公开的, 那么就实现了加密。
那么为了实现压缩, 就要基于词或短语进行编码, 基于字符压缩效果肯定不好, 那么如果这个字典是静态的,因为各个领域的词和短语都不一样的, 所以不可能适用于所有文本。
也有半静态的,就是每次对要压缩的文本生成一个字典,这个方法肯定也不好。
所以就有自适应的字典方案(adaptive dictionary scheme), 这个就有技术含量了怎么产生自适应的字典了。
当然牛人是很多的,Ziv和Lempel发明了LZ77和LZ88两种方法。
牛人想出来的方法都是很简单,很好用的, 这个也不例外,基本原理就是文本的子串被指向其以前出现之处的指针所替换。
说白了,就是字典码书就是文本本身, 码字就是指针。个人感觉,在发明这个方法时, 作者可能并没有想到什么基于字典模式的方法,应该是后面的学者把它归到这类了。
我们就以LZ77来了解下这个方法,
LZ77的输出码是一系列三元组,(a,b,c), a表示往前回溯多远, b表示短语多长, c表示要输入的下一个字符。
为什么要有c项,是为没有出现过的字符准备的, 这个设计照顾了新字符引进的需要。
以abaabab为例,输出码为:
(0,0,a) (0,0,b) (2,1,a) (3,2,b)
这个方法需要在之前的文本中找到最大匹配窗口, 这个不能线性查找, 一般采用散列表, 或二分查找树来实现。

著名的Gzip就是这个算法的一个变体,
Gzip用hash table来定位之前出现的字符串, 用3个连续的字符作为hash键值,链表中记录了这三个字符在窗口中出现的位置信息。
出于效率的考虑,限制了链表的长度, 其实也没有必要记录过远的位置, 记较近的几个位置比较合理。
Gzip比较有意思的是,对指针的偏移值也做了哈夫曼编码,较常用的值用较少的编码。同时对字符串匹配长度值, 也采用哈夫曼编码。
当之前没有发现匹配的时候, 传递一个原始字符(raw character),有意思的是这个原始字符和字符串匹配长度值公用同一个编码。
也就是说第二项有可能是个字符串匹配长度值, 也有可能是个原始字符,反正前缀编码, 也不冲突, 用心良苦都是为了压缩。


本文章摘自博客园,原文发布日期:2011-07-04
目录
相关文章
完美简单永久解决WEKA中导入arrf文件(包含中文字符)出现“unable to determine structure as arff...”错误
完美简单永久解决WEKA中导入arrf文件(包含中文字符)出现“unable to determine structure as arff...”错误
329 0
完美简单永久解决WEKA中导入arrf文件(包含中文字符)出现“unable to determine structure as arff...”错误
|
6月前
|
测试技术
【LaTex】10 从md文件导入\导出word (因为:Typora-版本过高不能转换word 报错:Unknown option --atx-headers. )
【LaTex】10 从md文件导入\导出word (因为:Typora-版本过高不能转换word 报错:Unknown option --atx-headers. )
167 7
|
存储 XML 定位技术
[✔️]cocos2dx Tiledmap性能优化分析:layer data建议使用压缩格式gzip/zlib
[✔️]cocos2dx Tiledmap性能优化分析:layer data建议使用压缩格式gzip/zlib
225 0
|
存储
RLE格式分割标注文件格式转换【以Airbus Ship Detection Challenge为例】
RLE格式分割标注文件格式转换【以Airbus Ship Detection Challenge为例】
232 0
RLE格式分割标注文件格式转换【以Airbus Ship Detection Challenge为例】
|
编解码
Compressor v4.6.3 中文激活版
Compressor与Final Cut Pro紧密集成,可添加自定义输出设置,分布式编码和广泛的交付功能。它支持360°视频,HDR,HEVC和MXF输出,是导出Final Cut Pro项目最强大,最灵活的方式。
Compressor  v4.6.3 中文激活版
|
存储 定位技术 数据库
如何区分Shapefile,Coverage,Geodatabase
如何区分Shapefile,Coverage,Geodatabase(转载) 在过去20年中,矢量数据模型是GIS中变化最大的方面,例如,ESRI公司所开发每种新软件包都对应一种新的矢量数据模型,Arc/Info对应Coverage,ArcView对应Shapefile,ArcGIS对应Geodatabase。
1484 0
PAT (Basic Level) Practice (中文)- 1078 字符串压缩与解压(20 分)
PAT (Basic Level) Practice (中文)- 1078 字符串压缩与解压(20 分)
98 0
|
存储 缓存 数据库
Confluence 6 从 WIKI 标记整合到基于 XHTML 的存储格式
如果你现在正在将 Confluence 从一个老的版本升级到 Confluence 4.0 或者更新的版本 (例如从 Confluence 3.5.x 或者更老的版本),在升级的过程中一个内容整合过程也会进行。
1100 0
|
Web App开发 API Android开发
Chrome 图片解码与 Image Decoding Hint
我在之前的一篇文章[Chrome 图片解码与 Image.decode API][1],说明了为什么图片解码可能会导致非合成器动画的阻塞和如何使用 Image.decode API 来避免动画的阻塞。不过虽然 Image.decode API 给页端提供了更灵活的控制图片解码时机的能力,但是使用起来较为复杂,也容易误用,而 Image Decoding Hint 属性则更简单,容易使用,同时也满足
3318 0