C++ 文本压缩过程中概率表的存储

我正在做一个项目，我比较了不同类型的文本压缩方法，如哈夫曼和静态和自适应形式的算术。我使用文本中每个字母的出现次数为这两种情况制作了一个概率表。现在，对于自适应形式，接收器不需要概率表，但是对于静态形式，我们也需要将概率表发送给接收器，以便对消息进行解码。现在，表的这种存储将需要一些额外的位，在比较时应该考虑这些位

所以我的问题是：

存储概率表（在文件中）的最佳解决方案是什么

这样做所需的最小位数是多少？（我知道这取决于文本，但是否有办法找到存储表所需的最小位）

---

非常感谢。

传递0阶表（即，只有一个标记且没有前瞻性的表）的一种常见方法是，简单地以递减的频率顺序预加所有可能的符号。概率通常不需要存储，因为编码只需要有序的符号集，而不需要它们的实际概率

---

对于编码8位令牌的压缩方案，并且假设所有令牌至少在理论上是可能的，这将意味着256字节的开销。对于仅可能存在字节子集的情况（例如，仅由大写字母和数字组成的消息），表当然更小。

根据概率，您可以为符号指定代码长度。为了创建代码，接收者需要一个元组列表：（位计数，符号计数），然后是按分配给代码的顺序排列的符号。现在，您可以对这些代码进行编码

对符号列表进行编码可以利用这样一个事实，即对于传输的每个符号，后续符号所需的位数都会下降。在早期指定使用（比如）8位符号子集的选项在这里会有所帮助。随着码字越来越长，对一段符号进行编码可能会很方便，而不是传输每一段符号——也许可以用一种方式来表达一段少几个符号的符号，其中“洞”可以用一些位数表示，这取决于段的长度——或者开始符号、长度和位向量（请注意，表示长度的位数取决于起始符号和剩余符号的数量，不需要为范围内的第一个和最后一个发送位！）

哈夫曼编码表的编码本身就是一个完整的游戏。那么对于短消息来说，该表可能是一个严重的开销……在这种情况下，（少量）常用表可能会提供更好的压缩

您还可以对每个符号的代码长度使用哈夫曼编码，并按符号顺序发送。带有哈夫曼的重复计数机制可以在这里提供帮助，以及跳过未使用符号（即代码长度为零的符号）运行的方法。当然，您可以添加一级表来指定此编码

另一种方法是多个位向量，每个码字长度对应一个向量。从符号最多的码字长度开始，发出长度和位向量，然后是下一个人口最多的码字长度和较小的位向量…依此类推。同样，一种编码运行和范围的方法可以减少所需的位数，并且n、 当您继续操作时，这些所需的位将下降

---

问题是，与代码表大小的比较有多敏感？很明显，如果它非常敏感，那么研究应用狡猾可以做什么很重要。但任何给定方案的有效性都将取决于它与“典型”的匹配程度正在压缩的数据。

有多种方法存储哈夫曼或算术解压器需要的概率信息，以便将压缩信息解码为原始明文（精确副本）

正如Mark Adler在相关问题（）中提到的

您不需要传输概率或树。所有 [Huffman]解码器需要的是分配给每个符号的位数，以及 将位值分配给每个约定符号的规范方法 由编码器和解码器同时执行。请参阅

我假设您使用的是一个面向字节的哈夫曼码，每个压缩码解码为256个可能字节中的一个

也许存储这些位长度的最简单方法是一个精确的256位长度的穷举表，每个可能的字节一个。 因此，例如，表中第65个条目给出字母“A”（第65个ASCII字符）的位长度，可能是1（当A非常常见时）到12（当A非常罕见时），或者0（表示本文本中从未出现过A）。 每个长度很容易放入一个字节，所以表的长度是256字节

（几乎总是最大长度为15位或更少，因此通常每个长度可以轻松放入半字节，给出的表总是正好128字节长——但处理的是“病态的”诱使哈夫曼算法为某些明文字节分配长度超过15位的符号的数据文件可能很棘手。一些系统专门检查最大长度是否超过15位，并人为更改哈夫曼树以强制所有长度最多为15位——有时称为受限深度哈夫曼树或.Likewise、 JPEG标准将哈夫曼代码长度限制为16位）

使用更紧凑（且更难描述）的方法将和存储在可变长度表中，该表的长度随特定数据而变化，但所有这些方法都首先将要存储的概率信息减少到符号的位长度。 （也许您可以使用DEFLATE实现，而不是编写和调试某些东西。）