我想压缩一个看起来像BITMAP INDEX的文件。 （二进制格式的文件，仅为“0”和“1”）。
当使用字节表示“0”或“1”时，压缩具有良好的比率，因为随机性较低。
我想使用一点，而不是用一个字节来表示“0”或“1”。 例： 数字8 = 00001000 numbeer 10 = 00001010
因此，未压缩文件将比使用byte表示0和1的位图索引小8倍。
但是当我压缩这个文件时，我的比例非常差，因为数据的随机性很高。
所以我的问题是。是否有任何压缩算法，较小的单位是一个位而不是一个字节？或者我可以用来降低数据随机性的任何技巧？
答案 0 :(得分：4)
是否有任何压缩算法，较小的单位是一个位而不是一个字节？
任何理智的基于熵的压缩算法都将在“位”级别上工作，从而显示预期的行为。当传递一个只包含“00000001”和“00000000”字节的输入时，编码器在某种意义上“看到”输入包含了很多“0”位，引发了一些“1” - 它通过使用表格（或压缩器用来表示它的状态）来处理这种情况，将适应这种情况并获得良好的压缩比。
如果你真的使用了一个字节中的所有位，输入的熵（“随机性”）要高得多，所以当你输入的大小只有1/8时，你也可以压缩机的工作要困难得多，它的压缩比也会受此影响。无论如何，我绝对认为这是要走的路，因为你不依赖于压缩器，它可能或者可能不擅长追赶输入数据中的“大量0方案”。
或者我可以用来降低数据随机性的任何技巧？
这些“技巧”涉及对输入数据执行转换以减少输入数据的熵。你在这里做什么真的取决于输入数据的性质。如果它是真正的黑白“图像”，您可能需要查看JBIG或查看PNG图像标准中定义的变换。
答案 1 :(得分：1)
但是当我压缩这个文件时，我的比例非常差，因为数据的随机性很高。
压缩率在这里是一个红鲱鱼。您应该比较压缩文件大小。
理论上，压缩文件大小应该没有区别，因为它是相同的数据。
未压缩，bits-as-bytes文件将大8倍。然而，它在理论上压缩得很好，大小只有1/8 - 但并不比未压缩的打包位版本好。
（我假设你在这里写8位字节。如果你正在写32位整数，用32替换为8位。）