| bzip2(1) | General Commands Manual | bzip2(1) |
bzip2, bunzip2 -
一種塊排序文件壓縮軟件，v0.9.5
bzcat -
將文件解壓縮至標準輸出
bzip2recover - 恢復損壞的 bzip2
文件
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames
... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
bzip2 採用 Burrows-Wheeler 塊排序文本壓縮算法和 Huffman 編碼方式壓縮文件。 壓縮率一般比基於 LZ77/LZ78 的壓縮軟件好得多，其性能接近 PPM 族統計類 壓縮軟件。
命令行參數有意設計爲非常接近 GNU gzip 的形式，但也不完全相同。
bzip2 從命令行讀入文件名和參數。 每個文件被名爲 "原始文件名.bz2" 的壓縮文件替換。 每個壓縮文件具有與原文件相同的修改時間、 權限， 如果可能的話， 還具有相同的屬主， 因此在解壓縮時這些特性將正確地恢復。 在某些文件系統中， 沒有權限、 屬主或時間的概念， 或者對文件名的長度有嚴格限制， 例如 MSDOS， 在這種情況下，bzip2 沒有保持原文件名、 屬主、 權限以及時間的機制， 從這個意義上說，bzip2 對文件名的處理是幼稚的。
bzip2 和 bunzip2 在缺省情況下不覆蓋已有的文件。 如果想覆蓋已有的文件，要指定 -f 選項。
如果未指定文件名， bzip2 將壓縮來自標準輸入的數據並寫往標準輸出。在這種情況下， bzip2 會拒絕將壓縮結果寫往終端，因爲這完全無法理解並且是沒有意義的。
bunzip2 (以及 bzip2 -d) 對所有指定的文件進行解壓縮處理。不是由 bzip2 產生的文件將被忽略，同時發出一個警告信息。 bzip2 按下列方式由壓縮文件名確定解壓後的文件名：
filename.bz2 解壓成 filename
filename.bz 解壓成 filename
filename.tbz2 解壓成 filename.tar
filename.tbz 解壓成 filename.tar
anyothername 解壓成 anyothername.out
如果文件名的後綴不是下列之一： .bz2, .bz, .tbz2 或 .tbz, .bzip2 將抱怨無法確定原始文件名，並採用原文件名加 .out 作爲解壓縮文件名。
在壓縮時，如果不提供文件名，bzip2 將從標準輸入讀取數據，壓縮結果寫往標準輸出。
bunzip2
能夠正確地解壓由兩個或更多個壓縮文件連在一起的文件。
解壓的結果爲相應的連在一起的未壓縮文件。
bzip2
也支持對連在一起的壓縮文件的完整性檢查(-t選項)。
同樣可採用 -c 選項將文件壓縮或解壓縮至標準輸出。 多個文件可通過這種方式壓縮或解壓縮。 輸出結果被依次送往標準輸出。 採用這種方式對多個文件的壓縮將生成包含 多個壓縮文件的數據流。這樣的數據流只能被 0.9.0 版或其後續版本的 bzip2 正確解壓。較早版本的 bzip2 會在解壓完第一個文件之後停止。
bzcat (或 bzip2 -dc) 將所有指定文件解壓縮至標準輸出。
bzip2 可從環境變量 BZIP2 和 BZIP 中依次讀取參數， 並在命令行參數之前對其進行處理。 這是提供缺省選項的方便途徑。
即使壓縮後的文件略大於原文件， 壓縮也總是照樣進行。 小於大約 100 字節的文件壓縮後傾向於變大， 因爲會有一個 50 字節的數據頭。 對於隨機數據 （包括大多數壓縮軟 件的輸出）， 大約每字節壓成 8.05 位， 放大率約爲 0.5%。
bzip2 採用 32 位 CRC 校驗碼作自我檢查，以確認解壓後的文件與原始文件相同。 這可用於檢測壓縮文件是否損壞，並防止 bzip2 中未知的缺陷（運氣好的話這種可能性非常小）。 數據損壞而未檢測到的機率非常之小， 對於每個被處理的文件大約是四十億分之一。 檢查是在解壓縮時進行的， 因此它只能說明某個地方出問題了。 它能幫助恢復原始未壓縮的數據。可以用 bzip2recover 來嘗試從損壞的文件中恢復數據。
返回值：正常退出返回 0， 出現環境問題返回 1 （文件未找到，非法的選項，I/O錯誤等）， 返回 2 表明壓縮文件損壞，出現導致 bzip2 緊急退出的內部一致性錯誤（例如缺陷）時返回 3。
在壓縮時，-s將選定 200k 的塊長度，內存用量也限制在 200k 左右， 代價是壓縮率會降低。 總之，如果機器的內存較少（8兆字節或更少）， 可對所有操作都採用-s選項。參見下面的內存管理。
bzip2 按照數據塊壓縮大文件。 數據塊長度同時影響數據的壓縮率和壓縮及解壓縮時需要 的內存用量。 選項 -1 至 -9 將數據塊長度分別指定爲 100,000 字節至 900,000（缺省）字節。 在解壓縮時， 壓縮時使用的塊長度從壓縮文件的頭中讀取， 同時 bunzip2 分配出剛好夠用的內存對文件進行解壓縮。 由於數據塊長度保存在壓縮文件中， 所以在解壓縮時不需要 -1 至 -9 這些選項， 因而將被忽略。
可以按下面的公式估計壓縮和解壓縮時的內存用量，單位爲字節：
壓縮: 400k + ( 8 x 數據塊長度 )
解壓縮: 100k + ( 4 x
數據塊長度 ), 或
100k + ( 2.5 x 數據塊長度 )
大數據塊長度產生迅速縮小的臨界返回 (give rapidly diminishing marginal returns)。 在小機器上使用 bzip2 時， 一個值得記住的事實是， 大多數壓縮來自數據塊長度的前 200 或 300k。 另外重要的一點是， 解壓縮時內存的需要量是在壓縮時用塊長度選項設定的。
對於缺省用 900k 的數據塊長度壓縮的文件， bunzip2 大約需要 3700k 字節的內存進行解壓縮。爲支持一臺 4MB 機器上任何文件的解壓縮， bunzip2 有一個選項大約只需一半容量的內存，約 2300k 字節。 解壓縮速度同樣也降低一半。 因此應該只在需要時採用該選項。相應的選項標誌爲 -s。
一般來說，應儘量採用內存允許的最大數據塊長度， 因爲這能達到最好的壓縮率， 壓縮和解壓縮速度實質上不受塊長度的影響。
另一個值得注意的問題是關於小於一個數據塊長度的文件的， 也就是說， 所遇到的 大多數文件使用一個大數據塊。 由於文件長度小於一個數據塊長度， 實際使用到的內存與文件長度成正比。 例如，採用 -9 選項壓縮一個 20,000 字節的文件時， 將分配 7600k 的內存， 但其中只用到了 400k+20000*8=560k 字節。同樣地，在解壓縮時將分配 3700k 內存，但只用到 100k + 20000 * 4 = 180 k 字節。
下表總結了不同數據塊長度下的內存用量。同時列出的還有 Calgary 文本壓縮語料 庫中的 14 個文件的壓縮長度，這 14 個文件壓縮前總長度爲 3,141,622 字節。 這些數據顯示了壓縮率是如何隨數據塊長度變化的。 由於這一語料庫主要由小文件組成， 所以這些數字並沒有充分體現出大文件情況下， 採用大數據塊所能達到的較高壓縮率的優勢。
壓縮時 解壓縮 解壓縮 -s
語料庫文件
Flag 內存用量 內存用量
選項內存用量
壓縮長度
-1 1200k 500k 350k 914704
-2 2000k 900k 600k 877703
-3 2800k 1300k 850k 860338
-4 3600k 1700k 1100k 846899
-5 4400k 2100k 1350k 845160
-6 5200k 2500k 1600k 838626
-7 6100k 2900k 1850k 834096
-8 6800k 3300k 2100k 828642
-9 7600k 3700k 2350k 828642
bzip2 按數據塊對數據進行壓縮，數據塊長度通常爲 900k 字節。每個數據塊被獨立地處理。 如果由於介質或傳輸錯誤導致多數據塊的 .bz2 文件損壞，有可能將文件中未損壞的 數據塊中的數據恢復。
壓縮後的數據塊以一個 48 位的結構分界，因而有可能在合理的範圍內找到塊邊界。 每個數據塊也帶着自己的 32 位 CRC 校驗碼，因此可以區分損壞與未損壞的數據塊。
bzip2recover 是一個簡單的程序，它的功能是在 .bz2 文件中尋找數據塊，並將每個數據塊寫到 自己的 .bz2 文件中。然後可以用 bzip2 -t 測試結果的完整性，將未損壞的部分解壓縮。
bzip2recover 只有一個命令行變量，即損壞文件的名字。輸出結果是一系列象 "rec0001file.bz2"、 "rec0002file.bz2" 這樣的文件， 每個文件含有從損壞文件中找出的數據塊。 輸出文件名設計爲在接下來的處理中可方便地使用通配符， 例如，"bzip2 -dc rec*file.bz2>recovered_data"，可按正確的次序列出文件。
bzip2recover 在處理大文件時最有用， 因爲大文件含有很多數據塊。 顯然用它處理單個數據塊的損壞文件不會有任何結果， 因爲一個損壞的數據塊是無法恢復的。 如果想盡量減少潛在的由於介質及傳輸錯誤導致的數據損壞， 可以考慮採用較小的數據塊長度進行壓縮。
在壓縮的排序階段， 相似的字符串將被聚集在一起。 因此， 對於包含很長重複符號 的文件， 例如象 "aabaabaabaab......" 這樣的字符串（重複幾百次）， 壓縮速度會 比通常情況慢得多。 0.9.5 及其以上版本在處理這樣的重複時， 速度比以前版本提高 了很多。 最壞情況與平均情況下的壓縮時間之比約爲 10:1。 對於以前的版本， 這一數字大約是 100:1 以上。你如果願意， 可採用 -vvvv 選項來非常詳細地監視這一過程。
解壓縮速度並不受這些現象的影響。
bzip2 通常分配出幾兆字節的內存用於處理數據， 對這些內存的訪問是以相當隨機的方式 進行的。 這意味着， 壓縮及解壓縮的性能在很大程度上取決於機器上處理高速緩存 未命中的速度。 因此， 已經觀察到對程序作很小的減少失敗率的改動會導致不成比例的很大的性能 上的提升。 我設想 bzip2 在有大量高速緩存機器上的性能最佳。
I/O 錯誤信息並不是很有用。 bzip2 會盡量探測 I/O 錯誤信息並乾淨地退出， 但問題的細節有時看上去很容易引起誤解。
本手冊頁適用於 0.9.5 版的 bzip2。 由這一版本的 bzip2 產生的壓縮數據與以前的公開版本 0.1pl2、0.9.0 完全兼容， 但有一個例外：0.9.0 及其以上版本能正確解壓縮多個連在一起的壓縮文件，0.1pl2 則不能， 它將在解壓縮完數據流中的第一個文件之後停止。
bzip2recover 採用 32 位的整型數表示壓縮文件中位的位置， 因此它無法處理大於 512 兆字節的文件。 但這一問題很容易解決。
Julian Seward, jseward@acm.org.
http://www.muraroa.demon.co.uk
bzip2 包含的想法及概念至少歸功於下列人員： Michael Burrows 和 David Wheeler（塊排序變換）， David Wheeler（Huffman 編碼器）， Peter Fenwick（原始 bzip 的結構編程模型及許多改進），Alistair Moffat、 Ian Witten（原始 bzip 中的算法編碼）。 我非常感激他們的幫助、 支持以及建議。 參見源發佈的手冊中有關文檔來源中的線索。 Christian von Roques 曾鼓勵我尋找更快的排序算法， 以提高壓縮速度。 bela Lubkin 曾鼓勵我改進最壞情況下的壓縮性能。 很多人給我發來修補程序， 幫助解決移植問題， 租借機器，提出建議等。
Liu JingSong <js-liu@263.net>
2001/01/31
http://cmpp.linuxforum.net
本頁面中文版由中文
man 手冊頁計劃提供。
中文 man
手冊頁計劃：https://github.com/man-pages-zh/manpages-zh