這是一場災(zāi)難！我們使用更短的代碼代表字母“e”和“t”的精巧計劃，導(dǎo)致了一個根本不奏效的編碼系統(tǒng)。幸運的是，再多使用一種把戲就能彌補。真正的問題是當(dāng)我們看到數(shù)字8或9時，我們無從分辨它是一個一位數(shù)代碼（不管是“e”還是“t”）的一部分，還是一個以8或9開頭的兩位數(shù)代碼（如重讀符號“á”和“è”等）的一部分。要解決這個問題，我們必須有所犧牲：一些代碼實際上會變得更長。以8或9開頭的清楚的兩位數(shù)代碼會變成三位數(shù)代碼，但并不會以8或9開頭。139頁的圖標(biāo)展示了一種達成這一目的的特殊方法。一些標(biāo)點符號也受到了影響，但最終情況良好：任何以7開頭的數(shù)字都是三位數(shù)代碼，任何以8或9開始的數(shù)字都是一位數(shù)代碼，任何以0、1、2、3、4、5或6開頭的數(shù)字都是和前面一樣的兩位數(shù)代碼。因此，現(xiàn)在拆分?jǐn)?shù)字13889的方法只有一種（13-8-8-9，代表“Meet”）——這也是用于其他任何正確編碼的數(shù)字字符串。所有模糊性都被消除了，原始消息的新編碼如下：
M e e t y o u r f i a n c é t h e r e .
138 8 9 0051414744003235274029782009 348 448 66
原始編碼使用了46個數(shù)字，這次只使用了41個數(shù)字。這看起來也許只是節(jié)省了一點點，但如果是一條更長的信息，節(jié)省的長度就會非常明顯。比如，本書文本（只有文字，沒有圖像）要求將近500 KB——50萬字符——的存儲空間。但在使用了剛剛描述的兩種把戲壓縮后，本書文本的體積減少到只有160 KB，不到原體積的三分之一。
總結(jié)：免費午餐來自何方？
現(xiàn)在，我們理解了創(chuàng)建計算機標(biāo)準(zhǔn)壓縮ZIP文件背后的所有重要概念。下面是具體實施步驟：
步驟一：
計算機使用同前把戲傳輸未經(jīng)壓縮的原文件，讓文件中絕大多數(shù)重復(fù)數(shù)據(jù)由短得多的指令取代，這些指令會返回并拷貝其他地方的數(shù)據(jù)。
鄂公網(wǎng)安備 42010302001612號