Compression 确定用于一系列字节的最佳压缩算法

对于我的一个个人项目，我正在编写一个小类来压缩和解压一个相当模糊的格式。我有完整的规格，但这不是问题所在

首先，这种“格式”使用一组6种不同的压缩类型以及未压缩的字节数据块。格式为RLE，是RLE的一个分支，其中每个字节的数量递增（例如3、4、5，…），16位RLE，LZ拷贝，反向LZ拷贝，LZ拷贝与255异或。这不是最干净的规格，但我也没有设计它

我的压缩例程应该接收1到65535字节的数组，并（希望）尽可能多地压缩它。我以前的尝试只是从未压缩流中的任何索引开始计算，上面哪种压缩技术将提供最佳压缩，然后将该方法将压缩的字节数压缩到压缩字节数组中，然后从新的“未压缩”索引重复，例如：

{0,0,0,1,2,3,4}

算法首先读取开始时有三个零，然后输出规范使用的RLE编码，然后从第四个元素开始，读取递增的RLE足以覆盖“1,2,3,4”，并在返回之前压缩

---

总结的问题是，在试图找到最佳使用规范时，即使在小（20-30）字节数组上，例程也非常慢。有谁能帮我提供一些建议，让我看看如何优化这一点，或者我是否可以提供更多的信息来帮助你？

听起来你想做的是为文件的每个可能的段（我们称为可变长度的1-64K块段）计算出大量的压缩可能性。如果我错了，请纠正我，但是您是否从以下选项中为第一段计算出最佳压缩（方法0为未压缩）：

---

• 压缩方法0，长度为1字节
• 压缩方法1，长度为1字节
• ：：：：：：
• 压缩方法6，长度为1字节
• 压缩方法0，长度为2字节
• 压缩方法1，长度为2字节
• ：：：：：：
• 压缩方法6，长度65534字节
• 压缩方法0，长度65535字节
• 压缩方法1，长度65535字节
• 压缩方法2，长度65535字节
• 压缩方法3，长度65535字节
• 压缩方法4，长度65535字节
• 压缩方法5，长度65535字节
• 压缩方法6，长度65535字节

---

这将花费大量时间（每段大约420000次压缩尝试）。如果这就是你正在做的，你最好选择一个单一的段大小（例如64K），并对其应用七种压缩方法中的每一种来选择最好的。然后，对于每个段，输出“method”字节，后跟压缩数据。

是否也包括要在成本中使用的解压的标题信息？如果您无法解压缩，那么获得很好的压缩并没有多大意义：）。尽管如此，LZ在长数据流上的压缩效果并不比其他的好，这似乎很奇怪。此外，IIRC，LZ在数据流中断时会显著降低其压缩性能（因为它使用了以前看到的字节字典）。是的，我想我解释得不好。不同的压缩类型都会为压缩数据的“数据包”输出1到4个字节的头信息，LZ拷贝和派生在解压缩.Neato时会从未压缩的输出流中输出，但这听起来像是一件很麻烦的事情：）。我不知道是否存在长度小于多项式的算法，即使只是贪婪匹配。不过，还是不应该花太多时间来决定这个尺寸——看看你能不能排一些有趣的队。是的，这有点像皮塔。当然，它是针对8位系统进行优化的，后来扩展到16位系统，所以这可能就是它需要这么长时间的原因。不，不是那样的。我基本上是从未压缩字节中的给定索引开始，查看每种压缩类型可以压缩多少字节，然后选择提供最多压缩字节的一个，然后再从新的源索引开始。压缩方法0，长度1字节，索引0。。。压缩方法7，长度为1字节，索引为0。压缩方法0，长度1字节，索引8。。。压缩方法7，长度为1字节，索引为8。压缩方法0，长度1字节，索引36。。。压缩方法7，长度为1字节，索引36。请注意，这可能是一个NP完全问题，因为更改尝试编号2的源索引可能会产生不同的结果。我的意思是，即使你选择了一个次优的第一种方法，其余的压缩可能会给出一个更好的结果。