壓縮器的演算法

『壹』 簡述JPEG壓縮演算法

首先你需要了解幾個概念，有損壓縮，量化，行程編碼。
對一副圖片來說，bitmap就是原始格式，沒經過任何壓縮的。
量化就是把所有0-255的像素值進行歸類，然後分成盡量少的積累，這要存儲量就小很多了，對於JEPG來說量化是有損壓縮的起源。
最後就是對所有的已經歸類過的點進行行程編碼，然後就壓縮完了

『貳』 壓縮演算法原理

哈夫曼
哈夫曼編碼是無損壓縮當中最好的方法。它使用預先二進制描述來替換每個符號，長度由特殊符號出現的頻率決定。常見的符號需要很少的位來表示，而不常見的符號需要很多為來表示。

哈夫曼演算法在改變任何符號二進制編碼引起少量密集表現方面是最佳的。然而，它並不處理符號的順序和重復或序號的序列。

2.1 原理
我不打算探究哈夫曼編碼的所有實際的細節，但基本的原理是為每個符號找到新的二進製表示，從而通常符號使用很少的位，不常見的符號使用較多的位。

簡短的說，這個問題的解決方案是為了查找每個符號的通用程度，我們建立一個未壓縮數據的柱狀圖；通過遞歸拆分這個柱狀圖為兩部分來創建一個二叉樹，每個遞歸的一半應該和另一半具有同樣的權（權是 ∑ N K =1 符號數 k , N 是分之中符號的數量，符號數 k 是符號 k出現的次數 ）

這棵樹有兩個目的：

1． 編碼器使用這棵樹來找到每個符號最優的表示方法

2． 解碼器使用這棵樹唯一的標識在壓縮流中每個編碼的開始和結束，其通過在讀壓縮數據位的時候自頂向底的遍歷樹，選擇基於數據流中的每個獨立位的分支，一旦一個到達葉子節點，解碼器知道一個完整的編碼已經讀出來了。

壓縮後的數據流是 24 位（三個位元組），原來是 80 位（ 10 個位元組）。當然，我應該存儲哈夫曼樹，這樣解碼器就能夠解碼出對應的壓縮流了，這就使得該例子中的真正數據流比輸入的流數據量大。這是相對較短的數據上的副作用。對於大數據量來說，上面的哈夫曼樹就不佔太多比例了。

解碼的時候，從上到下遍歷樹，為壓縮的流選擇從左 / 右分支，每次碰到一個葉子節點的時候，就可以將對應的位元組寫到解壓輸出流中，然後再從根開始遍歷。

2.2 實現
哈夫曼編碼器可以在基本壓縮庫中找到，其是非常直接的實現。

這個實現的基本缺陷是：

1． 慢位流實現

2． 相當慢的解碼（比編碼慢）

3． 最大的樹深度是 32 （編碼器在任何超過 32 位大小的時候退出）。如果我不是搞錯的話，這是不可能的，除非輸出的數據大於 2 32位元組。

另一方面，這個實現有幾個優點：

1． 哈夫曼樹以一個緊密的形式每個符號要求 12 位（對於 8 位的符號）的方式存儲，這意味著最大的頭為 384 。

2． 編碼相當容易理解

哈夫曼編碼在數據有噪音的情況（不是有規律的，例如 RLE ）下非常好，這中情況下大多數基於字典方式的編碼器都有問題。

『叄』 壓縮的演算法都有哪些

只有最常見的zip的，估計你都要研究上n久了。。。
文本文件一般有zip,rar,
網頁文件有htz
視頻文件有rm,avi
語音文件有mp3,
圖片文件有png,gif,jpg

這些都是文件壓縮的。。。。

------------------------------------

ZIP文件的總體格式
分文件頭信息+文件壓縮數據
中心目錄+中心目錄記錄結束符

1.分文件頭信息:
位元組數 描述
4 分文件頭信息標志(0x04034b50)
2 解壓縮所需版本
2 通用比特標志位(置比特0位=加密;置比特1位=使用壓
縮方式6,並使用8k變化目錄,否則使用4k變化目錄;置比特2位=使用壓
縮方式6,並使用3個ShannonFano樹對變化目錄輸出編碼,否則使用2個
ShannonFano樹對變化目錄輸出編碼,其它比特位未用)
2 壓縮方式(0=不壓縮,1=縮小,2=以壓縮因素1縮小,3=以
壓縮因素2縮小,4=以壓縮因素3縮小,5=以壓縮因素4縮小,6=自展)
2 文件最後修改時間
2 文件最後修改日期
4 32位校驗碼
4 壓縮文件大小
4 未壓縮文件大小
2 文件名長
2 擴展段長
? 文件名(不定長)
? 擴展段(不定長)

2.中心目錄結構
文件頭信息...中心目錄記錄結束符
文件頭:
位元組數 描述
4 中心文件頭信息標志(0x02014b50)
2 主機操作系統(高位位元組表示主機操作系統,低位字
節表示ZIP壓縮軟體版本號,其值除以10表示主版本號,其值模10表示
次版本號。0=MS-DOS,OS/2 FAT文件系統,1=Ami ga,2=VMS,3=Unix及
變種,4=VM/CMS,5=AtariST,6=OS/2 HPFS,7=Macintosh,8=Z-System,9
=C P/M,10-255未用)
2 解壓縮所需版本
2 通用比特標志
2 壓縮方式
2 文件最後修改時間(用標準的MS-DOS時間日 期格式
編碼)
2 文件最後修改日期
4 32位校驗碼(使用David Schwaderer的CRC-32演算法產
生)
4 壓縮文件大小
4 未壓縮文件大小
2 文件名長
2 擴展段長
2 文件注釋長(分別為文件名長,擴展段,注釋 段,小於
64K)
2 磁碟起始號(本文件在磁碟中的起始號)
2 內部文件屬性(最低位若置1,表示為ASC文本,否則為
二進制數據,其它位未用)
4 外部文件屬性(依賴於主機操作系統)
4 分文件頭相對位移
? 文件名(不定長)
? 擴展段(不定長,用於未來擴展,低版本為0長)
? 文件注釋(不定長)

3.中心目錄記錄結束符
位元組數 描述
4 中心目錄標記結束符(0x06054b50)
2 磁碟號(其中包括中心目錄結束記錄)
2 磁碟中心目錄起始號
2 磁碟中心目錄入口總數
2 中心目錄入口總數(ZIP文件中的文件總數)
2 整個中心目錄大小
4 關於起始磁碟號的中心目錄初始偏移
2 ZIP文件注釋長度
? ZIP文件注釋(不定長)

加密方法
PKZIP中使用的加密方法由Roger Schlafly提供。ZIP文件在解壓
縮前必須先解密。每個加密文件具有一個12位元組的加密文件頭擴展信
息,存儲於數據區的起始位置,加密前先設置一個起始值,然後被三個3
2位的密鑰加密。密鑰被使用者提供的口令初始化。12個位元組加密之
後,由PKZIP的偽隨機數產生方法,結合PKZIP中使用CRC-32演算法對密鑰
進行更新。
具體實施分為三步:

1.用口令對三個32位密鑰初始化。
K(0)=305419896,K(1)=591751049,K(2)=878082192
循環 for i=0 to length(password)-1
調用更新密鑰函數 update_keys(password(i))
結束循環(循環口令長度次)
其中更新密鑰函數為:
update_keys(char):
Key(0)=crc32(key(0),char)
Key(1)=Key(1)+(Key(0)& 000000ffH)
Key(1)=Key(1)*134775813+1
Key(2)=crc32(Key(2),Key(1)〉〉24)
end update_keys
CRC32函數中,給定一個4位元組的CRC值和一個字元,返回一個由CRC
-32演算法更新的CRC。具體為:
crc32(c,b)=crc32tab[(c^b)&0xff]^(c>>8),crc32tab[256]的值
為固定的256個4位元組數。

2.讀取並加密12位元組的加密頭,再次對密鑰進行初始化。
將12個位元組的加密頭讀入緩沖區buffer(0)至buffer(11),循環fo
r i=0 to 11
C=buffer(i)^decrypt_byte()
update_keys(C)
buffer(i)=C
結束循環(循環12次)
其中的decrypt_byte()函數為:
unsigned char decrypt_byte()
local unsigned short temp
temp=Key(2)¦2
decrypt_byte=((temp*(temp^1))>>8)&0xff
end decrypt_byte
該步結束後,緩沖區中最後的二個位元組buffer(10)和buffer(11)
將成為加密文件校驗碼的二個最高位(按低至高順序存放)。對ZIP加
密文件進行解壓縮前,PKUNZIP軟體將使用者提供的口令按上述二個步
驟進行處理,得到的結果與校驗碼的二個高位位元組進行比較,只有當提
供了正確的口令時,結果一致,才能進行後續的解壓縮過程,否則,PKZI
P報告錯誤信息,程序自動結束。

3.讀取壓縮的數據流並以加密密鑰對其進行加密。
壓縮數據流按下述過程加密:
循環 直至數據流結束
C=數據流的一個位元組
temp=C^decrypt_byte()
update_keys(temp)
輸出temp
結束循環

『肆』 壓縮器的工作原理

壓縮器(Compressor)的主要功能是衰減強度超過了給定門限的強信號，減小了信號的動態范同；而擴展器(Expander)則是衰減強度小於給定門限的弱信號，增加了信號的動態范圍。顯然這里壓縮、擴展是對應信號的動態范圍改變而言的，因此它們有時被稱為「動態范圍處理器」。 [2]
從本質上講，壓縮器(Compressor)是一種自動音量控制設備，能夠減小聲音的動態范圍。在現有的錄音棚中，壓縮器幾乎是必要沒備。壓縮器的面板上有幾個重要的控制參數，其中之一是閥值。簡單地說，閥值是允許用戶自由指定的一個臨界電平值，當輸入電平高於這個值的時候，壓縮器才開始工作。如果輸入信號的電平低於閥值，那麼壓縮器就會自動停止。因此，這里傳達出的一個重要信息就是壓縮器並不是一直都處於工作狀態的(特殊情況除外)。如果輸入信號電平過低，將永遠不會達到壓縮閾值；如果輸入信號電平過高，壓縮器將嚴重製約信號的動態范圍，影響聲音在動態上的表現。壓縮比決定壓縮器的壓縮強度，換句話說它代表的是壓縮器將壓低多少超過閥值的音頻信號。例如，5：1的壓縮比意味著，如果輸人信號在當前的基礎上增加到10倍．那麼輸出信號的電平相應地只增加到兩倍。
另外兩個重要的參數分別是建立時問和釋放時問。建立時間指的是，當輸人信號超過閾值後壓縮器由啟動到正常壓縮狀態所用的時間；釋放時間指的是，當輸人信號下降到閾值之下後壓縮器由壓縮狀態恢復到不工作狀態所需要的時間。釋放時間是一個至關重要的參數，因為如果將釋放時間設置得過大，就會產生泵音效應，尤其當前一個音較響而後一個音較弱時，這種現象尤為明顯。

『伍』 壓縮器是

動態范圍壓縮器（dynamic range compressor）
指在有些裝設有杜比數字（DD）解碼功能的功放接收機和前置放大器中採用的一種電路。系用來減少音量的峰值和增加低電平聲音的音量。深夜為了不影響鄰居或家人的休息，便可以使用動態范圍壓縮器來聆聽音樂和觀看影院節目。此時對於那些低電平的聲音，將仍能清晰可聞。
在目前數字音頻處理方面，多數音頻處理器，數字功放晶元等也都包含這種演算法，並可以控制動態范圍壓縮的比率，將系統輸出的最大功率限制在一個固定范圍。這樣可有效避免大動態信號造成的過載以及燒壞揚聲器。

『陸』 有誰知道,JPEG壓縮編碼演算法的主要步驟

JPEG壓縮編碼演算法的主要計算步驟如下：

1.正向離散餘弦變換(FDCT)。

2.量化(quantization)。

3.Z字形編碼(zigzag scan)。

4.使用差分脈沖編碼調制(differential pulse code molation，DPCM)對直流系數(DC)進行編碼。

5.使用行程長度編碼(run-length encoding，RLE)對交流系數(AC)進行編碼。

6.熵編碼(entropy coding)。

2. 量化

量化是對經過FDCT變換後的頻率系數進行量化。量化的目的是減小非「0」系數的幅度以及增加「0」值系數的數目。量化是圖像質量下降的最主要原因。

對於有損壓縮演算法，JPEG演算法使用均勻量化器進行量化，量化步距是按照系數所在的位置和每種顏色分量的色調值來確定。因為人眼對亮度信號比對色差信號更敏感，因此使用了兩種量化表：亮度量化值和色差量化值。此外，由於人眼對低頻分量的圖像比對高頻分量的圖像更敏感，因此圖中的左上角的量化步距要比右下角的量化步距小。

3. Z字形編排

量化後的系數要重新編排，目的是為了增加連續的「0」系數的個數，就是「0」的遊程長度，方法是按照Z字形的式樣編排，如圖5-17所示。這樣就把一個8 ? 8的矩陣變成一個1 ? 64的矢量，頻率較低的系數放在矢量的頂部。

4. 直流系數的編碼

8 ? 8圖像塊經過DCT變換之後得到的DC直流系數有兩個特點，一是系數的數值比較大，二是相鄰8 ? 8圖像塊的DC系數值變化不大。根據這個特點，JPEG演算法使用了差分脈沖調制編碼(DPCM)技術，對相鄰圖像塊之間量化DC系數的差值(Delta)進行編碼，

Delta＝DC(0, 0)k-DC(0, 0)k-1 ........ (5-5)

5. 交流系數的編碼

量化AC系數的特點是1 ? 64矢量中包含有許多「0」系數，並且許多「0」是連續的，因此使用非常簡單和直觀的遊程長度編碼(RLE)對它們進行編碼。

JPEG使用了1個位元組的高4位來表示連續「0」的個數，而使用它的低4位來表示編碼下一個非「0」系數所需要的位數，跟在它後面的是量化AC系數的數值。

6. 熵編碼

使用熵編碼還可以對DPCM編碼後的直流DC系數和RLE編碼後的交流AC系數作進一步的壓縮。

在JPEG有損壓縮演算法中，使用霍夫曼編碼器來減少熵。使用霍夫曼編碼器的理由是可以使用很簡單的查表(lookup table)方法進行編碼。壓縮數據符號時，霍夫曼編碼器對出現頻度比較高的符號分配比較短的代碼，而對出現頻度較低的符號分配比較長的代碼。這種可變長度的霍夫曼碼表可以事先進行定義。

『柒』 壓縮器有哪幾個主要參數

一、閥值電平

閥值電平指壓限器控製作用的信號電平，這個電平的確是非常重要的，選擇太低，則信號的大 部分時間都處於壓縮狀態，會使信號失真，選得太高則達不到防止削波的目的。

二、壓縮比

壓縮比是指在閥值電平以上壓縮器開始壓縮工作後，其輸入信號變化的分貝數和輸出信號變化 的分貝數之比，如2:1，3:1，壓縮比越大。

則在發著以上的輸入信號變化時，輸出信號變化越小，壓縮比一般應從小壓縮比開始選，因為壓縮比越大，引起的失真越大，一般可選2:1或 3:1，只有在信號峰值因數很大時才選較大壓縮比。

三、壓縮啟動時間

壓縮器啟動時間是指當信號達到閥值電平壓縮器進入工作狀態的63%所需時間，此時間一般 是在100us-10ms之間，時間過短則會導致節目過分被壓縮，影響動態效果，過長則會產生可 感覺到的起始觸感，產生不自然的「音頭加重」現象。

四、壓縮恢復時間

壓縮恢復時間是指當信號退出閥值電平，壓縮器開始退出壓縮工作，其退到正常狀態的37% 所需時間，恢復時間一般為0.1s至幾秒，時間過短會產生可感覺到的電平變化，造成喘息效 應，時間過長，則將破壞音源的實際動態變化狀況。

工作原理：

壓縮器(Compressor)的主要功能是衰減強度超過了給定門限的強信號，減小了信號的動態范同；而擴展器(Expander)則是衰減強度小於給定門限的弱信號，增加了信號的動態范圍。顯然這里壓縮、擴展是對應信號的動態范圍改變而言的，因此它們有時被稱為「動態范圍處理器」。

『捌』 window zip和rar兩種壓縮方式的區別等詳細情況

4月14日，年僅37歲的菲利普·卡茲（Philip Katz）被人發現倒斃在美國威斯康星州密爾沃基的一家汽車旅館里，據說死因是慢性酒精中毒引起的並發症。被人發現時，卡茲的手中仍握著一個烈性酒的酒瓶，在同一個房間里還發現了另外5個空酒瓶。這個噩耗很快就通過Internet傳遍了世界，很多認識和了解卡茲的人們以不同的方式對這個不幸的消息發表評論，寄託哀思。你一定會好奇地問，這個菲利普·卡茲究竟是何方神聖？
說起菲利普·卡茲這個名字，很多人可能都茫然不知；但是相信一提到電腦里、Internet上那比比皆是的ZIP壓縮文檔，不知道的人就很少了。菲利普·卡茲正是ZIP這個大名鼎鼎的壓縮文檔格式的發明人，他開發的ZIP壓縮軟體PKZip在DOS時代已風行世界，成為人們使用最頻繁的工具軟體之一。今天，人們從Internet下載的文件幾乎百分之百是用卡茲發明的ZIP壓縮演算法壓縮過的。卡茲的這個發明和貢獻，在使電腦之間交換信息的方式變得更加方便的同時，也大大降低了成本。特別是在今天這個Internet大行其道而通訊速度和帶寬又很難令人滿意的情況下，ZIP壓縮軟體得到世界各地的電腦愛好者的歡迎和喜愛就是極其自然的事情。看看身邊有多少人在使用PKZip和Winzip，你就能真切地體會到菲利普·卡茲對於我們今天使用計算機的方式帶來的巨大影響。

壓縮軟體的爭斗

現在回憶起來，ZIP壓縮文檔標准和PKZip壓縮軟體的問世頗有幾分戲劇性的傳奇色彩。
時光要回溯到1988年，那時候的Internet還處在蒙昧的「原始時代」的後期，當時網上的信息遠遠沒有今天豐富，只是極少數大學、研究機構和美國軍方才能夠享用的「特權」，一般電腦愛好者很難有機會接觸。那個時代，風靡北美大地的是通過電話線接入的老式「電子公告牌」（BBS）系統。熱衷於電腦的「發燒友」們就通過這些現在幾乎已經絕跡的方式來交換信息、交流思想和共享軟體。由於電話線的數據通訊帶寬很低、干擾大、穩定性很差，再加上當時流行的數據機（Modem）的速率也只有14.4Kbps，通過BBS傳輸體積較大的軟體一直是讓人頭疼的難題。正是基於這種原因，文檔壓縮技術就變得極為有用。壓縮後的文檔一般只有原來體積的幾分之一，可以大大減少傳輸的時間，也提高了可靠性。
當時流行的文檔壓縮技術有好幾種，比較流行的一種是新澤西州的SEA（(Systems Enhanced Associates）公司開發的ARC壓縮技術，壓縮生成的文檔的後綴是.ARC。ARC能很好地工作，但是你必須花錢去向SEA公司購買。1988年的時候，20歲出頭的菲利普·卡茲和很多同時代的年輕人一樣，穿梭於BBS的自由空間，沉迷於狂熱的編程體驗里。由於深受斷線的困擾，經常出沒於BBS的卡茲索性自己開發了一個與SEA的ARC完全兼容的共享壓縮軟體，取名PKARC。PKARC推出以後，很快就在BBS上廣為流傳，深受電腦愛好者們的喜愛。它和SEA ARC一樣工作得很不錯，最要命的是，由於是以共享軟體形式發布，人們可以隨意地使用，如果覺得滿意的話，才給作者付上很小的一筆注冊費用。有了近乎免費的PKARC，人們當然不會再為SEA的ARC付出不菲的代價。直接的後果是，很多人都轉向了PKARC——這個菲利普·卡茲的「業余作品」，SEA的ARC則銷量巨減。這無異於放倒了SEA的「搖錢樹」。惱羞成怒的SEA把卡茲告上了法庭，聲稱ARC壓縮標準是它的***，要求法庭禁止卡茲繼續傳播與其競爭的PKARC。雖然大多數的電腦愛好者都站在卡茲這邊，但法庭最終還是作出了不利於卡茲的判決。這個結果對卡茲是一個不小的打擊，他被迫放棄了PKARC這個心愛的軟體項目。最讓卡茲氣憤的是，他感覺自由創新的權利被人剝奪了。在朋友和同好們的鼓勵之下，憋足了一口氣的卡茲發誓要寫出一個更好的壓縮軟體，堂堂正正地擊敗SEA，而且要讓它輸得心服口服。這一次，卡茲的編程天才再次展露無遺。在短短的幾周以後，卡茲就拿出了後來統治整個BBS世界乃至Internet的ZIP。這個全新的PKZIP，使用卡茲發明的ZIP壓縮演算法，比SEA的ARC速度快了將近一倍，壓縮率也有一定的提高。卡茲繼承了PKARC的做法，將PKZIP免費發放，使其很快成為人見人愛的「殺手應用」（Killer Appliction）。沒有任何號召，遍及美國的各大BBS的管理員們都先後自發地將原有的.Arc壓縮文檔轉換成卡茲的.ZIP格式。經過不到半年時間，原來風光無限的SEA的ARC就幾乎絕跡了！取而代之的就是免費而且性能更加出眾的PKZIP。在失去眾多的用戶的支持以後，SEA迅速沉淪，最終銷聲匿跡。有人在後來對此事的評論中說道，「菲利普·卡茲無疑扮演了ARC掘墓人的角色，他為ARC的棺材釘上了最後一顆釘子！」
有關ZIP打敗強大的ARC和SEA的事跡成為了電腦愛好者們津津樂道的傳奇故事，疾惡如仇而又身手不凡的菲利普·卡茲也成為那些熱衷於編寫非凡程序的青年人的偶像。此後，卡茲一直繼續著對PKZIP的開發和維護工作。
PKZIP及其「克隆」作品Winzip成為Internet歷史上最有名的共享軟體之一，ZIP壓縮格式也成為壓縮文檔的事實標准，建立起一個統治Internet的「ZIP王朝」。菲利普·卡茲為世界貢獻了一個偉大的共享軟體，而他自己卻幾乎沒有從中獲得任何好處！

意外的結局

菲利普·卡茲的突然去世，對於他本人，對於他的家庭，乃至整個計算機界都是一個令人扼腕的悲劇。人們從此失去了一個才華橫溢的程序員，失去了一個傳奇英雄。噩耗傳出以後，在著名的IT網站ZDNET的新聞反饋頁面上，許許多多的網友留言體現了人們對卡茲早逝的惋惜和他生前成就的褒揚。正像來自南美洲巴拉圭的一位系統分析員在留言中寫到的那樣：「菲利普·卡茲和他的.ZIP壓縮格式必將得到永生。每一個.ZIP文件都將永遠記住菲利普·卡茲，因為每個ZIP文件的開頭都嵌有他姓名的字頭縮寫字母『PK』……」
也有報道指出，菲利普·卡茲的英年早逝除了與長年編寫軟體的巨大壓力有關外，也與其不良的個人生活方式關系密切。卡茲的直接死因，無疑是其長期酗酒惡習的悲劇結局。作為一名程序員，菲利普·卡茲獲得了巨大成功。但於之形成鮮明對比的是，在個人生活方面，卡茲卻一直很不順利。郁悶的結果讓卡茲覺得只能求助於酒精才能獲得解脫，而這最終讓他付出了生命的代價！數據壓縮和程序設計占據了卡茲短暫的生命歷程的絕大部分。他的傑作讓世界各地的人們從「壓縮」中獲益匪淺，然而，不幸的是，菲利普·卡茲的生命似乎也被令他得意非凡的壓縮軟體壓縮得那樣短暫。不知道這是不是造物弄人？

他們是程序員

人生如戲，戲如人生。對生活在無比精彩的計算機時代乃至互聯網時代的一代又一代和菲利普·卡茲一樣的天才程序員們來講，這句話如果改成「人生如程序，程序如人生」可能會更加貼切一些。這些在常人眼中聰明絕頂、特立獨行的古怪「傢伙」簡直就將程序看作了自己的生命，寫不出好用的軟體，對他們無疑是一場災難。在很大程度上，程序已經成為他們生命中不可割捨的一個最重要的組成部分了。這些充滿靈性的程序不再僅僅是玄妙無匹的0和1的排列組合體，它們根本就是嘔心瀝血的程序員們的人生哲學甚至整個人生的寫照。菲利普·卡茲或許只是一個極端的例子而已。
在這個劇烈變革的大時代中，我們並不缺乏偉大的程序員。他們中的絕大部分睿智、熱情、樂觀、無私，由於他們的天才與傑作，我們的生活和工作變得從未有過的精彩、豐富、刺激、舒適。被譽為「自由之神」的自由軟體陣營的精神領袖理查德·斯托曼（Richard Stallman）極力倡導的GNU計劃，吹響了計算機軟體進軍「共產主義社會」的號角；永遠擁有一張「娃娃臉」的比爾·蓋茨經過20多年的奮斗，成了不可企及的「微軟帝王」，每個人的桌上擺上一台PC的夢想很快就將成為現實；發明免費操作系統Linux的萊納斯·托沃茲（Linus Torvalds）讓人們看到了打破微軟霸權的希望曙光；被美譽為Internet上的「孤獨騎士」的拉里·沃（Larry Wall）因為偷懶而發明的Perl語言，成為目前Internet上使用最廣的編程語言……這些出色的程序員的故事，寫下來都是一段讓人不忍釋卷的傳奇。然而，使我們這個對信息的依賴日甚一日的世界良好運轉的是更多默默無聞地分布在世界各地的辛勤的程序員們。沒有這些忘我工作的人們，數字化社會就只能永遠是美好而遙遠的幻夢！有人將編程看成是一種藝術而並非技術，這在一定程度上不無道理。那是一種藝術家一般的靈感和激情的產物，美妙的程序是要用心、用血去書寫的。現在雖然時時聽到身邊的程序員悲嘆「我們吃的可是時光短暫的青春飯」，但真正因此「金盆洗手」而罷手不幹的還是少之又少。挑戰困難、勇於創新已經成為融入了每一個真正的程序員血液的特質，成為他們生命中不可分割的部分。他們也因為這些而贏得人們的尊敬。
在可敬、可愛有時甚至是可恨的程序員們的身上或許還存在這樣、那樣的問題，或許還遠遠談不上完美，但是我們不能對他們苛求太多。畢竟，他們和我們一樣，也是普普通通有血有肉的人。我們為他們創造的傑作和奇跡歡呼，為他們面對的失敗和失意惋惜，為他們遭遇的不幸和悲慘流淚，就因為他們是程序員！在這里，我們沒有任何誇耀或是貶低的潛台詞，因為那是世界上一部分真實人群的真實的生存狀態和生活方式，我們很難給其貼上對與錯或是好與壞的「標簽」，況且，我們也許根本就沒有這樣的權力。是非功過的評說，最有說服力的是時間……