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