对二进制数据使用霍夫曼编码时，如何确定字符？答案

【问题标题】：When using Huffman encoding for binary data, how are characters determined?对二进制数据使用霍夫曼编码时，如何确定字符？
【发布时间】：2019-04-20 17:19:43
【问题描述】：

我见过的所有霍夫曼编码示例都使用字母（A、B、C）作为被编码的字符，它们在其中计算每个字符的频率以生成霍夫曼树。当您要编码的数据是二进制时会发生什么？我见过人们将每个字节视为一个字符，但为什么呢？使用 8 位作为“字符”的截止值似乎是任意的，为什么不使用 16 位呢？为什么 32 位架构不使用 32？

【问题讨论】：

可能是因为这些是简化的示例（并且每个人都对 ascii 表有所了解）。我会假设（不确定）例如在放气中，熵编码可能不是按字节计算的。从性能的角度来看，字节对齐（不一定是一个字节）可能是有意义的。 32 位输入也会生成更大的霍夫曼树，必须存储和传输，因此在数据大小方面也需要权衡。

标签： compression huffman-code

【解决方案1】：

您意识到Huffman encoding 可以处理超过 256 个符号，这是您的敏锐洞察力。 Huffman 编码的一些实现可以处理超过 256 个符号，例如

HuffWord，将英文文本解析为或多或少的英文单词（通常是包含大约 32,000 个唯一单词的文本块）并生成 Huffman 树，其中每个叶子代表一个英文单词，并使用唯一的 Huffman 代码进行编码
HuffSyllable，将文本解析为音节，并生成一个 Huffman 树，其中每个叶子代表（大约）一个英语音节，用唯一的 Huffman 代码编码
DEFLATE，首先将重复的字符串替换为（长度，偏移）符号，有几个不同的 Huffman 表，一个优化用于表示距离（偏移），另一个有 287 个符号，每个叶子代表要么一个特定的长度（（长度，偏移）符号的一部分）或一个文字字节。
一些length-limited Huffman trees used in JPEG compression 编码JPEG quantized 亮度值（从-2047 到+2047？），最大代码长度为16 位。

在 16 位架构或 32 位架构的计算机上，ASCII 文本文件和 UTF-8 文本文件和照片与 8 位计算机上的几乎相同，因此没有真正的理由切换到不同的方法.

在 16 位架构或 32 位架构上，通常机器代码是 16 位对齐的，因此使用 16 位符号的静态 Huffman 可能有意义。

静态霍夫曼具有传输有关每个符号的比特长度信息的开销，因此接收器可以重建解压缩所需的码字。 8 位静态 Huffman 标头中的 257 位左右的位长度对于“短字符串压缩”来说已经太多了。正如 sascha 指出的那样，使用 16 位作为“字符”将需要更多的开销（大约 65,000 位长度），因此使用 16 位输入的静态 Huffman 编码仅对开销较小的长文件有意义。

【讨论】：