[老文章搬家] 关于 Huffman 编码

按:去年接手一个项目,涉及到一个一个叫做Mxpeg的非主流视频编码格式,编解码器是厂商以源代码形式提供的,但是可能代码写的不算健壮,以至于我们tcp直连设备很正常,但是经过一个UDP数据分发服务器之后,在偶尔有丢包的情况下解码器会偶发崩溃,翻了翻他们的代码觉得可能问题出在Huffman这一块。水平有限也没有看太懂他们的源码,而且我也不是科班出身当时对Huffman编码算法只是知道这么个名字,还好服务端软件那边做了修改,解决了丢包的问题。在回家过年的火车上想起这件事,阅读了一些关于Huffman编码的资料,算是对这个东西有了些通俗的认识,记在这里以防遗忘或者智力萎缩。

Huffman编码,是一种压缩编码算法,它利用“出现频率最大的信息应该用最短的码元来表示”这一原理对信息进行压缩。使用这种原理的编码算法统称“熵编码”。为了解释清楚Huffman编码的原理,我得先定义一些概念:

信息(Message)
含有某种语义的单元。比如拿常用的文本传输举例子,‘a‘就是个信息,它表示字母a,或者不定冠词a,又或者A片。总之它有一个预先定义的语义。

信息序列(Message Sequence)
信息排列组合组成的串。就像英文一样,光有字母是不行的,因为字母只有26个,但是单词有几百万个,所以要用字母的排列组合来构成单词,比如apple,再比如<a href="http: baike.baidu.com="" view="" 657095.htm?source="www.willlong.com"">这个单词。然后我们还用单词加空格组成句子来表达更复杂的意思(信息),比如"son of bitch",这也是一个序列

符号(Symbol)
我们用电子设备来传输信息,但是设备不认识信息,只认识电平,1和0。0和1被叫作符号。
PS: 据说中国有个教授研究能表达3个状态的量子逻辑,成果还挺厉害的,不知道靠谱否。

符号序列(Symbol Sequence)
同样,光有符号也是不行的,因为符号只有两个(0,1),消息却有很多,比如字母有26个,所以要用符号的排列组合来表示信息,继而表示出信息序列。比如你去内存里看C字符串"son of bitch",就是0和1组成的符号序列。

编码(Message Code)
对于一个信息/信息序列M,用一个符号序列C来表示,在这个映射中,我们称C为M的编码/编码序列(同时,我们不妨把这个映射的过程叫做编码,不会产生歧义)。

有了上面这些概念,我们很容易推知,在单位符号传输时间恒定的情况下,传输同样的消息,肯定是生成的编码序列越短,花费的时间就越短。那么为了提高传输效率,我们有必要找到一种编码算法,使得一个有限长信息序列编码生成的符号序列尽可能的短,大神Shannon称之为“最小冗余编码(minimum-redundancy code)”——事实上Shannon的定义和我这里不太一样,我这是山寨解释。另外为了解码需要,一个可行的编码算法还要符合两个基本限制

1.不同的信息不能编出同样的码,这个是天经地义的,不需要解释。

2.不需要额外的说明就能确定信息编码之间的界限,从这个条件引申,我们可以将其解释为不能有一个编码C1是另一个编码C2的前k位(也叫前缀k——kth prefix),比如01表示a,011表示b就是不合法的,因为给定符号序列011,如果没有额外说明,没法确定是a加上一个1还是b。虽然没有什么逻辑联系,但是看到第二条我就想到为什么大家都喜欢配置文件而不是xml,尤其是手写解析器的情况下。

进一步考虑,假设待编码序列中的信息空间有N种取值,用1到N表示,P(n)为消息n出现的频率(因为是已知序列,所以是频率而不是概率),L(n)为消息n编码后的长度,C(n)为消息n的编码。我们可以得到另外一些结论,首先,有:
    如果 P(1)<=P(2)<=...<=P(N)
    那么 L(1)>=L(2)>=...>=L(N)

也就是说,频率小的信息编码之后不能比频率大的信息更短,因为如果不这样的话,我们只要简单的互换两个信息的编码,就能减小编码序列的长度。然后我们再考虑L(N-1)和L(N),假设L(N-1)=4,那L(N)是几?显然根据刚得出的结论L(N)不能小于4,那能不能是比4大,比如5?如果真等于5的话,根据前面的限制2,C(N)的前4位必然没有在编码空间中出现过,那第5位还有必要么?显然没有了,我读到第4位就知道一定是N了,还要第5位干什么?L(N)不能比4小,也不能比4大,那只能是4,也就是说,结论是L(N)=L(N-1)。

时间: 2024-11-08 23:25:36

[老文章搬家] 关于 Huffman 编码的相关文章

[老文章搬家] 关于屏蔽优酷视频广告的一个方法

11年的老文章,稳重那个插件让我爽了很久,不过后来就买会员了.代码我已经遗失了,不过无所谓,思路还是明确的,我后来在 Chrome 上测试过,一样能用. ==== 正文 ==== 需求:优酷最近搞了一个广告防屏蔽,导致修改host的方法不能用了.我们需要一个新方法来绕过这个防屏蔽机制. 基本思想:新版的优酷flv player下载不到广告会罢工30秒,既然不能屏蔽广告,那我们就替换广告文件,用一个假广告文件让flv player播放. 实现:首先抓一下包,或者用Fiddle2拦截请求,会发现优酷

[老文章搬家] 插件化软件设计的头疼问题以及可能的解决思路

11年的文章,当时在做系统集成,实际上当时的思路到现在我还在琢磨,只不过后来就不做系统集成了,也一直没机会深入下去解决这个问题. ==== 正文 ==== 一直以来做的项目中有很大一部分工作量都是有关集成设备的工作.为了方便扩展以支持更多厂家的设备,但在这个过程中遇到了非常头疼的问题,在这里我把问题描述一下,欢迎大家来探讨. 问题描述:所谓设备集成,多数情况下可以简化为SDK的集成(这个比较方便,有时候我们宁愿直接集成协议,但是厂家有厂家的考虑).针对这种情况,我们的系统采用了比较典型的插件式设

[老文章搬家] [翻译] 深入解析win32 crt 调试堆

09 年翻译的东西. 原文见:  http://www.nobugs.org/developer/win32/debug_crt_heap.html 在DeviceStudio的Debug编译模式下, crt中的堆内存分配操作----包括malloc()和free()----使用一个特殊的, 便于调试的版本, 我们称之为crt debug堆(译注: 下面简称CDH). 相比于电光火石(译注: 原文blazingly, 我想不出更确切的说法)的运行效率, 调试版本更关注对于堆错误的定位, 它通过以

Jcompress: 一款基于huffman编码和最小堆的压缩、解压缩小程序

前言 最近基于huffman编码和最小堆排序算法实现了一个压缩.解压缩的小程序.其源代码已经上传到github上面: Jcompress下载地址 .在本人的github上面有一个叫Utility的repository,该分类下面有一个名为Jcompress的目录便是本文所述的压缩.解压缩小程序的源代码.后续会在Utility下面增加其他一些实用的小程序,比如基于socket的文件断点下载小程序等等.如果你读了此文觉得还不错,不防给笔者的github点个star, 哈哈.在正式介绍Jcompres

Huffman编码学习笔记

主要是在学算导,觉得算导译到中国真是中国人民的福音. 一.编码 编码就是选择有意义的01串,令其首尾相接组成文本.我们并非可以随便挑选01串,原因在于它们是首尾相接的,这为我们识别造成了一些困难.比如说我们不能在文本000000中分清字符00与000. 一般我们使用的方式是定长字符:但更好的方式是前缀码,算导中写道"虽然我们这里不会证明,但与任何字符编码相比,前缀码确实可以保证达到最优数据压缩率.",这显然是一个flag,将来一定会有比前缀码更好的编码方式的. 二.Huffman编码便

Huffman 编码压缩算法

前两天发布那个rsync算法后,想看看数据压缩的算法,知道一个经典的压缩算法Huffman算法.相信大家应该听说过 David Huffman 和他的压缩算法—— Huffman Code,一种通过字符出现频率,Priority Queue,和二叉树来进行的一种压缩算法,这种二叉树又叫Huffman二叉树 —— 一种带权重的树.从学校毕业很长时间的我忘了这个算法,但是网上查了一下,中文社区内好像没有把这个算法说得很清楚的文章,尤其是树的构造,而正好看到一篇国外的文章<A Simple Examp

Huffman编码实现压缩解压缩

这是我们的课程中布置的作业,找一些资料将作业完成,顺便将其写到博客,以后看起来也方便. 原理介绍 什么是Huffman压缩 Huffman( 哈夫曼 ) 算法在上世纪五十年代初提出来了,它是一种无损压缩方法,在压缩过程中不会丢失信息熵,而且可以证明 Huffman 算法在无损压缩算法中是最优的. Huffman 原理简单,实现起来也不困难,在现在的主流压缩软件得到了广泛的应用.对应用程序.重要资料等绝对不允许信息丢失的压缩场合, Huffman 算法是非常好的选择. 怎么实现Huffman压缩

基于Huffman编码的压缩软件的Python实现

哈夫曼编码是利用贪心算法进行文本压缩的算法,其算法思想是首先统计文件中各字符出现的次数,保存到数组中,然后将各字符按照次数升序排序,挑选次数最小的两个元素进行连结形成子树,子树的次数等于两节点的次数之和,接着把两个元素从数组删除,将子树放入数组,重新排序,重复以上步骤.为了解压,在压缩时首先往文件中填入huffman编码的映射表的长度,该表的序列化字符串,编码字符串分组后最后一组的长度(编码后字符串长度模上分组长度),最后再填充编码后的字符串.本算法中以一个字节,8位作为分组长度,将编码后二进制

基于二叉树和数组实现限制长度的最优Huffman编码

具体介绍详见上篇博客:基于二叉树和双向链表实现限制长度的最优Huffman编码 基于数组和基于链表的实现方式在效率上有明显区别: 编码256个符号,符号权重为1...256,限制长度为16,循环编码1w次,Release模式下.基于链表的耗时为8972ms,基于数组的耗时为1793ms,速度是链表实现方式的5倍. 详细代码例如以下: //Reference:A fast algorithm for optimal length-limited Huffman codes.pdf,http://p