像霍夫曼编码这样的算法是否实际用于生产？

Question

目前，我正在开发一款需要在iPad上存储大量文字的应用。我的问题是，像生产中实际使用的霍夫曼编码这样的算法吗？我只需要一个非常简单的压缩算法（那里不会有大量的文本，它只需要一个更有效的存储方法），那么像Huffamn这样的工作呢？我应该研究一下其他类型的压缩库吗？

Answer 1

来自Wikipedia on the subject：

  

今天的霍夫曼编码通常被用作其他压缩方法的“后端”。 DEFLATE（PKZIP的算法）和多媒体编解码器（如JPEG和MP3）具有前端模型和量化，然后是霍夫曼编码（或具有类似结构的可变长度无前缀码，尽管可能不一定使用霍夫曼算法设计）。

所以是的，霍夫曼编码用于生产。相当多，甚至。

Answer 2

非常广泛地使用霍夫曼编码（也是熵编码）。你想象的任何被压缩的东西，除了一些非常古老的方案，都会使用它们。图像压缩，Zip和RAR存档，每个可以想象的编解码器等。

请记住，霍夫曼编码是无损的，需要您事先了解所有正在压缩的数据。如果您正在进行有损压缩，则需要对数据执行一些转换以首先减少其熵（在JPEG压缩中移除和量化DCT系数）。如果您希望Huffnam编码处理实时数据（您事先不知道每一位），则使用自适应霍夫曼编码。你可以在信号处理文献中找到很多关于这个主题的内容。

一些预霍夫曼压缩包括游程编码（传真机）等方案。有时仍使用游程编码（JPEG，再次）与霍夫曼编码结合使用。

Answer 3

是的，它们用于生产。

正如其他人所提到的，真正的霍夫曼要求您首先分析整个语料库以获得最有效的编码，因此它通常不会单独使用。

可能在您出生后不久，我在C中的Psion Series 3掌上电脑上实施了霍夫曼压缩，以便压缩预装到数据包上的数据，并且只在手持设备上解压缩。在那些日子里，空间很紧张，没有内置的压缩​​库。

与大多数明确指定的软件一样，我强烈考虑使用iOS中内置的任何功能或开发环境中提供的标准软件包。

这将节省大量调试工作，让您专注于应用程序中最重要的部分，从而增加价值。

大量文本将适合压缩式压缩。从长远来看，花费精力改善其表现（在空间或时间上）将不太可能获得回报。

Answer 4

有一种支持zlib算法的iOS嵌入式机制（Objective-C中的zlib.h）。

您可以实现自己的压缩功能和utilize iOS embedded zlib functions。并比较性能。

我认为嵌入式zlib功能会更快，并且会提供更高的压缩率。

Answer 5

霍夫曼代码是许多“真实世界”生产算法的支柱。今天的常见压缩算法通过转换其数据来改进压缩比，从而改进了霍夫曼码。当然，有许多应用程序特定的技术用于执行此操作。

至于你是否应该使用霍夫曼代码，我的问题是为什么你应该通过使用已经实现的第三方库来实现更好的压缩和代码简化？

Answer 6

是的，我在我的网络应用程序中使用霍夫曼压缩来在隐藏的输入字段中存储我的引擎的完整快照。首先它只是好奇心，但它卸载了我的SESSION内存，将其移动到客户端浏览器内存，我用它将它存储在一个文件中备份并与我的同事交换该快照。伙计，当你可以在管理面板中加载文件以在网络中加载引擎时，你必须看到他们的面孔！它基本上是一个序列化的压缩和base64编码的数组。它帮助我节省了大约15％的带宽，但我想我现在可以做得更好。

Answer 7

是的，您正在使用霍夫曼编码（解码）来阅读此页面，因为网页被压缩为gzip格式。因此，全球各地的网络浏览器几乎每纳秒都会使用它。

霍夫曼编码本身几乎从不使用，而是总是对数据进行一些高阶建模，以便为霍夫曼算法提供所需的工作。因此，LZ77将文本和其他面向字节的数据建模为编码为文字和长度/距离对的重复字符串，然后将其馈送到霍夫曼编码，例如，使用deflate compressed format在zlib中。或者使用PNG的像素差异或其他预测编码，然后进行霍夫曼编码。

至于您应该使用什么，请查看lz4，zlib和zstd。