Compression 随机字符串的最佳压缩算法

我有一些像下面这样的绳子

ff8870fd30db56efd72e8b499a454c4e27be6ab70e23dd59a864563628e998a

这是我试图压缩的大约2k字节，但我没有得到很好的压缩比

使用gz我只减少了400字节，使用defalte我减少了450字节

---

有没有更好的算法可以使压缩率至少降低50%以上。

根据定义，您不能压缩随机数据，因为它不包含任何可以用更少的位以更有效的方式表示/描述的结构。 如果这是可能的，数据包含一个结构，不再是随机的

一个常见的反论点是，如果有足够的赔率，RNG甚至可以生成一个全0字符串，但魔鬼在细节中：这一切都与赔率有关！ 即使在一个很小的2KB空间中，如果数据是由一个真实的RNG或一个稳健的PRNG算法生成的，并带有合理数量的噪声，那么您也有2^（2048*8）个可能的字符串，并且绝大多数这些Sting将不包含任何合理数量的您可以压缩的“顺序”

事实上，您在2KB上获得了400B/450B的压缩，这有力地暗示了您正在查看的字符串不是真正随机的，只是非人类可读的或“随机的”

GZ格式基于Deflate压缩算法，因此不清楚为什么这两个数字分别显示-Deflate接受各种参数以牺牲速度进行微调压缩，因此不同的设置可以证明不同的结果

---

为了更好地压缩随机外观（但不是真正随机！）数据，可以尝试使用LZMA2（7-Zip）或更好的ZPAQ（）。

我知道这比OP要晚得多。。。。然而，如果你看看数据是如何表示的，那么是的，很难找到作为字符串的重复。。。然而

举个例子 “ff8870fd30db56efd72e8b499a454c4e27be6ab70e23dd59a864563628e998a”如下所示

这些信息还可以用其他方式表示？这些看起来都是十六进制对联。例如 “0xff 0x88 0x70”等。。。所以…如果这是以字节存储的。。。。您自动获得100%压缩，因为每个字符本身就是一个字节

如果我们想变得非常聪明，我们可以研究一些数学，比如说我们可以把这些数据映射成更容易压缩的数据。。当然，这只对非常大的数据有利，因为对少量数据的编码可能会使其变得更大