如何在不压缩文件的情况下估计文件的可压缩性？答案

【问题标题】：How can I estimate the compressibility of a file without compressing it?如何在不压缩文件的情况下估计文件的可压缩性？
【发布时间】：2022-04-18 01:41:13
【问题描述】：

我在 twisted python 中使用基于事件循环的服务器来存储文件，我希望能够根据文件的可压缩性对文件进行分类。

如果他们从压缩中受益的可能性很高，他们会转到打开 btrfs 压缩的目录，否则他们会转到其他地方。

我不需要确定 - 80% 的准确度就足够了，而且会节省大量磁盘空间。但由于也存在 CPU 和 fs 性能问题，我不能只保存所有压缩文件。

文件为低兆字节。如果不使用大量 CPU 并过度延迟事件循环或重构压缩算法以适应事件循环，我无法测试压缩它们。

是否有任何最佳做法可以快速估算可压缩性？我想出的是从文件开头提取一小块（几 kB）数据，对其进行测试压缩（可能有可以容忍的延迟），然后以此为基础做出决定。

有什么建议吗？提示？我的推理和/或问题有缺陷？

【问题讨论】：

只是为了说明这一点，您没有提到您计划使用的压缩算法。话虽如此，我认为如果不至少检查一次文件，您将无能为力
为什么不能使用渐进式压缩？
压缩一小部分不会有帮助：如果文件的其余部分只是从这部分的副本中制作的，那么压缩将很容易。恐怕唯一好的解决方案是尝试压缩整个文件。
如何将所有内容保存到未压缩目录中，然后在后台线程中将内容迁移到压缩目录中？在将迁移发布回其他线程之前，迁移器可以检查是否已实现可接受的压缩。
相关：stackoverflow.com/questions/7027022/…

标签： python compression twisted

【解决方案1】：

距离文件中间仅 10K 就可以了。您不需要开头或结尾，因为它们可能包含不代表文件其余部分的标题或结尾信息。 10K 足以使用任何典型算法进行一定程度的压缩。这将预测整个文件的相对压缩量，以中间 10K 为代表。您获得的绝对比率与整个文件的绝对比率不同，但它与未压缩的差异量将允许您设置阈值。只需对多个文件进行试验，看看在哪里设置阈值。

如前所述，您可以通过对明显已经压缩的文件不执行任何操作来节省时间，例如.png。 .jpg.、.mov、.pdf、.zip 等。

测量熵不一定是一个好的指标，因为它只给出了可压缩性的零阶估计。如果熵表明它足够可压缩，那么它是正确的。如果熵表明它没有足够的可压缩性，那么它可能是正确的，也可能不是正确的。您的实际压缩器是一个更好的可压缩性估计器。在 10K 上运行它不会花费很长时间。

【讨论】：

用我的 testdata 1K 做不到，但似乎 10K 足以估计整个文件可以达到的压缩率。但我仍在处理数字，所以我会回复你:)

【解决方案2】：

我想你要找的是How to calculate the entropy of a file?

此问题包含计算文件熵的各种方法（通过这些方法您可以获得文件的“可压缩性”）。这是this文章摘要的引述（Relationship Between Entropy and 测试数据压缩 Kedarnath J. Balakrishnan，IEEE 成员和 Nur A. Touba，IEEE 高级成员）：

一组数据的熵是衡量其中包含的信息量的指标。已使用完全指定数据的熵计算来获得关于可以压缩多少数据的理论界限。本文扩展了熵的概念，用于不完全指定的测试数据（即具有未指定或无关位），并探索使用熵来显示如何计算特定符号分区的最大压缩量的界限。研究了将测试数据划分为符号的不同方式对熵的影响。对于使用固定长度符号的一类分区，描述了一种用于指定无关减少熵的贪心算法。它被证明等价于最小熵集覆盖问题，因此在所有指定无关项的方法中，相对于最小熵可能在一个加性常数误差内。描述了一种可用于近似计算熵的多项式时间算法。针对熵界限分析了文献中提出的不同测试数据压缩技术。使用熵理论研究某些类型的测试数据编码策略的局限性和优势

为了更具建设性，请查看 this 站点，了解 python 实现数据块的熵计算

【讨论】：

感谢文献！我不想走学术路线，但是用一两个熵算法进行测试运行、压缩一小块样本数据和压缩整个文件可能真的很有趣。我想我会这样做并返回结果:)
好的，所以我必须再次取消选中标记，因为熵（至少不是链接的函数，但我不是数学家，所以我对替代方案了解多少；）不是去。我会把更多的测试数据放到网上，但现在看起来，实际上在小样本上使用压缩算法比潜在的熵相关更具代表性——后者更加模糊。
所以你必须改变这个问题:)你特别要求一种方法来知道数据是否会很好地压缩而不实际压缩它......
顺便说一句 - 我刚刚发现了这个 SO 问题：stackoverflow.com/questions/7027022/… 看起来您可以尝试产生良好结果的方法：“ASCII 检查”、“熵计算”和“简化压缩”。跨度>

【解决方案3】：

压缩文件通常不能很好地压缩。这意味着几乎任何媒体文件都不会很好地压缩，因为大多数媒体格式已经包含压缩。显然，这有例外，例如 BMP 和 TIFF 图像，但您可能可以建立一个压缩良好的文件类型（PNG、MPEG 和冒险远离视觉媒体 - gzip、bzip2 等）的白名单以跳过然后假设您遇到的其余文件都会很好地压缩。

如果您想变得花哨，可以在系统中建立反馈（观察您所做的任何压缩的结果并将结果比率与文件类型相关联）。如果您遇到压缩率一直很差的文件类型，您可以将其添加到白名单中。

这些想法取决于能够识别文件的类型，但是有一些标准实用程序可以很好地完成这一工作（通常比 80% 好得多） - file(1)、/etc/mime.types 等.

【讨论】：

如果文件的开头（以及 mime 类型）是给定的，这将是最好的解决方案，但事实并非如此。它更像是通常可以压缩的任意数据块。
当然，您必须有某种方法从文件的任何给定块中发现文件的开头 - 否则您如何重建整个文件？但是如果你真的不能这样做，那么我想这种方法是不可能的（它作为 file server 的解决方案肯定比 任意文件块更有意义服务器（你的问题听起来像是在处理前者:)。
对不起，正如您猜对的那样，它们确实是解构文件，我应该将其包括在内以消除 mime 类型的可能性。工作流程不允许即时重建，因为它是系统的不同部分，知道如何做到这一点。