初始分配一个[0,1)区间，按信源输出字符的概率对其进行划分，使每一个字符都对应一个唯一的区间。编码时，每次把当前字符的区间分配为码字，重复下去，最终得到一个区间就是该字符串的编码。解码时，查看码字区间属于哪个字符，依次迭代直到迭代出与码字相同的区间即为结束。即为：
high(n+1) = low(n+1) + range x high_range(x)
low(n+1) = low(n+1) + range x low_range(x)
其中，range = high(n) - low(n)，high、low_range(x)为当前字符x的概率区间上下界。
实际应用时，只保存下界作为码字即可。
此图来自开头所提到的书籍

算术编码与移位运算

**一知半解，此处存疑。**目的是为了简化算术编码过程中的乘法运算，从而提高速度。疑惑的点在于：移位的位数为何是动态的，是怎么决定的？

自适应算术编码

与自适应霍夫曼编码相似，动态调整每个字符的概率。用一棵平衡二叉树来保存字符的频数来提高效率。

四、字典编码

4.1 基本原理

静态字典：需要预设字典项，对一些专用的场景比较适合，比如源程序代码等等。但当字典查找成功率低到某一个阈值时，就会出现反扩张的现象。
自适应字典：从一个空或小字典开始，从输入流读到新字就输出新字并加入字典，并且删除旧字。删除旧字是因为大字典搜索速度太慢。如此便形成了一个循环：读入并解析成短语，在字典中查找，找到就输出码字，否则加入字典并输出原字，最后检查看是否需要删除一个旧字。这样做的好处是：只有字符串操作无数值运算；译码简单。译码过程，与编码一样从动态调整字典，只要规则一样，最后的解压结果便也是一样的，并且不需要解析输入数据，不需要匹配字符串，只需要查找索引，简单高效，是不对称的。

4.2 LZ77

分两个区域，左边的缓冲区为当前的字典，右边的滑动窗口为即将要压缩的字符。原理见下图：
在这里插入图片描述
声明：上面这张图是来自另一篇博客：https://blog.csdn.net/qq_23084801/article/details/77496955，我看的这本书没图，纯文字，无力吐槽。
若从右往左搜索缓冲区没有匹配到字符串，则输出（0，0，当前字符），这就是必须要有第三部分的原因。一般在压缩器刚开始工作时，（0，0，）很容易出现。
LZ77也是非对称压缩技术，解压简单，因此多应用于一次压缩多次解压的场合。

4.3 LZ78

压缩原理如下图：
在这里插入图片描述

解压时可以动态地恢复字典，如下图例：
声明：以上三图均来自博客：https://www.cnblogs.com/en-heng/p/6283282.html
与LZ77不同，LZ78的字典不删除字典项。LZ78的字典采用树形结构保存，且是多叉树，如8位字符则每个节点最多可以有2^8个子节点。由于不会删除字典项，因此不涉及空间的回收，简化了存储空间的管理及字符串的搜索。但树的大小可能会急剧膨胀，导致空间耗尽。

4.4 LZW

算是LZ78的改进版。最主要的区别在于它去掉了LZ78的第二个字段，这是因为它将所有的单字符提前预装到字典中了，所以下一个输入字符总是能被找到。剩下的过程显然容易推得，其解码过程与编码一样。
LZW的字典结构显然也是一棵多叉树，此书中介绍说为了减少不必要的子节点指针的空间预分配，LZW的多叉树采用的是数组结构，保存的是母节点指针。母节点采用哈希映射的方法来寻找子节点。我猜Zstd在这里肯定是有优化的。

存疑点

率失真定理
算术编码与移位运算
基于LZ77的LZSS，Google的Snappy；基于LZ78的LZW，Facebook的Zstd（基于FSE）

未完待续…

dc199706 发布了10 篇原创文章 · 获赞 0 · 访问量 444 私信关注

标签：编码,概率,字符,压缩,笔记,信源,调研,字典
来源： https://blog.csdn.net/dc199706/article/details/104210676