用于嵌入式使用的紧凑型解压缩库

Question

我们目前正在为客户创建一个设备，该设备将从PC应用程序获取一块数据（例如，5-10KB）。这有点简化，因此假设数据必须经过多次传递和解压缩，而不是每年一次。通信通道非常非常慢，因此我们希望事先压缩数据，传递给设备并让数据解压缩到内部闪存。然而，设备本身在微控制器上运行，该控制器不是很快并且没有大量内存。它有足够的闪存来存储结果，并且可以在接收时解压缩数据块，但它可能没有足够的RAM来存储整个压缩或未压缩（甚至两个！）数据块。当然，它没有操作系统或其他奢侈品。

这意味着我们需要足够快速的无压缩算法，不会占用大量内存。压缩可能是缓慢而丑陋的，因为我们在PC端进行压缩。 C或.NET代码首选，但压缩，以使事情更容易。解压缩代码应该在C中，因为有人不太可能为我们的控制器提供ASM优化版本。

我们发现LZO对我们来说几乎是完美的，但它默认拥有所谓的“免费”许可证（GPL），这使得它对我们的客户来说完全无法使用。作者说，商业许可证可以根据要求提供，但不幸的是他目前无法访问（出于非技术原因，如他网站上的新闻所说）。

我找到了一些其他的库，包括来自zlib的puff.c，我们还在调查，但我想我会问你的经历：

鉴于解压缩设备的资源非常有限，需要源代码和商业许可证，您建议将哪种压缩算法和/或库用于嵌入式目的？

Answer 1

您可能想要查看其中一个非GPL并且是相当紧凑的实现：

• fastlz - MIT许可证，相当简单的代码
• lzjb - sun CDDL，在zfs中用于压缩，简单且非常短
• liblzf - BSD风格的许可证，小巧，快捷
• lzfx - BSD风格，基于liblzf，小巧，快速

这些算法都是基于Lempel-Ziv-Welch的原始算法（它们共有所有LZ） https://en.wikipedia.org/wiki/Lempel–Ziv–Welch

Answer 2

我使用过LZSS。我使用code中的Haruhiko Okumura作为基础。它使用未压缩数据的最后部分（2K）作为字典。如果没有内存，可以修改此代码以不需要临时环形缓冲区。他的网站上的许可证不明确，但some versions已发布，其中包含“自由使用，分发和修改此程序”行，并且代码由商业供应商使用。

Here是基于构成Allegro游戏库一部分的相同代码的实现。 Allegro许可是礼品或zlib。

另一个选项可能是实现LZF的lzfx lib。我还没用过，但看起来不错。还使用以前的结果，因此它具有较低的内存要求，并在BSD许可下发布。

Answer 3

另一种选择可能是Basic Compression Library中的LZ77编码器/解码器。

由于它为其字典使用解压缩的数据历史记录，因此除了压缩和未压缩的数据缓冲区之外，它不使用额外的RAM。它应该是您的用例（zlib许可证，便携式C）的理想选择。整个解码器只有70行代码（包括注释），而且非常快。

编辑：另一个替代方案是liblzg库，它是上述LZ77编码器/解码器的精炼版本。它压缩得更好，通常更快，并且不需要内存来进行解压缩。它非常非常免费（zlib许可证）。

Answer 4

很大程度上取决于数据的性质。如果它很简单，你可能不需要任何非常花哨的东西。例如，如果下载的数据是简单的图像（例如线图），则简单的运行长度编码可以将数据减少10倍，并且您需要大量的代码和RAM来解码它。

当然，如果数据更复杂，那么这将没有多大用处。但我首先要探索发送的数据，看看是否有特定的方面可以让你比使用通用算法更有效地压缩它。

Answer 5

我会推荐ZLIB。 来自维基：

该库提供了用于控制处理器和内存使用的工具 还有用于节省内存的设施。这些可能仅在受限制的内存环境中有用，例如某些嵌入式系统。 zlib也用于许多嵌入式设备，因为代码是可移植的，自由许可的 并且内存占用相对较小。

Answer 6

您可能需要查看Jørgen易卜生的aPlib - 产品页面中的一些摘录：

  

aPLib实现的压缩比与拆卸器的速度和小尺寸（低至169字节！）相结合，使其成为许多产品的理想选择。

     

aPLib甚至可以免费用于商业用途，请查看附带的许可证以获取详细信息。

压缩库是封闭源代码（是的，我知道这可能是一个问题），但是有各种编译器和操作系统的预编译库，包括32位和64位版本。 有解压缩程序的C和x86汇编源代码。

编辑：

Jørgen还有一个免费的（zlib许可证）BrifLZ库你可以检查一下，如果没有压缩源是一个大问题。

Answer 7

我见过人们在内存数十兆字节的嵌入式系统上使用7zip。