這是一場災(zāi)難！我們使用更短的代碼代表字母“e”和“t”的精巧計(jì)劃，導(dǎo)致了一個(gè)根本不奏效的編碼系統(tǒng)。幸運(yùn)的是，再多使用一種把戲就能彌補(bǔ)。真正的問題是當(dāng)我們看到數(shù)字8或9時(shí)，我們無從分辨它是一個(gè)一位數(shù)代碼（不管是“e”還是“t”）的一部分，還是一個(gè)以8或9開頭的兩位數(shù)代碼（如重讀符號“á”和“è”等）的一部分。要解決這個(gè)問題，我們必須有所犧牲：一些代碼實(shí)際上會(huì)變得更長。以8或9開頭的清楚的兩位數(shù)代碼會(huì)變成三位數(shù)代碼，但并不會(huì)以8或9開頭。139頁的圖標(biāo)展示了一種達(dá)成這一目的的特殊方法。一些標(biāo)點(diǎn)符號也受到了影響，但最終情況良好：任何以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個(gè)數(shù)字，這次只使用了41個(gè)數(shù)字。這看起來也許只是節(jié)省了一點(diǎn)點(diǎn)，但如果是一條更長的信息，節(jié)省的長度就會(huì)非常明顯。比如，本書文本（只有文字，沒有圖像）要求將近500 KB——50萬字符——的存儲(chǔ)空間。但在使用了剛剛描述的兩種把戲壓縮后，本書文本的體積減少到只有160 KB，不到原體積的三分之一。

總結(jié)：免費(fèi)午餐來自何方？

現(xiàn)在，我們理解了創(chuàng)建計(jì)算機(jī)標(biāo)準(zhǔn)壓縮ZIP文件背后的所有重要概念。下面是具體實(shí)施步驟：

步驟一：

計(jì)算機(jī)使用同前把戲傳輸未經(jīng)壓縮的原文件，讓文件中絕大多數(shù)重復(fù)數(shù)據(jù)由短得多的指令取代，這些指令會(huì)返回并拷貝其他地方的數(shù)據(jù)。