怎么樣把兩個壓縮文件壓到一起？

簡單回答一下，完全可以把多個文件看作一個文件進行壓縮，也可以達到你說的壓縮效果，但是慢！如果只是在實驗室里做實驗那是沒有問題的，但是做成通用軟件的時候需要考慮很多問題。

1. 算法的限制。像比較常用的LZ77，GZIP，snappy這種，在匹配相同字符串的時候是有窗口（history buffer）大小和最大匹配長度限制的。以你說的例子為例，你在遇到第二個100M的時候，你需要往前找100M的位置去找到這個匹配，但是匹配這個100M是需要代價的（包括消耗100M的內存和匹配100M長度所需要的時間），這樣會使得壓縮過程非常非常非常慢！其次是最大匹配長度問題，同理，在有限的時間內你不可能無限制地要求更長的匹配，都是有一個閾值的。一般情況下，匹配窗口大小通常是幾KB到幾MB這個級別（snappy是64KB），最大匹配長度就更小了。像LZ78、LZW這些基于字典的也會有字典大小和最大匹配長度問題，不再贅述。

2. 軟件對壓縮率和壓縮速度的折中。簡單說，壓縮率越大，壓縮速度越縵，反之亦然。主要看追求的是怎樣的平衡。即便是一味追求壓縮率，使用一個算法100M對100M的壓縮代價還是很大的，還不如用多層壓縮，比如說GZIP用了哈夫曼和LZ77結合。當然你也可以使用文件對文件的查重算法（各種云1秒上傳電影的例子），但是這種只適合用在云備份上，暫時不適合用作多文件（量太少不實用，浪費資源）壓縮打包。

3. 多文件壓縮更傾向每個單獨壓縮，主要也是性能決定的。比如說你有16個文件要壓縮，如果一開始分開壓縮，那就可以調動16個線程一起壓縮，時間會縮短16倍。然后再花一點時間把各個壓縮之后的文件粘一起并添加上元數據。如果是一起壓縮，由于壓縮算法的并行比較困難，基本都是一個線程在工作（多線程的很多也是先把文件切割成多份，原理同上），這樣會慢很多。解壓也是一樣的，單獨壓縮的文件可以調動多線程同時解壓。另外，在解壓時候如果我只需要其中一個文件，這種壓縮方式就更有優勢了，只需要讀元數據并解只壓需要的那部分文件，而不需要解壓所有文件。