sourCEntral - mobile manpages

pdf

bzip2

NAME 命令名

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 對檔名的處理是幼稚的。

bzip2bunzip2 在預設情況下不覆蓋已有的檔案。 如果想覆蓋已有的檔案,要指定 −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 可從環境變量 BZIP2BZIP 中依次讀取參數, 並在命令行參數之前對其進行處理。 這是提供預設選項的方便途徑。

即使壓縮後的檔案略大於原檔案, 壓縮也總是照樣進行。 小於大約 100 字節的檔案壓縮後傾向於變大, 因為會有一個 50 字節的數據頭。 對於隨機數據 (包括大多數壓縮軟 件的輸出), 大約每字節壓成 8.05 位, 放大率約為 0.5%。

bzip2 採用 32 位 CRC 校驗碼作自我檢查,以確認解壓後的檔案與原始檔案相同。 這可用於檢測壓縮檔案是否損壞,並防止 bzip2 中未知的缺陷(運氣好的話這種可能性非常小)。 數據損壞而未檢測到的幾率非常之小, 對於每個被處理的檔案大約是四十億分之一。 檢查是在解壓縮時進行的, 因此它只能說明某個地方出問題了。 它能幫助恢復原始未壓縮的數據。可以用 bzip2recover 來嘗試從損壞的檔案中恢復數據。

返回值:正常退出返回 0, 出現環境問題返回 1 (檔案未找到,非法的選項,I/O錯誤等), 返回 2 表明壓縮檔案損壞,出現導致 bzip2 緊急退出的內部一致性錯誤(例如缺陷)時返回 3。

選項

−c --stdout

將數據壓縮或解壓縮至標準輸出。

−d --decompress

強制解壓縮。 bzip2, bunzip2 以及 bzcat 實際上是同一個程式,進行何種操作將根據程式名確定。 指定該選項後將不考慮這一機制,強制 bzip2 進行解壓縮。

−z --compress

−d 選項的補充:強制進行壓縮操作,而不管執行的是哪個程式。

−t --test

檢查指定檔案的完整性,但並不對其解壓縮。 實際上將對數據進行實驗性的解壓縮操作,而不輸出結果。

−f --force

強制覆蓋輸出檔案。通常 bzip2 不會覆蓋已經存在的檔案。該選項還強制 bzip2 打破檔案的硬連接,預設情況下 bzip2 不會這麼做。

−k --keep

在壓縮或解壓縮時保留輸入檔案(不刪除這些檔案)。

−s --small

在壓縮、 解壓縮及檢查時減少記憶體用量。 採用一種修正的算法進行壓縮和測試, 每個數據塊僅需要 2.5 個字節。 這意味著任何檔案都可以在 2300k 的記憶體中進行解壓縮, 儘管速度只有通常情況下的一半。

在壓縮時,−s將選定 200k 的塊長度,記憶體用量也限制在 200k 左右, 代價是壓縮率會降低。 總之,如果機器的記憶體較少(8兆字節或更少), 可對所有操作都採用−s選項。參見下面的記憶體管理。

−q --quiet

壓制不重要的警告訊息。屬於 I/O 錯誤及其它嚴重事件的信息將不會被壓制。

−v --verbose

詳盡模式 -- 顯示每個被處理檔案的壓縮率。 命令行中更多的 −v 選項將增加詳細的程度, 使 bzip2 顯示出許多主要用於診斷目的信息。

−L --license -V --version

顯示軟體版本,許可証條款及條件。

−1 to −9

在壓縮時將塊長度設為 100 k、200 k .. 900 k。 對解壓縮沒有影響。參見下面的記憶體管理。

−-

將所有後面的命令行變量看作檔名,即使這些變量以減號"-"打頭。 可用這一選項處理以減號"-"打頭的檔名, 例如:bzip2 −- −myfilename.

−-repetitive-fast --repetitive-best

這些選項在 0.9.5 及其以上版本中是多餘的。 在較早的版本中,這兩個選項對排序算法 的行為提供了一些粗糙的控制,有些情況下很有用。 0.9.5 及其以上版本採用了改進的算法而與這些選項無關。

記憶體管理

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 AT acm DOT 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 AT 263 DOT net>

[中文版最新更新]

2001/01/31

[中國 Linux 論壇 man手冊頁翻譯計劃]

http://cmpp.linuxforum.net

pdf