我的问题是我有 100,000 多个不同的元素，据我所知，霍夫曼的工作方式是为最常见的元素分配 0 代码，接下来是 10，接下来是 110、1110、11110 等等。我的问题是，如果第 n 个元素的代码是 n 位长，那么肯定一旦我通过了第 32 项，那么只发送 32 位数据类型（例如整数）会更节省空间吗？我是否错过了方法论中的某些内容？
非常感谢您提供的任何帮助。我目前的实施通过做
code = (code << 1) + 2;
生成每个新代码（这似乎是正确的！），但我可以对超过 100,000 个元素进行编码的唯一方法是在临时的新数据类型中使用 int[] 来访问我们将从 int 中读取的值数组作为一个连续的长符号......这不像传输 32 位 int 那样节省空间？或者它更像是霍夫曼使用其前缀代码的情况，并且能够明确地确定连续比特流中的每个唯一值？
谢谢
你的理解有点偏离 - 看看http://en.wikipedia.org/wiki/Huffman_coding。而且您必须将编码位打包成机器字才能进行压缩 - 霍夫曼编码数据最好被认为是位流。
您似乎了解前缀码的原理。
你能告诉我们更多关于你提到的这 100,000 多个不同元素的信息吗？
事实上，最快的前缀码——通用码——确实涉及一系列可以预先生成的位序列，而无需考虑实际的符号频率。正如您所提到的，使用这些代码的压缩程序将最频繁的输入符号与最短的位序列相关联，将下一个最频繁的输入符号与下一个短路的位序列相关联，依此类推。
您描述的是一种特殊的前缀代码：一元编码。一元编码系统的另一种流行变体按频率顺序将元素分配给固定代码“1”、“01”、“001”、“0001”、“00001”、“000001”等。
一些压缩程序使用另一种流行的前缀代码：Elias gamma 编码。Elias 伽马编码按频率顺序将元素分配给固定的码字集
1
010
011
00100
00101
00110
00111
0001000
0001001
0001010
0001011
0001100
0001101
0001110
0001111
000010000
000010001
000010010
...
第 32 个 Elias 伽马码字长约 10 位，约为第 32 个一元码字的一半。第 100,000 个 Elias 伽马码字的长度约为 32 位。
如果你仔细看，你会发现每个 Elias gamma 码字都可以分成两部分——第一部分或多或少是你熟悉的一元码。该一元代码告诉解码器在该特定 Elias 伽马代码字的其余部分之后还有多少位。
还有许多其他种类的前缀代码。许多人（令人困惑地）将所有前缀代码称为“霍夫曼代码”。
在压缩某些特定的数据文件时，某些前缀代码在压缩方面比其他代码做得更好。你如何决定使用哪一个？哪个前缀代码最适合某些特定的数据文件？
霍夫曼算法——如果你忽略霍夫曼频率表的开销——为每个数据文件准确地选择最佳前缀代码。在不考虑实际符号频率的情况下，没有可以预先生成的单数“the”霍夫曼码。霍夫曼算法选择的前缀码对于不同的文件通常是不同的。
当我们确实有 100,000 多个唯一元素时，霍夫曼算法的压缩效果不是很好——霍夫曼频率表的开销变得如此之大，以至于我们经常可以找到一些其他“次优”前缀代码，它们实际上可以提供更好的净压缩。或者，一些完全不同的数据压缩算法可能在您的应用程序中工作得更好。
“Huffword”实现似乎可以使用大约 32,000 个左右的独特元素，但我见过的绝大多数 Huffman 代码实现都可以使用大约 257 个独特元素（256 个可能的字节值和文本结束指示符） .
您可能会考虑以某种原始“未压缩”格式将数据存储在磁盘上。（对于 100,000 多个唯一元素，您将不可避免地最终将其中许多元素存储在 3 个或更多字节中）。那些 257 值的 Huffman 压缩实现将能够压缩该文件；他们将该文件的字节重新解释为 256 个不同的符号。
我的问题是，如果第 n 个元素的代码是 n 位长，那么肯定一旦我通过了第 32 项，那么只发送 32 位数据类型（例如整数）会更节省空间吗？我是否错过了方法论中的某些内容？
前缀码更违反直觉的特征之一是某些符号（稀有符号）被“压缩”成更长的位序列。如果您实际上有 2^8 个唯一符号（所有可能的 8 位数字），则如果您强制压缩器使用限制为 8 位或更少的前缀代码，则不可能获得任何压缩。通过允许压缩器扩展稀有值——使用超过 8 位来存储我们知道可以存储在 8 位中的稀有符号——这可以释放压缩器以使用少于 8 位来存储更频繁的符号.
相关： 不同数字的最大数量，霍夫曼压缩