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

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倍。然後再花一點時間把各個壓縮之後的檔案粘一起並新增上元資料。如果是一起壓縮，由於壓縮演算法的並行比較困難，基本都是一個執行緒在工作（多執行緒的很多也是先把檔案切割成多份，原理同上），這樣會慢很多。解壓也是一樣的，單獨壓縮的檔案可以調動多執行緒同時解壓。另外，在解壓時候如果我只需要其中一個檔案，這種壓縮方式就更有優勢了，只需要讀元資料並解只壓需要的那部分檔案，而不需要解壓所有檔案。

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

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倍。然後再花一點時間把各個壓縮之後的檔案粘一起並新增上元資料。如果是一起壓縮，由於壓縮演算法的並行比較困難，基本都是一個執行緒在工作（多執行緒的很多也是先把檔案切割成多份，原理同上），這樣會慢很多。解壓也是一樣的，單獨壓縮的檔案可以調動多執行緒同時解壓。另外，在解壓時候如果我只需要其中一個檔案，這種壓縮方式就更有優勢了，只需要讀元資料並解只壓需要的那部分檔案，而不需要解壓所有檔案。