tom harris
或stuffit
這樣的程式來展開檔案，將其復原到原始大小。如果一切正常，展開的檔案與壓縮前的原始檔案將完全相同。
乍一聽好像很神秘：您是怎樣減少位元和位元組的數量並將它們原封不動地還原回去的呢？等一切水落石出之後，您會發現這個過程背後的基本理念其實非常簡單明瞭。在本文中，我們將討論這種通過簡單壓縮來明顯減小檔案的方法。
大多數計算機檔案型別都包含相當多的冗餘內容——它們會反覆列出一些相同的資訊。檔案壓縮程式就是要消除這種冗餘現象。與反覆列出某一塊資訊不同，檔案壓縮程式只列出該資訊一次，然後當它在原始程式中出現時再重新引用它。
以我們熟悉的資訊型別——單詞——為例子。
甘迺迪（john f. kennedy）在2023年的就職演說中曾說過下面這段著名的話：
ask not what your country can do for you——ask what you can do for your country.（不要問國家能為你做些什麼，而應該問自己能為國家做些什麼。）
這段話有17個單詞，包含61個字母、16個空格、1個破折號和1個句點。如果每個字母、空格或標點都占用1個記憶體
單元，那麼檔案的總大小為79個單元。為了減小檔案的大小，我們需要找出冗餘的部分。
我們立刻發現：
如果忽略大小寫字母間的區別，這個句子幾乎有一半是冗餘的。九個單詞（ask、not、what、your、country、can、do、for、you）幾乎提供了組成整句話所需的所有東西。為了構造出另一半句子，我們只需要拿出前半段句子中的單詞，然後加上空格和標點就行了。
大多數壓縮程式使用基於自適應字典的lz演算法來縮小檔案。「lz」指的是此演算法的發明者lempel和ziv，「字典」指的是對資料塊進行歸類的方法。
排列字典的機制有很多種，它也可以像編號列表那樣簡單。在我們檢查甘迺迪這句著名講話時，可以挑出重複的單詞，並將它們放到編號索引中。然後，我們直接寫入編號而不是寫入整個單詞。
因此，如果我們的字典是：
ask
what
your
country
can
do for
you
我們的句子現在就應該是這樣的：
1 not 2 3 4 5 6 7 8-- 1 2 8 5 6 7 3 4
但是使用這種機制究竟能夠節省多少空間呢？「1 not 2 3 4 5 6 7 8——1 2 8 5 6 7 3 4」當然短於「ask not what your country can do for you-- ask what you can do for your country.」，但應注意的是，我們需要隨檔案一起儲存這個字典。
在實際壓縮方案中，計算出各種檔案需求是乙個相當複雜的過程。讓我們回過頭考慮一下上面的例子。每個字元和空格都占用1個記憶體單元，整個原句要占用79個單元。壓縮後的句子（包括空格）占用了37個單元，而字典（單詞和編號）也占用了37個單元。也就是說，檔案的大小為74個單元，因此我們並沒有把檔案大小減少很多。
但這只是乙個句子的情況！可以想象的是，如果用該壓縮程式處理完甘迺迪講話的其餘部分，我們會發現這些單詞以及其他單詞重複了更多次。而且，正如下一節所言，為了得到盡可能高的組織效率，可以對字典進行重寫。
如果從這個角度處理該句子，我們最終會得到乙個完全不同的字典。
如果壓縮程式掃瞄甘迺迪的這句話，它遇到的第乙個冗餘部分只有幾個字母長。在ask not what your中，出現了乙個重複的模式，即字母t後面跟乙個空格——在not和what中。如果壓縮程式將此模式寫入字典，則每次出現「ｔ」後面跟乙個空格的情況時，它會寫入乙個「１」。但是在這個短句中，此模式的出現次數不夠多，不足以將其保留為字典中的乙個條目，因此程式最終會覆蓋它。
程式接下來注意到的內容是ou，在your和country中都出現了它。如果這是一篇較長的文件，將此模式寫入字典會節省大量空間——在英語中ou是乙個十分常見的字母組合。但是在壓縮程式看完整個句子後，它立即發現了乙個更好的字典條目選擇：不僅ou發生了重複，而且your和country整個單詞都發生了重複，並且它們實際上是作為乙個短語your country一起發生重複的。在本例中，程式會用your country條目覆蓋掉字典中的ou條目。
短語can do for也發生了重複，一次後面跟著your，另一次跟著you，因此我們又發現can do for you也是一種重複模式。這樣，我們可以用乙個數字來代替15個字元（包含空格），而your country只允許我們用乙個數字代替13個字元（包含空格），所以程式會用r country條目覆蓋your country條目，然後再寫入乙個單獨的can do for you條目。程式通過這種方式繼續工作，挑出所有重複的資訊，然後計算應該將哪一種模式寫入字典。基於自適應字典的lz演算法中的「自適應」部分指的就是這種重寫字典的能力。程式執行此工作的過程實際上非常複雜，您可以參考data-compression.com
無論使用什麼方法，這種深入搜尋機制都能比僅僅挑出單詞這種方法更有效率地對檔案進行壓縮。如果使用我們上面提取出的模式，然後用「__」代替空格，最終將得到下面這個更大的字典：
ask__
what__
you
r__country
__can__do__for__you
而句子則較短：
「1not__2345__--__12354」
句子現在占用18個記憶體單元，字典占用41個單元。所以，我們將檔案總大小從79個單元壓縮到了59個單元！這僅僅是壓縮句子的一種方法，而且不一定是最高效的方法。（看看您能找到更好的方法嗎！）
那麼這種機制到底有多好呢？檔案壓縮率取決於多種因素，包括檔案型別、檔案大小和壓縮方案。
在世界上的大多數語言中，某些字母和單詞經常以相同的模式一起出現。正是由於這種高冗餘性，而導致文字檔案的壓縮率會很高。通常大小合適的文字檔案的壓縮率可以達到50%或更高。大多數程式語言的冗餘度也很高，因為它們的命令相對較少，並且命令經常採用一種設定的模式。對於包含大量不重複資訊的檔案（例如影象或***檔案
），則不能使用這種機制來獲得很高的壓縮率，因為它們不包含重複多次的模式。
如果檔案有大量重複模式，那麼壓縮率通常會隨著檔案大小的增加而增加。從我們的例子中就可以看出這一點——如果我們摘錄的甘迺迪講話再長一些，您會發現又多次出現了我們字典中的模式，因此能夠通過每個字典條目節省更多的檔案空間。此外，對於更大的檔案，還可能出現具有更大普遍性的模式，從而能夠建立出效率更高的字典。
此外，檔案壓縮效率還取決於壓縮程式使用的具體演算法
。有些程式能夠在某些型別的檔案中更好地尋找到模式，因此能更有效地壓縮這些型別的檔案。其他一些壓縮程式在字典中又使用了字典，這使它們在壓縮大檔案時表現很好，但是在壓縮較小的檔案時效率不高。儘管這一類的所有壓縮程式都基於同乙個基本理念，但是它們的執行方式卻各不相同。程式開發人員始終在嘗試建立更好的壓縮機制。
有失真壓縮和無失真壓縮
我們在上文中討論的壓縮型別稱為無失真壓縮，因為您重新建立的檔案與原始檔案完全相同。所有無失真壓縮都基於這樣一種理念：將檔案變為「較小」的形式以利於傳輸或儲存，並在另一方收到它後復原以便重新使用它。
有失真壓縮則與此大不相同。這些程式直接去除「不必要」的資訊，對檔案進行剪裁以使它變得更小。這種型別的壓縮大量應用於減小位圖影象的檔案大小，因為位圖影象的體積通常非常龐大。為了了解有失真壓縮的工作原理，讓我們看看你的計算機如何對一張掃瞄
的**進行壓縮。
對於此類檔案，無失真壓縮程式的壓縮率通常不高。儘管的大部分看起來都是相同的——例如，整個天空都是藍色的——但是大部分畫素之間都存在微小的差異。為了使變得更小同時不降低其解析度，您必須更改某些畫素的顏色值。如果中包含大量的藍色天空，程式會挑選一種能夠用於所有畫素的藍色。然後，程式重寫該檔案，所有天空畫素的值都使用此資訊。如果壓縮方案選擇得當，您不會注意到任何變化，但是檔案大小會顯著減小。
當然，對於有失真壓縮，在檔案壓縮後您無法將其復原成原始檔案的樣子。您必須接受壓縮程式對原始檔案的重新解釋。因此，如果需要完全重現原來的內容（例如軟體應用程式、資料庫和**就職演說），則不應該使用這種壓縮形式。
檔案壓縮技術簡單原理
檔案壓縮技術簡單原理 比如儲存乙個數字1到計算機硬碟中，那麼該如何儲存呢？這裡用到了byte，位元組的概念。其實計算機儲存資料的最小單位應該是bits即 1byte 8bits，比如要把1這個數字儲存到計算機中應該是這樣的00000001,那麼前面的七個0，而後面只用到了一位，這樣就有點浪費，聰明的...
HTTP壓縮工作原理
http壓縮工作原理 web伺服器處理http壓縮的工作原理如下 web伺服器接收到瀏覽器的http請求後，檢查瀏覽器是否支援http壓縮 如果瀏覽器支援http壓縮，web伺服器檢查請求檔案的字尾名 如果請求檔案是html css等靜態檔案，web伺服器到壓縮緩衝目錄中檢查是否已經存在請求檔案的最...
壓縮多個檔案
首先需要icsharpcode.sharpziplib.dll 新建filecompression.cs檔案 using system using system.collections.generic using system.io using system.threading using icsh...