Provided by:
manpages-zh_1.5.1-1_all 
NAMEROW
bzip2, bunzip2 - 一種塊排序檔案壓縮軟體，v0.9.5
bzcat - 將檔案解壓縮至標準輸出
bzip2recover - 恢復損壞的 bzip2 檔案
`覽
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
yz
bzip2 採用 Burrows-Wheeler 塊排序文本壓縮算法和 Huffman
編碼方式壓縮檔案。 壓縮率一般比基於 LZ77/LZ78
的壓縮軟體好得多，其性能接近 PPM 族統p類 壓縮軟體。
命令行參數有意設p為非常接近 GNU gzip 的形式，但也不完全相同。
bzip2 從命令行讀入檔名和參數。 每蚗仵袕Q名為 "鴝l檔名.bz2"
的壓縮檔案替換。 每蚗Y檔案具有與嚓仵蚻萓P的蚹黈伅﹛B 權，
如果可能的話， 還具有相同的屬主， 因此在解壓縮時這些特性將正確地恢復。
在某些檔案系統中， 沒有權、 屬主或時間的概念， 或者對檔名的長度有嚴格-
制， 例如 MSDOS， 在這種情況下，bzip2 沒有保持嚓犰W、 屬主、 權-
以及時間的機制， 從這虓N義上說，bzip2 對檔名的處理是幼稚的。
bzip2 和 bunzip2 在預設情況下不覆誘w有的檔案。 如果想覆誘w有的檔案，-
n指定 -f 選項。
如果未指定檔名， bzip2
將壓縮來自標準輸入的數據並寫往標準輸出。在這種情況下， bzip2
會拒絕將壓縮結果寫往終端，因為這完全無法理解並且是沒有意義的。
bunzip2 (以及 bzip2 -d) 對所有指定的檔案進行解壓縮處理。不是由 bzip2
產生的檔案將被忽略，同時發出一蚅筆i訊息。 bzip2
按下列方式由壓縮檔名確定解壓後的檔名：
filename.bz2 解壓成 filename
filename.bz 解壓成 filename
filename.tbz2 解壓成 filename.tar
filename.tbz 解壓成 filename.tar
anyothername 解壓成 anyothername.out
如果檔名的延伸檔名不是下列之一： .bz2, .bz, .tbz2 或 .tbz, .bzip2
將抱怨無法確定鴝l檔名，並採用嚓犰W加 .out 作為解壓縮檔名。
在壓縮時，如果不提供檔名，bzip2
將從標準輸入讀取數據，壓縮結果寫往標準輸出。
bunzip2 能夠正確地解壓由兩茤峓韟h蚗Y檔案連在一起的檔案。
解壓的結果為相應的連在一起的未壓縮檔案。
bzip2 也支持對連在一起的壓縮檔案的完整性檢查(-t選項)。
同樣可採用 -c 選項將檔案壓縮或解壓縮至標準輸出。 多-
蚗仵蚰i通過這種方式壓縮或解壓縮。 輸出結果被依次送往標準輸出。
採用這種方式對多蚗仵蛌瑰Y將生成包含 多-
蚗Y檔案的數據流。這樣的數據流只能被 0.9.0 版或其後續版本的 bzip2
正確解壓。較扛岩貌 bzip2 會在解壓完第一蚗仵蚺妨嵹惜謘C
bzcat (或 bzip2 -dc) 將所有指定檔案解壓縮至標準輸出。
bzip2 可從環境變量 BZIP2 和 BZIP 中依次讀取參數，
並在命令行參數之前對其進行處理。 這是提供預設選項的方便途徑。
即使壓縮後的檔案略大於嚓仵蛂A 壓縮也總是照樣進行。 小於大約 100
字節的檔案壓縮後傾向於變大， 因為會有一 50 字節的數據頭。 對於隨機數據
（包括大多數壓縮軟 件的輸出）， 大約每字節壓成 8.05 位， 放大率約為
0.5%。
bzip2 採用 32 位 CRC 校驗碼作自我檢查，以確認解壓後的檔案與-
鴝l檔案相同。 這可用於檢測壓縮檔案是否損壞，並防止 bzip2
中未知的缺陷（運氣好的話這種可能性非常小）。
數據損壞而未檢測到的幾率非常之小， 對於每-
茬Q處理的檔案大約是四十億分之一。 檢查是在解壓縮時進行的，
因此它只能說明某茼a方出問題了。 它能幫助恢復鴝l未壓縮的數據。可以用
bzip2recover 來嘗試從損壞的檔案中恢復數據。
返回G正常退出返回 0， 出現環境問題返回 1
（檔案未找到，非法的選項，I/O錯誤等）， 返回 2
表明壓縮檔案損壞，出現導P bzip2 緊急退出的內部一-
P性錯誤（例如缺陷）時返回 3。
項
-c --stdout
將數據壓縮或解壓縮至標準輸出。
-d --decompress
強制解壓縮。 bzip2, bunzip2 以及 bzcat 實際上是同一-
茧{式，進行何種操作將根據程式名確定。
指定該選項後將不考慮這一機制，強制 bzip2 進行解壓縮。
-z --compress
-d 選項的補充：強制進行壓縮操作，而不管執行的是茧{式。
-t --test
檢查指定檔案的完整性，但並不對其解壓縮。
實際上將對數據進行實驗性的解壓縮操作，而不輸出結果。
-f --force
強制覆遛擖X檔案。通常 bzip2 不會覆誘w經存在的檔案。該選項還強制
bzip2 打破檔案的硬連接，預設情況下 bzip2 不會這麼做。
-k --keep
在壓縮或解壓縮時保留輸入檔案（不刪除這些檔案）。
-s --small
在壓縮、 解壓縮及檢查時減少記憶體用量。 採用一種-
蚰羲犖滫k進行壓縮和測試， 每蚍痗艨愯 2.5 茼r節。
這意味著任何檔案都可以在 2300k 的記憶體中進行解壓縮，
儘管速度只有通常情況下的一半。
在壓縮時，-s將選定 200k 的塊長度，記憶體用量也制在 200k 左右，
代價是壓縮率會飢C。
總之，如果機器的記憶體較少（8兆字節或更少），
可對所有操作都採用-s選項。參見下悸滌O憶體管理。
-q --quiet
壓制不南的警告訊息。屬於 I/O 錯誤及其它嚴-
咧顗澈H息將不會被壓制。
-v --verbose
詳盡模式 -- 顯示每茬Q處理檔案的壓縮率。 命令行中更多的 -v
選項將增加詳細的程度， 使 bzip2 顯示出釵h主n用於診斷目的信息。
-L --license -V --version
顯示軟體版本，野i証條款及條件。
-1 to -9
在壓縮時將塊長度設為 100 k、200 k .. 900 k。
對解壓縮沒有影響。參見下悸滌O憶體管理。
-- 將所有後悸漫R令行變量看作檔名，即使這些變量以減號"-"打頭。
可用這一選項處理以減號"-"打頭的檔名， 例如：bzip2 --
-myfilename.
--repetitive-fast --repetitive-best
這些選項在 0.9.5 及其以上版本中是多餘的。 在較扛漯岩誘丑A這兩-
蚇龠給黿滫k 的行為提供了一些粗糙的控制，有些情況下很有用。
0.9.5 及其以上版本採用了改進的算法而與這些選項無關。
Oz
bzip2 按照數據塊壓縮大檔案。
數據塊長度同時影響數據的壓縮率和壓縮及解壓縮時需n 的記憶體用量。 選項
-1 至 -9 將數據塊長度分別指定為 100,000 字節至 900,000（預設）字節。
在解壓縮時， 壓縮時使用的塊長度從壓縮檔案的頭中讀取， 同時 bunzip2
分配出閬n夠用的記憶體對檔案進行解壓縮。
由於數據塊長度保存在壓縮檔案中， 所以在解壓縮時不需n -1 至 -9
這些選項， 因而將被忽略。
可以按下悸漱膠’皫壓縮和解壓縮時的記憶體用量，單位為字節：
壓縮: 400k + ( 8 x 數據塊長度 )
解壓縮: 100k + ( 4 x 數據塊長度 ), 或
100k + ( 2.5 x 數據塊長度 )
大數據塊長度產生迅速縮小的臨界返回 (give rapidly diminishing marginal
returns)。 在小機器上使用 bzip2 時， 一蚧得記住的事實是，
大多數壓縮來自數據塊長度的前 200 或 300k。 另外南的一點是，
解壓縮時記憶體的需n量是在壓縮時用塊長度選項設定的。
對於預設用 900k 的數據塊長度壓縮的檔案， bunzip2 大約需n 3700k
字節的記憶體進行解壓縮。為支持一台 4MB 機器上任何檔案的解壓縮， bunzip2
有一蚇龠竣j約只需一半容量的記憶體，約 2300k 字節。 解壓縮速度同樣也-
飢C一半。 因此應該只在需n時採用該選項。相應的選項標誌為 -s。
一般來說，應盡量採用記憶體允釭熙怳j數據塊長度，
因為這能達到最好的壓縮率， 壓縮和解壓縮速度實質上不受塊長度的影響。
另一蚧得注意的問題是關於小於一蚍痗籅曮蛌瑰仵蛌滿A 也就是說， 所遇到的
大多數檔案使用一茪j數據塊。 由於檔案長度小於一蚍痗籅曮蛂A
實際使用到的記憶體與檔案長度成正比。 例如，採用 -9 選項壓縮一 20,000
字節的檔案時， 將分配 7600k 的記憶體， 但其中只用到了 400k+20000*8=560k
字節。同樣地，在解壓縮時將分配 3700k 記憶體，但只用到 100k + 20000 * 4
= 180 k 字節。
下表總結了不同數據塊長度下的記憶體用量。同時列出的還有 Calgary
文本壓縮語料 庫中的 14 蚗仵蛌瑰Y長度，這 14 蚗仵袤Y前總長度為
3,141,622 字節。 這些數據顯示了壓縮率是如何隨數據塊長度變化的。
由於這一語料庫主n由小檔案組成，
所以這些數字並沒有充分體現出大檔案情況下，
採用大數據塊所能達到的較高壓縮率的優勢。
壓縮時 解壓縮 解壓縮 -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
qla據
bzip2 按數據塊對數據進行壓縮，數據塊長度通常為 900k 字節。每-
蚍痗臛Q獨立地處理。 如果由於介質或傳輸錯誤導P多數據塊的 .bz2
檔案損壞，有可能將檔案中未損壞的 數據塊中的數據恢復。
壓縮後的數據塊以一 48 位的結構分界，因而有可能在合理的-
S圍內找到塊邊界。 每蚍痗穭]帶著自己的 32 位 CRC
校驗碼，因此可以區分損壞與未損壞的數據塊。
bzip2recover 是一蚋眾瑼熊{式，它的弁酮O在 .bz2
檔案中尋找數據塊，並將每蚍痗蘛g到 自己的 .bz2 檔案中。然後可以用
bzip2 -t 測試結果的完整性，將未損壞的部分解壓縮。
bzip2recover 只有一茤R令行變量，即損壞檔案的名字。輸出結果是一系列像
"rec0001file.bz2"、 "rec0002file.bz2" 這樣的檔案， 每-
蚗仵蚹t有從損壞檔案中找出的數據塊。 輸出檔名設-
p為在接下來的處理中可方便地使用通配符， 例如，"bzip2 -dc
rec*file.bz2>recovered_data"，可按正確的次序列出檔案。
bzip2recover 在處理大檔案時最有用， 因為大檔案含有很多數據塊。
顯然用它處理單蚍痗籅熒l壞檔案不會有任何結果， 因為一-
虓l壞的數據塊是無法恢復的。 如果想盡量減少潛在的由於介質及傳輸錯誤導-
P的數據損壞， 可以考慮採用較小的數據塊長度進行壓縮。
`解
在壓縮的排序階段， 相似的字符串將被聚集在一起。 因此， 對於包含很長-
契_符號 的檔案， 例如像 "aabaabaabaab......" 這樣的字符串（-
契_幾百次）， 壓縮速度會 比通常情況慢得多。 0.9.5
及其以上版本在處理這樣的契_時， 速度比以前版本提高 了很多。
最壞情況與尼§〞p下的壓縮時間之比約為 10:1。 對於以前的版本，
這一數字大約是 100:1 以上。你如果願意， 可採用 -vvvv
選項來非常詳細地監視這一過程。
解壓縮速度並不受這些現象的影響。
bzip2 通常分配出幾兆字節的記憶體用於處理數據，
對這些記憶體的訪問是以相當隨機的方式 進行的。 這意味著，
壓縮及解壓縮的性能在很大程度上取決於機器上處理高速緩存 未命中的速度。
因此， 已經觀察到對程式作很小的減少失敗率的改動會導-
P不成比例的很大的性能 上的提升。 我設想 bzip2
在有大量高速緩存機器上的性能最佳。
i
I/O 錯誤訊息並不是很有用。 bzip2 會盡量探測 I/O 錯誤訊息並幹凈地退出，
但問題的細節有時看上去很容易引起誤解。
本手冊馮A用於 0.9.5 版的 bzip2C 由這一版本的 bzip2
產生的壓縮數據與以前的公開版本 0.1pl2、0.9.0 完全相容， 但有一-
茖狴~：0.9.0 及其以上版本能正確解壓縮多茬s在一起的壓縮檔案，0.1pl2
則不能， 它將在解壓縮完數據流中的第一蚗仵蚺妨嵹惜謘C
bzip2recover 採用 32 位的整型數表示壓縮檔案中位的位置，
因此它無法處理大於 512 兆字節的檔案。 但這一問題很容易解決。
@者
Julian Seward, jseward@acm.org.
http://www.muraroa.demon.co.uk
bzip2 包含的想法及概念至少歸巧韝U列人： Michael Burrows 和 David
Wheeler（塊排序變換）， David Wheeler（Huffman 編碼器）， Peter
Fenwick（鴝l bzip 的結構編程模型及釵h改進），Alistair Moffat、 Ian
Witten（鴝l bzip 中的算法編碼）。 我非常感激他怐瑰飢U、 支持以及建議。
參見源發佈的手冊中有關文件來源中的線索。 Christian von Roques
曾鼓勵我尋找更快的排序算法， 以提高壓縮速度。 bela Lubkin
曾鼓勵我改進最壞情況下的壓縮性能。 很多人給我發來袑伂{式，
幫助解決移植問題， 租刉鷑飽A提出建議等。
[]
Liu JingSong <js-liu@263.net>
[]
2001/01/31
[Linux manUp]
http://cmpp.linuxforum.net
bzip2(1)