bzcat - 将文件解压缩到标准输出
bzip2 [ -cdfkqstvzVL123456789 ] [ filenames ... ]
bunzip2 [ -fkvsVL ] [ filenames ... ]
bzcat [ -s ] [ filenames ... ]
bzip2recover filename
块排序文件压缩器
将文件解压到标准输出
从损坏的 bzip2 文件中恢复数据
bzip2 使用 Burrows-Wheeler 块排序文本压缩算法和 Huffman 编码来压缩文件。压缩通常比更传统的基于 LZ77/LZ78 的压缩器要好得多，并且接近 PPM 系列统计压缩器的性能。
命令行选项故意与 GNU gzip 的选项非常相似，但它们并不相同。
bzip2 期望命令行标志附带一个文件名列表。每个文件都被其自身的压缩版本替换，名称为“original_name.bz2”。每个压缩文件都具有与相应原始文件相同的修改日期、权限和所有权（如果可能），以便在解压缩时可以正确恢复这些属性。文件名处理是幼稚的，因为没有机制在缺乏这些概念或具有严格文件名长度限制的文件系统（例如 MS-DOS）中保留原始文件名、权限、所有权或日期。
bzip2 和 bunzip2 默认情况下不会覆盖现有文件。如果您希望发生这种情况，请指定 -f 标志。
如果未指定文件名，bzip2 将从标准输入压缩到标准输出。在这种情况下，bzip2将拒绝将压缩输出写入终端，因为这将是完全不可理解的，因此毫无意义。
bunzip2（或bzip2 -d）解压缩所有指定的文件。不是由 bzip2 创建的文件将被检测并忽略，并发出警告。 bzip2 尝试根据压缩文件的文件名猜测解压缩文件的文件名，如下所示：
filename.bz2 becomes filename
filename.bz becomes filename
filename.tbz2 becomes filename.tar
filename.tbz becomes filename.tar
anyothername becomes anyothername.out如果文件不以可识别的结尾之一结尾，.bz2、 .bz、 .tbz2 或 .tbz、 bzip2 抱怨它无法猜测原始文件的名称，并使用附加 .out 的原始名称。
与压缩一样，不提供文件名会导致从标准输入解压缩到标准输出。
bunzip2 将正确解压缩由两个或多个压缩文件串联而成的文件。结果是相应的未压缩文件的串联。还支持串联压缩文件的完整性测试 (-t)。
您还可以通过提供 -c 标志将文件压缩或解压缩到标准输出。多个文件可以像这样被压缩和解压缩。结果输出按顺序馈送到标准输出。以这种方式压缩多个文件会生成包含多个压缩文件表示的流。这样的流只有 bzip2 0.9.0 或更高版本才能正确解压缩。早期版本的 bzip2 将在解压缩流中的第一个文件后停止。
bzcat（或bzip2 -dc）将所有指定文件解压缩到标准输出。
bzip2 将从环境变量 BZIP2 和 BZIP 中按顺序读取参数，并在从命令行读取任何参数之前处理它们。这提供了一种提供默认参数的便捷方法。
即使压缩文件比原始文件稍大，也会始终执行压缩。小于大约 100 字节的文件往往会变得更大，因为压缩机制在 50 字节区域具有恒定的开销。随机数据（包括大多数文件压缩器的输出）以每字节约 8.05 位进行编码，提供约 0.5% 的扩展。
作为保护的自我检查，bzip2 使用 32 位 CRC 来确保文件的解压缩版本与原始版本相同。这可以防止压缩数据损坏，并防止 bzip2 中未检测到的错误（希望可能性很小）。数据损坏未被检测到的可能性很小，每个处理的文件的可能性约为四十亿分之一。但请注意，检查是在减压时进行的，因此它只能告诉您出现了问题。它无法帮助您恢复原始未压缩的数据。您可以使用bzip2recover尝试从损坏的文件中恢复数据。
返回值：0 表示正常退出，1 表示环境问题（未找到文件、无效标志、I/O 错误等），2 表示损坏的压缩文件，3 表示导致内部一致性错误（例如 bug） bzip2 引起恐慌。
压缩或解压缩到标准输出。
强制减压。 bzip2、 bunzip2 和 bzcat 实际上是同一个程序，并且根据使用的名称来决定采取什么操作。该标志会覆盖该机制，并强制bzip2解压缩。
-d 的补充：强制压缩，无论调用名称如何。
检查指定文件的完整性，但不解压缩它们。这确实执行了一次尝试减压并丢弃了结果。
强制覆盖输出文件。通常，bzip2 不会覆盖现有的输出文件。还强制 bzip2 断开文件的硬链接，否则它不会这样做。
bzip2 通常拒绝解压缩没有正确魔术头字节的文件。但是，如果强制 (-f)，它将不加修改地传递此类文件。这就是 GNU gzip 的行为方式。
在压缩或解压缩期间保留（不要删除）输入文件。
减少压缩、解压和测试的内存使用量。使用修改后的算法对文件进行解压缩和测试，每个块字节仅需要 2.5 个字节。这意味着任何文件都可以在 2300k 内存中解压缩，尽管速度大约是正常速度的一半。
在压缩过程中，-s 选择 200k 的块大小，这将内存使用限制在大约相同的数字，但会牺牲压缩率。简而言之，如果您的计算机内存不足（8 MB 或更少），请使用 -s 来执行所有操作。请参阅下面的内存管理。
禁止显示非必要的警告消息。与 I/O 错误和其他关键事件有关的消息不会被抑制。
详细模式——显示每个处理文件的压缩率。此外，-v 增加了详细程度，喷出大量主要用于诊断目的的信息。
显示软件版本、许可条款和条件。
压缩时将块大小设置为 100 k、200 k .. 900 k。解压时没有效果。请参阅下面的内存管理。 --fast 和 --best 别名主要用于 GNU gzip 兼容性。特别是，--fast 并不会让事情变得明显更快。并且 --best 仅选择默认行为。
将所有后续参数视为文件名，即使它们以破折号开头。这样您就可以处理名称以破折号开头的文件，例如：bzip2 -- -myfilename。
这些标志在 0.9.5 及更高版本中是多余的。他们对早期版本中的排序算法的行为提供了一些粗略的控制，这有时很有用。 0.9.5 及更高版本有一个改进的算法，使这些标志变得无关紧要。
bzip2 将大文件压缩为块。块大小会影响所实现的压缩比以及压缩和解压缩所需的内存量。标志 -1 到 -9 分别指定块大小为 100,000 字节到 900,000 字节（默认值）。在解压缩时，从压缩文件的标头中读取用于压缩的块大小，然后 bunzip2 为自己分配足够的内存来解压缩文件。由于块大小存储在压缩文件中，因此标志 -1 到 -9 与解压缩无关并因此被忽略。
压缩和解压缩要求（以字节为单位）可估计为：
Compression: 400k + ( 8 x block size )
Decompression: 100k + ( 4 x block size ), or
100k + ( 2.5 x block size )较大的区块大小会导致边际收益迅速递减。大多数压缩来自前两三百千的块大小，在小型机器上使用 bzip2 时值得牢记这一事实。同样重要的是要认识到，解压缩内存要求是在压缩时通过选择块大小来设置的。
对于使用默认 900k 块大小压缩的文件，bunzip2 将需要大约 3700 kbytes 来解压缩。为了支持在 4 MB 计算机上解压缩任何文件，bunzip2 可以选择使用大约一半的内存（大约 2300 KB）进行解压缩。解压速度也会减半，因此您应该仅在必要时使用此选项。相关标志是-s。
一般来说，尝试使用内存限制允许的最大块大小，因为这样可以最大化实现的压缩。压缩和解压缩速度实际上不受块大小的影响。
另一个重要的一点适用于适合单个块的文件——这意味着您遇到的大多数文件都使用大块大小。由于文件小于块，因此所触及的实际内存量与文件的大小成正比。例如，使用标志 -9 压缩 20,000 字节长的文件将导致压缩器分配大约 7600k 的内存，但仅触及其中的 400k + 20000 * 8=560 kbytes。同样，解压缩器将分配 3700k，但仅触及 100k + 20000 * 4=180 kbytes。
下表总结了不同块大小的最大内存使用量。还记录了卡尔加里文本压缩语料库 14 个文件的总压缩大小，总计 3,141,622 字节。本专栏介绍了压缩如何随块大小变化的情况。这些数字往往低估了较大文件的较大块大小的优势，因为语料库以较小的文件为主。
Compress Decompress Decompress Corpus
Flag usage usage -s usage Size
-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 828642bzip2 以块的形式压缩文件，通常为 900kbytes 长。每个块都是独立处理的。如果介质或传输错误导致多块 .bz2 文件损坏，则可以从文件中未损坏的块中恢复数据。
每个块的压缩表示由 48 位模式定界，这使得可以合理确定地找到块边界。每个块还带有自己的 32 位 CRC，因此可以区分损坏的块和未损坏的块。
bzip2recover 是一个简单的程序，其目的是搜索 .bz2 文件中的块，并将每个块写入其自己的 .bz2 文件中。然后，您可以使用 bzip2 -t 测试生成的文件的完整性，并解压缩未损坏的文件。
bzip2recover 采用单个参数，即损坏文件的名称，并写入多个文件“rec00001file.bz2”、“rec00002file.bz2”等，其中包含提取的块。输出文件名经过精心设计，以便在后续处理中使用通配符（例如“bzip2 -dc rec*file.bz2 > returned_data”）以正确的顺序处理文件。
bzip2recover 应该最适合处理大型 .bz2 文件，因为这些文件将包含许多块。在损坏的单块文件上使用它显然是徒劳的，因为损坏的块无法恢复。如果您希望最大程度地减少因介质或传输错误而导致的任何潜在数据丢失，您可以考虑使用较小的块大小进行压缩。
压缩的排序阶段将文件中相似的字符串收集在一起。因此，包含很长的重复符号的文件，例如“aabaabaabaab ...”（重复数百次）可能会比正常情况下压缩得更慢。 0.9.5及以上版本在这方面比以前的版本要好得多。最坏情况和平均情况压缩时间之比约为 10:1。对于以前的版本，这个数字更像是 100:1。如果需要，您可以使用 -vvvv 选项来详细监控进度。
减压速度不受这些现象的影响。
bzip2 通常会分配几兆字节的内存进行操作，然后以相当随机的方式对其进行充电。这意味着压缩和解压缩的性能很大程度上取决于计算机处理缓存未命中的速度。正因为如此，为了降低失误率而对代码进行的小改动已经被观察到可以带来不成比例的巨大性能改进。我想bzip2将在具有非常大缓存的机器上表现最佳。
I/O 错误消息并没有发挥应有的帮助。 bzip2 努力检测 I/O 错误并干净地退出，但问题的细节有时似乎相当具有误导性。
本手册页适用于 bzip2 版本 1.0.8。 此版本创建的压缩数据与之前的公开版本（版本 0.1pl2、0.9.0、0.9.5、1.0）完全向前和向后兼容.0、1.0.1、1.0.2 及更高版本，但有以下例外：0.9.0 及更高版本可以正确解压缩多个串联的压缩文件。 0.1pl2 无法做到这一点；仅解压缩流中的第一个文件后它将停止。
1.0.2 之前的 bzip2recover 版本使用 32 位整数来表示压缩文件中的位位置，因此它们无法处理长度超过 512 MB 的压缩文件。 1.0.2 及更高版本在某些支持 64 位整数的平台（GNU 支持的目标和 Windows）上使用 64 位整数。要确定 bzip2recover 是否在构建时存在此类限制，请在不带参数的情况下运行它。无论如何，如果您可以将 MaybeUInt64 设置为无符号 64 位整数来重新编译它，那么您可以为自己构建一个无限版本。
朱利安·苏厄德，jseward@acm.org。
https://sourceware.org/bzip2/
bzip2 中体现的思想（至少）归功于以下人员：Michael Burrows 和 David Wheeler（用于块排序转换）、David Wheeler（同样用于 Huffman 编码器）、Peter Fenwick（对于原始 bzip 中的结构化编码模型， 以及许多改进），以及 Alistair Moffat、Radford Neal 和 Ian Witten（对于原始 bzip 中的算术编码器）。非常感谢他们的帮助、支持和建议。请参阅源代码分发中的手册以获取文档源的指针。 Christian von Roques 鼓励我寻找更快的排序算法，从而加快压缩速度。 Bela Lubkin 鼓励我提高最坏情况下的压缩性能。 Donna Robinson 将文档 XML 化。 bz* 脚本源自 GNU gzip 的脚本。许多人发送补丁，帮助解决可移植性问题，借出机器，提供建议，并且总体上很有帮助。