我有 2 个大文本文件（准确地说是 csv）。两者具有完全相同的内容，只是一个文件中的行顺序相同，而另一个文件中的行顺序不同。
当我压缩这两个文件（以编程方式，使用 DotNetZip）时，我注意到其中一个文件总是相当大 - 例如，一个文件比另一个文件大约 7 MB。-
我的问题是：
文本文件中的数据顺序如何影响压缩以及可以采取哪些措施来保证最佳压缩率？- 我认为将相似的行组合在一起（至少在我正在使用的 ZIP 文件的情况下）将有助于压缩，但我不熟悉不同压缩算法的内部结构，我会很感激快速解释在这个问题上。
哪种算法可以更好地处理这种情况，无论数据的顺序如何，都能实现最佳的平均压缩？
“如何”已经回答了。要回答您的“哪个”问题：
匹配窗口越大，算法对订单的敏感度就越低。然而，所有压缩算法都会在某种程度上敏感。
gzip 有一个 32K 的窗口，bzip2 有一个 900K 的窗口，而 xz 有一个 8MB 的窗口。xz 可以达到 64MB 的窗口。所以 xz 对订单最不敏感。距离较远的匹配将花费更多位进行编码，因此无论窗口大小如何，您总是可以通过排序记录获得更好的压缩。短窗口只是排除了远距离匹配。
在某种意义上，它是文件熵的度量，定义了它的压缩程度。所以，是的，顺序绝对重要。举个简单的例子，考虑一个充满abcdefgh...zabcd...z重复值的文件。大多数算法都可以很好地压缩它，因为它非常有序。但是，如果您完全随机化顺序（但每个字母的计数相同），那么它具有完全相同的数据（尽管“含义”不同）。它是不同顺序的相同数据，也不会压缩。
事实上，因为我很好奇，我只是尝试了一下。我用 100,000 个重复字符填充了一个数组a-z，将其写入文件，然后“随机”打乱该数组并再次写入。第一个文件压缩到 394 字节（小于原始大小的 1%）。第二个文件压缩到 63,582 字节（超过原始大小的 63%）。
典型的压缩算法如下工作。看一大块数据。如果它与其他最近看到的块相同，请不要按字面意思输出当前块，而是输出对那个较早块的引用。
当相似的块靠得很近时，它肯定会有所帮助。该算法将仅保留有限数量的回溯数据以保持合理的压缩速度。因此，即使一块数据与其他块相同，如果那个旧块太旧，它可能已经被刷新掉了。
当然可以。如果输入模式是固定的，则有 100% 的机会预测每个位置的字符。鉴于两方都知道他们的数据流（这基本上等于说他们知道固定模式），几乎不需要传达任何内容：完全压缩是可能的（传达有限长度的字符串，而不是无限的流，你' d 仍然需要对长度进行编码，但这有点离题了）。如果对方不知道该模式，您需要做的就是对其进行编码。完全压缩是可能的，因为您可以用有限的数据量编码无限的流。
在另一个极端，如果你有完全随机的数据——所以流可以是任何东西，下一个字符总是可以是任何有效字符——就不可能进行压缩。流必须完全完整地传输，对方才能重建正确的流。
有限字符串有点棘手。由于有限字符串必须包含每个字符的固定数量的实例，因此一旦您开始读取初始标记，概率就必须改变。可以将某种顺序读入任何有限字符串。
不确定这是否回答了您的问题，但它在理论上解决了一些问题。