可以用 8 位有效数据完全填充所有字节，是减小文件大小的（好）方法吗？
Can completely filling all the bytes with 8 significant bits of data, be a (good) way to reduce file sizes?
这个想法在我脑海中萦绕了几个月。当我在互联网上搜索数据压缩技术时，我发现每个人都在谈论删除人类未注意到的字节或找到重复的模式并重新编码位和字节以减小文件大小。我在数据压缩领域的知识非常有限，因此这个问题。
在检查多个 MPEG-4 媒体文件的位模式时，我注意到所有 256 种 8 位模式出现的次数几乎相同。也就是说，占该文件 95%（或更多）的 255 种模式最多需要 7 位，但正在占用更多位。如果一个字节存储 00001011，前四位是多余的并且可以安全删除（如果我错了，请在这一点上纠正我）。如果我们删除那些无关紧要的位并用其他字节的重要位填充 space 会怎样？如果我们这样做，我知道挑战。我们需要一种方法来获取原始位模式及其所有冗余，以便媒体播放器稍后能够理解。我们能否想出一种算法来删除冗余位并存储一些引用（编码）以帮助分离 "merged" 字节，然后使用这些引用取回原始字节（解码）？你对 "stored references" 有什么看法？它们的有效性和 space 效率如何？我希望我解释得很好。如果没有，请告诉我。
示例：
假设一个文件中有 8 个字节的数据。字节如下：
0001010111110000101010100101010100000001000001101011111000001111
查看第 1、4、5、6 和 8 个字节。我们实际上并不需要 8 位来表示它现在表示的数据。这些字节用零填充，占用更多 space 来完成八位字节。我将从第一个字节中删除填充位，这将使 space 成为 3 位。在这 3 位中，我将存储第二个字节的前 3 位。那么前两个字节变为：
1111010100010000
删除所有冗余位后，我们最终节省了 16 位：
1111010110110000 - 101 来自第 3 个字节10101010 - 101 来自第 4 个字节。请注意，第 4 个字节本身有一个无关紧要的位 11100101 - 1 和 110 来自第 5 和第 6 个字节10111110 - 整个第 7 个字节00001111 - 用零填充，因为文件在这里结束
我上面所做的可能很难理解。简单来说，我通过删除冗余位（填充零）然后用下一个字节的有效位填充它来清理 space 。我正在考虑一种算法的可能性，该算法首先计算并存储一些数据（显然在内存中占用少于 16 位），然后使用它来解码 "merged bytes" 以带出我们的原始 8 字节文件开始我们的例子。
通常没有办法在保持明确解码和无条件减小大小的同时简单地从值中删除前导零位。虽然对于人类来说 00001 是 "simply 1" 与 0000123 是 "simply 123" 的方式相同，但在考虑二进制字节值时情况并非如此。事实上，0和1在这里是对称的：为什么不问如何删除领先的？
当然，如果有很多前导零（超出您对均匀分布字节的预期），您当然可以使用各种现有技术（例如熵编码）压缩数据 - 但只有 "some" 次字节值中有许多前导零并不意味着数据是可压缩的。
想象一下，如果可能的话：您可以重复应用您的技术，直到不存在带前导零的字节。然后您可以对数据应用 NOT（反转每一位），此时每个字节都会有前导零 1，并且您可以继续应用您的过程，重复直到实现无限压缩.一旦你提出了无限压缩，你可以很确定你的技术在一般情况下不起作用。
1 重要的是要注意此步骤是可逆的，因为您可以在只有带前导零的字节的解码时应用它。
这个想法在我脑海中萦绕了几个月。当我在互联网上搜索数据压缩技术时，我发现每个人都在谈论删除人类未注意到的字节或找到重复的模式并重新编码位和字节以减小文件大小。我在数据压缩领域的知识非常有限，因此这个问题。
在检查多个 MPEG-4 媒体文件的位模式时，我注意到所有 256 种 8 位模式出现的次数几乎相同。也就是说，占该文件 95%（或更多）的 255 种模式最多需要 7 位，但正在占用更多位。如果一个字节存储 00001011，前四位是多余的并且可以安全删除（如果我错了，请在这一点上纠正我）。如果我们删除那些无关紧要的位并用其他字节的重要位填充 space 会怎样？如果我们这样做，我知道挑战。我们需要一种方法来获取原始位模式及其所有冗余，以便媒体播放器稍后能够理解。我们能否想出一种算法来删除冗余位并存储一些引用（编码）以帮助分离 "merged" 字节，然后使用这些引用取回原始字节（解码）？你对 "stored references" 有什么看法？它们的有效性和 space 效率如何？我希望我解释得很好。如果没有，请告诉我。
示例： 假设一个文件中有 8 个字节的数据。字节如下：
0001010111110000101010100101010100000001000001101011111000001111
查看第 1、4、5、6 和 8 个字节。我们实际上并不需要 8 位来表示它现在表示的数据。这些字节用零填充，占用更多 space 来完成八位字节。我将从第一个字节中删除填充位，这将使 space 成为 3 位。在这 3 位中，我将存储第二个字节的前 3 位。那么前两个字节变为：
1111010100010000
删除所有冗余位后，我们最终节省了 16 位：
1111010110110000- 101 来自第 3 个字节10101010- 101 来自第 4 个字节。请注意，第 4 个字节本身有一个无关紧要的位11100101- 1 和 110 来自第 5 和第 6 个字节10111110- 整个第 7 个字节00001111- 用零填充，因为文件在这里结束
我上面所做的可能很难理解。简单来说，我通过删除冗余位（填充零）然后用下一个字节的有效位填充它来清理 space 。我正在考虑一种算法的可能性，该算法首先计算并存储一些数据（显然在内存中占用少于 16 位），然后使用它来解码 "merged bytes" 以带出我们的原始 8 字节文件开始我们的例子。
通常没有办法在保持明确解码和无条件减小大小的同时简单地从值中删除前导零位。虽然对于人类来说 00001 是 "simply 1" 与 0000123 是 "simply 123" 的方式相同，但在考虑二进制字节值时情况并非如此。事实上，0和1在这里是对称的：为什么不问如何删除领先的？
当然，如果有很多前导零（超出您对均匀分布字节的预期），您当然可以使用各种现有技术（例如熵编码）压缩数据 - 但只有 "some" 次字节值中有许多前导零并不意味着数据是可压缩的。
想象一下，如果可能的话：您可以重复应用您的技术，直到不存在带前导零的字节。然后您可以对数据应用 NOT（反转每一位），此时每个字节都会有前导零 1，并且您可以继续应用您的过程，重复直到实现无限压缩.一旦你提出了无限压缩，你可以很确定你的技术在一般情况下不起作用。
1 重要的是要注意此步骤是可逆的，因为您可以在只有带前导零的字节的解码时应用它。