塊排序這一路壓縮格式的結構，三十年來幾乎沒動過：單塊上限停在幾百 KB，一輪只能用一個執行緒，碼長還得按整位元組計算。BZip3 把這幾樣一起掀開重做：塊上限放到 511 MiB，整條流水線換新，平行處理幾乎等於白送。

先把塊的邊界放開

無損壓縮的取捨一向擺在明面上：要壓得更小，多半得拿時間與記憶體去換。BZip3 是一款面向文字與原始碼的命令列壓縮工具，同時附上一套用 C 寫成的壓縮函式庫。它把「一次能看多遠」當作頭一個旋鈕：單塊大小可從 1 MiB 調到 511 MiB，預設 16 MiB。塊越大，長距離的重複越有機會被抓到，壓縮率也跟著往上。代價寫在官方文件裡：壓縮與解壓的記憶體佔用都約等於塊大小的六倍，而且解壓需要多少記憶體，在壓縮的那一刻就被塊大小定死了，調參之前得先看目標機器扛不扛得住。

三段演算法疊出來的流水線

流水線分三段。入口先做前置處理，遊程編碼與倫佩爾-齊夫預測各走一遍：前者收拾連續重複的位元組，後者按 LZ77 式字串比對找出遠處相同的片段，再按 PPM 式的上下文建模估計下一個位元組的可能取值。這一步趕在變換之前把長重複剝掉，素材越冗餘，收益越明顯。中段是塊排序變換，由後綴陣列建構完成，把相似的上下文聚到相鄰位置，於是排在後面的那個簡單低階預測器也能吃到高階統計特性。出口是熵編碼：算術編碼配上零階上下文混合，按上下文把多路機率估計混在一起，整數碼長帶來的損失也就沒了。

塊的上限就是在這三段之間找平衡點。同一份語料換成不同的塊上限，壓縮率能差出不少；官方的建議是儘量把塊調到記憶體允許的上限，因為解壓速度幾乎不受塊大小影響。

把記憶體與平行交給使用者調

塊與塊之間互不依賴，平行因此幾乎是白送的：命令列給一個工作者數量參數，每個工作者負責一個塊，預設只開一個，取值範圍到 64 為止。日常備份腳本裡開四到八個工作者，壓縮時間就能成倍往下掉。完整性上也沒省料，每個塊都帶 CRC32 校驗，解壓時逐位元組核對結果；檔案格式的固定開銷是每個檔案 9 位元組、每個塊 9 到 17 位元組，官方另外說明隨機資料的膨脹一般控制在 0.8% 以內，碰上壓不動的資料，檔案也不會被撐大多少。

官方基準裡的數字

專案方公開了一份基準列表，把性質各不相同的語料放進去跑了一遍。一眼能看出來的是「壓縮後體積 ÷ 原始體積」這個比值：內附原始碼包從 501,760 位元組壓到 72,320 位元組，只剩一成四；中文長文本壓到一成六；而音訊資料只壓到三成五，虛擬機磁碟映像更是停在五成。這說明它並非萬靈丹，官方把定位寫得很直白：對文字與原始碼格外擅長。

授權、平台與配套命令

授權是 LGPLv3，執行期程式碼的著作權歸 Kamila Szewczyk；執行期函式庫裡另外打包了 Apache 2.0 與 BSD 二條款授權的元件，編譯期腳本走 GPL 三條款加 Autoconf 例外，專案自己也說明整體按 LGPLv3 單一授權發布，不做雙重授權。平台覆蓋比想像中寬：官方測過 x86、x86_64、armv6、armv7、aarch64、ppc64le、mips、mips64、sparc 與 s390x 十種架構，發布資產裡直接給了 Windows 的 32 位與 64 位執行檔，外加一份 64 位 Linux 執行檔，macOS 上則可以從套件管理器取用。命令列選項刻意做得像傳統的類 Unix 壓縮工具：預設動作是壓縮，-b 調塊大小，-j 調工作者數量，-d 解壓，-t 只做校驗，-B 批次處理。隨原始碼包還帶六支配套命令，bunzip3 專門負責解壓，bz3cat 把內容打到標準輸出，bz3grep 在壓縮包裡直接搜文字，bz3less、bz3more 與 bz3most 把解壓結果送進分頁器。目前版本 1.5.4 發布於 2026 年 9 月 7 日，倉庫從 2022 年 5 月起一直在更新。

BZip3 沒打算在壓縮率上堆出什麼奇蹟，它做的是把幾個長期被忍受的限制一併鬆開：塊放大到 511 MiB，前置處理多一層預測，熵編碼換成上下文混合，平行交給使用者自己調。它合適的場景也很明確：原始碼、日誌與長文本這類重複度高、又捨不得丟字的東西。