任何压缩算法实现的压缩程度显然取决于所提供的数据。但是，显然也有一些纯粹是通过压缩数据而增加的开销。
我正在处理一个过程，其中我压缩的数据可能是各种类型，但我知道很多数据将非常小，尽管它通常也足够大，可以从某种程度的压缩中受益。虽然我可能只能通过实验确定在应用压缩之前可以工作的最小值，但是我很好奇是否有明确的观点绝对不值得。
使用zip运行一些测试，我压缩了一系列文件，分别包含10、100和1000字节的随机数据，并重复了字母。例如，这是100字节字母文件的内容：
abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqr
我发现文件的压缩版本为219字节（尽管有一定程度的冗余）感到非常惊讶。为了进行比较，带有随机数据的100字节文件变为272字节。
但是，1000字节的字母文件一直压缩到227字节，而随机文件增加到1174。
是否有明确的最小文件大小，即使最冗余的文件也无法从这种压缩中受益？
答案 0 :(得分：1)
大约250字节和500字节之间的大小是一个不错的阈值，具体取决于冗余级别，并且假设压缩数据所花费的时间可以忽略不计。
我意识到完全冗余的数据（每个字节相同）可能会导致最大程度的压缩。
使用从class Rectangle {
height: 23,
width: 45,
constructor(height, width) {
}
}
读取的数据重新运行相同的测试，我发现压缩文件的长度实际上并不是那个变量：
Uncompressed | Compressed | Percent Size -------------+------------+------------- 100 bytes | 178 bytes | 178% 200 bytes | 178 bytes | 89% 300 bytes | 179 bytes | 60% 400 bytes | 180 bytes | 45% 500 bytes | 180 bytes | 36% ... 1000 bytes | 185 bytes | 19%
这在技术上是合理的答案 178个字节（我测试了这种情况，得到了178个字节）。
但是，我认为字母测试可能更接近于实际的最佳冗余情况（在不了解DEFLATE如何寻找冗余的情况下。）
使用与问题相同格式的各种文件，我发现了以下内容：
Uncompressed | Compressed | Percent Size -------------+------------+------------- 100 bytes | 212 bytes | 212% 200 bytes | 212 bytes | 106% 300 bytes | 214 bytes | 71% 400 bytes | 214 bytes | 54% 500 bytes | 214 bytes | 43% ... 1000 bytes | 221 bytes | 22%
毫不奇怪，212对于这种类型的文件似乎是固定的。
最后，我决定对lorem ipsum文本尝试一种更直接的方法，最终发现414个字节是此处的固定点。
基于所有这些，我认为250到500之间的某个值是跳过一般文本的压缩的合理下限，该文本通常可能具有或没有某种程度的冗余。如果基准测试揭示了压缩所花费的时间不值得在空间上获得次要好处，那么甚至可能甚至想更高些。