块排序压缩这套格式的结构三十年没怎么动过：单块上限停在几百 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，预处理加一层预测，熵编码换成上下文混合，并行交给使用者自己调。它合适的场景也很明确——源码、日志与长文本这类重复度高、又舍不得丢字的东西。