lzcat.1

XZ(1)

XZ Utils

XZ(1)

xz, unxz, xzcat, lzma, unlzma, lzcat - 压缩或解压缩 .xz 和 .lzma 文件

xz [option...] [file...]

unxz 等价于 xz --decompress.- xzcat 等价于 xz --decompress --stdout.- lzma 等价于 xz --format=lzma.- unlzma 等价于 xz --format=lzma --decompress.- lzcat 等价于 xz --format=lzma --decompress --stdout.

在编写需要解压缩文件的脚本时，建议始终使用带有适当参数 (xz -d 或 xz -dc) 的名称 xz 而不是名称 unxz 和 xzcat 。

xz 是一个通用的数据压缩工具，命令行语法类似于 gzip(1) 和 bzip2(1) 。本机文件格式是 .xz 格式，但也支持 LZMA Utils 使用的旧版 .lzma 格式以及没有容器格式标头的原始压缩流。

xz 根据选择的操作模式压缩或解压缩每个文件。 file 如果没有给出 files 或 file 是 -, xz 从标准输入读取并将处理后的数据写入标准输出。如果是终端， xz 将拒绝（显示错误并跳过 file) 将压缩数据写入标准输出。同样，如果 xz 是终端，则 xz 将拒绝从标准输入读取压缩数据。

除非指定 --stdout ，否则 - 以外的 files 将写入一个新文件，其名称源自 file 名：

压缩时，将目标文件格式 (.xz 或 .lzma) 的后缀附加到源文件名后，得到目标文件名。
解压时，去掉文件名中的 .xz 或 .lzma 后缀，得到目标文件名。 xz 还可以识别后缀 .txz 和 .tlz, 并将它们替换为 .tar 后缀。

如果目标文件已存在，则会显示错误并跳过该 file 。

除非写入标准输出，否则 xz 将显示警告并在以下任何情况下跳过 file :

File 不是常规文件。不遵循符号链接，因此它们不被视为常规文件。
File 有多个硬链接。
File 设置了 setuid、setgid 或粘滞位。
操作模式设置为压缩，并且 file 已经有目标文件格式的后缀（压缩为 .xz 格式时为 .xz 或 .txz ，压缩为 .lzma 格式时为 .lzma 或 .tlz )。
操作模式设置为解压缩，并且 file 没有任何支持的文件格式 (.xz、 .txz、 .lzma 或 .tlz ）的后缀。

成功压缩或解压 file 后， xz 将源文件的所有者、组、权限、访问时间和修改时间复制到目标 file 中。如果复制组失败，则会修改权限，以使无权访问源 file 的用户无法访问目标文件。 xz 还不支持复制其他元数据，例如访问控制列表或扩展属性。

成功关闭目标文件后，除非指定 --keep ，否则源 file 将被删除。如果将输出写入标准输出，则永远不会删除源 file 。

向 xz 进程发送 SIGINFO 或 SIGUSR1 会使其将进度信息打印到标准错误。这只有有限的用途，因为当标准错误是终端时，使用 --verbose 将显示一个自动更新的进度指示器。

xz 的内存使用量从几百千字节到几千兆字节不等，具体取决于压缩设置。压缩文件时使用的设置决定了解压缩器的内存要求。通常，解压缩器需要压缩器创建文件时所需内存量的 5 % 到 20 % 。例如，解压缩使用 xz -9 创建的文件当前需要 65 MiB 的内存。尽管如此，仍可能有需要数 GB 内存才能解压缩的 .xz 文件。

特别是旧系统的用户可能会发现非常大内存使用的可能性令人讨厌。为了防止令人不快的意外， xz 有一个内置的内存使用限制器，默认情况下它是禁用的。虽然一些操作系统提供了限制进程内存使用的方法，但依赖它被认为不够灵活（例如，使用 ulimit(1) 来限制虚拟内存往往会削弱 mmap(2) )。

可以使用命令行选项 --memlimit=limit 启用内存使用限制器。通常通过设置环境变量 XZ_DEFAULTS, 来默认启用限制器会更方便，例如 XZ_DEFAULTS=--memlimit=150MiB 。可以使用 --memlimit-compress=limit 和 --memlimit-decompress=limit 分别设置压缩和解压缩的限制。在 XZ_DEFAULTS 之外使用这两个选项很少有用，因为单次运行 xz 不能同时进行压缩和解压缩，而且 --memlimit=limit (或 -M limit) 在命令行上键入更短。

如果解压时超过了指定的内存使用限制， xz 会报错，解压文件会失败。如果压缩时超出限制， xz 将尝试缩小设置，以便不再超出限制（使用 --format=raw 或 --no-adjust 时除外）。这样操作不会失败，除非限制非常小。设置的缩放以与压缩级别预设不匹配的步骤完成，例如，如果限制仅略小于 xz -9 所需的量，则设置将仅缩小一点，而不是一直缩小降至 xz -8 。

可以按原样连接 .xz 文件。 xz 将解压缩这些文件，就好像它们是单个 .xz 文件一样。

可以在连接的部分之间或最后一部分之后插入填充。填充必须由空字节组成，并且填充的大小必须是四个字节的倍数。这可能很有用，例如，如果 .xz 文件存储在以 512 字节块为单位测量文件大小的介质上。

.lzma 文件或原始流不允许连接和填充。

在大多数需要整数参数的地方，支持可选后缀以轻松指示大整数。整数和后缀之间不能有空格。

KiB

将整数乘以 1,024 (2^10)。 Ki, k, kB, K 和 KB 被接受为 KiB 的同义词。

MiB

将整数乘以 1,048,576 (2^20)。 Mi, m, M 和 MB 被接受为 MiB 的同义词。

GiB

将整数乘以 1,073,741,824 (2^30)。 Gi, g, G 和 GB 被接受为 GiB 的同义词。

特殊值 max 可用于表示选项支持的最大整数值。

如果给出了多个操作模式选项，则最后一个生效。

-z, --compress

压缩。当未指定操作模式选项且命令名称未暗示其他操作模式时，这是默认操作模式（例如， unxz 表示 --decompress)。

-d, --decompress, --uncompress

解压。

-t, --test

测试压缩 files 的完整性。此选项等效于 --decompress --stdout ，只是解压缩的数据被丢弃而不是写入标准输出。没有文件被创建或删除。

-l, --list

打印有关压缩 files 的信息。不会产生未压缩的输出，也不会创建或删除文件。在列表模式下，程序无法从标准输入或其他不可搜索的源中读取压缩数据。

默认列表显示有关 files 的基本信息，每行一个文件。要获得更详细的信息，还可以使用 --verbose 选项。要获得更多信息，请使用 --verbose 两次，但请注意这可能会很慢，因为获取所有额外信息需要多次查找。详细输出的宽度超过 80 个字符，因此如果终端不够宽，将输出通过管道传送到例如 less -S 可能会很方便。

确切的输出可能因 xz 版本和不同的语言环境而异。对于机器可读的输出，应该使用 --robot --list 。

-k, --keep

不要删除输入文件。

-f, --force

这个选项有几个效果：

如果目标文件已经存在，请在压缩或解压前将其删除。
即使输入是指向常规文件的符号链接、具有多个硬链接或设置了 setuid、setgid 或粘滞位，也可以压缩或解压缩。 setuid、setgid 和sticky 位不会复制到目标文件中。
与 --decompress --stdout 一起使用时， xz 无法识别源文件的类型，将源文件原样复制到标准输出。这允许 xzcat --force 像 cat(1) 一样用于未使用 xz 压缩的文件。请注意，将来 xz 可能会支持新的压缩文件格式，这可能会使 xz 解压缩更多类型的文件，而不是按原样将它们复制到标准输出。 --format=format 可用于限制 xz 仅解压缩单个文件格式。

-c, --stdout, --to-stdout

将压缩或解压缩的数据写入标准输出而不是文件。这意味着 --keep 。

--single-stream

仅解压缩第一个 .xz 流，并静默忽略该流后面可能存在的剩余输入数据。通常这种尾随垃圾会使 xz 显示错误。

xz 从不从 .lzma 文件或原始流中解压缩多个流，但此选项仍然使 xz 忽略 .lzma 文件或原始流之后可能出现的尾随数据。

如果操作模式不是 --decompress 或 --test ，此选项无效。

--no-sparse

禁用创建稀疏文件。默认情况下，如果解压缩成常规文件，如果解压缩的数据包含长的二进制零序列， xz 会尝试使文件稀疏。只要标准输出连接到常规文件并且满足某些附加条件以使其安全，它在写入标准输出时也可以工作。创建稀疏文件可以通过减少磁盘 I/O 量来节省磁盘空间并加快解压缩速度。

-S .suf, --suffix=.suf

压缩时，使用 .suf 作为目标文件的后缀，而不是 .xz 或 .lzma 。如果不写入标准输出并且源文件已经具有后缀 .suf, 则会显示警告并跳过该文件。

解压缩时，除了后缀 .xz, .txz, .lzma 或 .tlz 的文件之外，还要识别后缀为 .suf 的文件。如果源文件具有后缀 .suf, 则删除后缀以获取目标文件名。

压缩或解压缩原始流 (--format=raw) 时，必须始终指定后缀，除非写入标准输出，因为原始流没有默认后缀。

--files[=file]

从 file 中读取要处理的文件名；如果省略 file ，则从标准输入中读取文件名。文件名必须以换行符结尾。破折号 (-) 被视为常规文件名；这并不意味着标准输入。如果文件名也作为命令行参数给出，则在从 file 中读取文件名之前处理它们。

--files0[=file]

这与 --files[=file] 相同，只是每个文件名必须以空字符结尾。

-F format, --format=format

指定要压缩或解压缩的文件 format :

auto

这是默认设置。压缩时， auto 等价于 xz 。解压时会自动检测输入文件的格式。请注意，无法自动检测原始流（使用 --format=raw 创建）。

压缩成 .xz 文件格式，或者解压时只接受 .xz 文件。

lzma, alone

压缩为旧的 .lzma 文件格式，或在解压缩时仅接受 .lzma 文件。仅提供替代名称 alone 是为了向后兼容 LZMA Utils。

raw

压缩或解压缩原始流（无标头）。这仅适用于高级用户。要解码原始流，您需要使用 --format=raw 并明确指定过滤器链，该过滤器链通常存储在容器标头中。

-C check, --check=check

指定完整性检查的类型。检查是根据未压缩的数据计算得出的，并存储在 .xz 文件中。此选项仅在压缩为 .xz 格式时有效； .lzma 格式不支持完整性检查。解压缩 .xz 文件时会验证完整性检查（如果有）。

支持的 check 类型：

none

根本不计算完整性检查。这通常是个坏主意。当无论如何通过其他方式验证数据的完整性时，这可能很有用。

crc32

使用来自 IEEE-802.3（以太网）的多项式计算 CRC32。

crc64

使用 ECMA-182 中的多项式计算 CRC64。这是默认设置，因为它在检测损坏文件方面比 CRC32 略好，而且速度差异可以忽略不计。

sha256

计算 SHA-256。这比 CRC32 和 CRC64 慢一些。

.xz 标头的完整性始终使用 CRC32 进行验证。无法更改或禁用它。

--ignore-check

解压时不要验证压缩数据的完整性检查。 .xz 标头中的 CRC32 值仍将正常验证。

除非您知道自己在做什么，否则不要使用此选项。 使用此选项的可能原因：

试图从损坏的 .xz 文件中恢复数据。
加速解压。这主要与 SHA-256 或压缩得非常好的文件有关。建议不要将此选项用于此目的，除非文件完整性已通过其他方式在外部进行验证。

-0 ... -9

选择压缩预设级别。默认值为 -6 。如果指定了多个预设级别，则最后一个生效。如果已指定自定义过滤器链，则设置压缩预设级别会清除自定义过滤器链。

预设之间的差异比 gzip(1) 和 bzip2(1) 更显着。选定的压缩设置决定了解压器的内存需求，因此使用过高的预设级别可能会使在 RAM 很少的旧系统上解压文件变得很痛苦。具体来说，像 gzip(1) 和 bzip2(1) 一样， 盲目地使用 -9 并不是一个好主意 。

-0 ... -3

这些是一些快速的预设。 -0 有时比 gzip -9 更快，同时压缩得更好。较高的通常具有与 bzip2(1) 相当的速度，具有相当或更好的压缩率，尽管结果在很大程度上取决于被压缩的数据类型。

-4 ... -6

良好到非常好的压缩，同时即使对于旧系统也能保持合理的解压器内存使用。 -6 是默认值，这通常是一个不错的选择，例如分发需要解压缩的文件，即使在只有 16 MiB RAM 的系统上也是如此。 (-5e 或 -6e 也可能值得考虑。请参阅 --extreme 。)

-7 ... -9

这些类似于 -6 ，但具有更高的压缩器和解压缩器内存要求。这些仅在分别压缩大于 8 MiB、16 MiB 和 32 MiB 的文件时才有用。

在相同的硬件上，解压缩速度大约是每秒压缩数据的恒定字节数。换句话说，压缩得越好，通常解压的速度就越快。这也意味着每秒产生的未压缩输出量可能会有很大差异。

下表总结了预设的功能：

Preset

DictSize

CompCPU

CompMem

DecMem

-0

256 KiB

3 MiB

1 MiB

-1

1 MiB

9 MiB

2 MiB

-2

2 MiB

17 MiB

3 MiB

-3

4 MiB

32 MiB

5 MiB

-4

4 MiB

48 MiB

5 MiB

-5

8 MiB

94 MiB

9 MiB

-6

8 MiB

94 MiB

9 MiB

-7

16 MiB

186 MiB

17 MiB

-8

32 MiB

370 MiB

33 MiB

-9

64 MiB

674 MiB

65 MiB

栏目说明：

DictSize 是 LZMA2 字典大小。使用大于未压缩文件大小的字典会浪费内存。这就是为什么在没有真正需要时最好避免使用预设 -7 ... -9 的原因。在 -6 或更低时，浪费的内存量通常低到无所谓。
CompCPU 是影响压缩速度的 LZMA2 设置的简化表示。字典大小也会影响速度，因此虽然 CompCPU 对于级别 -6 ... -9 是相同的，但更高级别仍然往往会慢一些。要获得更慢并因此可能获得更好的压缩，请参阅 --extreme 。
CompMem 包含单线程模式下的压缩器内存要求。 xz 版本之间可能略有不同。未来一些多线程模式的内存需求可能会大大高于单线程模式。
DecMem 包含解压缩器内存要求。也就是说，压缩设置决定了解压缩器的内存需求。确切的解压缩器内存使用量略大于 LZMA2 字典大小，但表中的值已四舍五入到下一个完整的 MiB。

-e, --extreme

使用所选压缩预设级别的较慢变体 (-0 ... -9) 有望获得更好的压缩比，但如果运气不好，这也会使其变得更糟。解压器内存使用不受影响，但压缩器内存使用在预设水平 -0 ... -3 时略有增加。

由于有两个字典大小为 4 MiB 和 8 MiB 的预设，因此预设 -3e 和 -5e 分别使用比 -4e 和 -6e, 稍快的设置（较低的 CompCPU）。这样，没有两个预设是相同的。

Preset

DictSize

CompCPU

CompMem

DecMem

-0e

256 KiB

4 MiB

1 MiB

-1e

1 MiB

13 MiB

2 MiB

-2e

2 MiB

25 MiB

3 MiB

-3e

4 MiB

48 MiB

5 MiB

-4e

4 MiB

48 MiB

5 MiB

-5e

8 MiB

94 MiB

9 MiB

-6e

8 MiB

94 MiB

9 MiB

-7e

16 MiB

186 MiB

17 MiB

-8e

32 MiB

370 MiB

33 MiB

-9e

64 MiB

674 MiB

65 MiB

例如，共有四个预设使用 8 MiB 字典，从最快到最慢的顺序是 -5, -6, -5e 和 -6e 。

--fast

--best

这些分别是 -0 和 -9 的一些误导性别名。提供这些只是为了向后兼容 LZMA Utils。避免使用这些选项。

--block-size=size

压缩为 .xz 格式时，将输入数据拆分为 size 字节的块。这些块相互独立压缩，这有助于多线程并使有限的随机访问解压缩成为可能。此选项通常用于在多线程模式下覆盖默认块大小，但此选项也可以在单线程模式下使用。

在多线程模式下，每个线程将分配大约三倍 size 的字节用于缓冲输入和输出。默认 size 是 LZMA2 字典大小的三倍或 1 MiB，以较大者为准。通常一个好的值是 LZMA2 字典大小的 2-4 倍或至少 1 MiB。使用小于 LZMA2 字典大小的 size 会浪费 RAM，因为这样 LZMA2 字典缓冲区将永远不会被完全使用。块的大小存储在块头中，未来版本的 xz 将用于多线程解压缩。

在单线程模式下，默认情况下不进行块拆分。设置此选项不会影响内存使用。块头中没有存储大小信息，因此在单线程模式下创建的文件与在多线程模式下创建的文件不同。缺少大小信息也意味着未来版本的 xz 将无法在多线程模式下解压缩文件。

--block-list=sizes

压缩为 .xz 格式时，在给定的未压缩数据间隔后开始一个新块。

块的未压缩 sizes 被指定为逗号分隔的列表。省略大小（两个或多个连续逗号）是使用前一个块大小的简写。

如果输入文件大于 sizes 的总和，则重复 sizes 中的最后一个值，直到文件末尾。可以使用特殊值 0 作为最后一个值，以指示文件的其余部分应编码为单个块。

如果指定的 sizes 超过了编码器的块大小（线程模式下的默认值或 --block-size=size 指定的值），编码器将创建额外的块，同时保持 sizes 指定的边界。例如，如果指定 --block-size=10MiB --block-list=5MiB,10MiB,8MiB,12MiB,24MiB 并且输入文件为 80 MiB，则将得到 11 个块：5、10、8、10， 2、10、10、4、10、10 和 1 MiB。

在多线程模式下，块的大小存储在块头中。这不是在单线程模式下完成的，因此编码输出不会与多线程模式的输出相同

--flush-timeout=timeout

压缩时，如果自上次刷新以来已经过去了超过 timeout 毫秒（一个正整数）并且读取更多输入将阻塞，则所有待处理的输入数据都从编码器中刷新并在输出流中可用。如果 xz 用于压缩通过网络传输的数据，这将很有用。小的 timeout 值使数据在接收端可用，延迟小，但大的 timeout 值提供更好的压缩比。

默认情况下禁用此功能。如果多次指定此选项，则最后一个生效。特殊的 timeout 值 0 可用于显式禁用此功能。

此功能在非 POSIX 系统上不可用。

此功能仍处于试验阶段。 由于 xz 的缓冲方式，目前 xz 不适合实时解压缩流。

--memlimit-compress=limit

设置压缩的内存使用限制。如果多次指定该选项，则最后一个生效。

如果压缩设置超过 limit, xz 将向下调整设置，以便不再超过限制，并显示自动调整已完成的通知。使用 --format=raw 压缩或指定 --no-adjust 时不会进行此类调整。在这些情况下，会显示错误并且 xz 将以退出状态 1 退出。

可以通过多种方式指定 limit :

limit 可以是以字节为单位的绝对值。使用像 MiB 这样的整数后缀会很有用。示例： --memlimit-compress=80MiB
可以将 limit 指定为总物理内存 (RAM) 的百分比。这在不同计算机之间共享的 shell 初始化脚本中设置 XZ_DEFAULTS 环境变量时尤其有用。这样，在具有更多内存的系统上，限制会自动变大。示例： --memlimit-compress=70%
可以通过将 limit 设置为 0 将其重置为默认值。这目前相当于将 limit 设置为 max （无内存使用限制）。一旦实现了多线程支持，对于多线程情况， 0 和 max 之间可能存在差异，因此建议使用 0 而不是 max ，直到细节确定为止。

对于 32 位 xz ，有一种特殊情况：如果 limit 超过 4020 MiB, 则 limit 设置为 4020 MiB 。（值 0 和 max 不受此影响。解压缩不存在类似的功能。）当 32 位可执行文件可以访问 4 GiB 地址空间时，这可能会很有帮助，同时希望在其他情况下不会造成任何伤害。

另请参阅 内存使用部分 。

--memlimit-decompress=limit

设置解压的内存使用限制。这也会影响 --list 模式。如果不超过 limit 不能操作， xz 会报错，解压文件会失败。有关指定 limit 的可能方法，请参见 --memlimit-compress=limit 。

-M limit, --memlimit=limit, --memory=limit

这等效于指定 --memlimit-compress= limit --memlimit-decompress= limit。

--no-adjust

如果压缩设置超过内存使用限制，则显示错误并退出。默认是向下调整设置，以免超出内存使用限制。创建原始流时始终禁用自动调整 (--format=raw) 。

-T threads, --threads=threads

指定要使用的工作线程数。将 threads 设置为特殊值 0 使 xz 使用与系统上的 CPU 内核一样多的线程。如果输入文件不足以使用给定设置进行线程处理，或者如果使用更多线程会超过内存使用限制，则实际线程数可能会少于 threads 。

目前唯一的线程化方法是将输入分成块并相互独立地压缩它们。默认块大小取决于压缩级别，可以使用 --block-size=size 选项覆盖。

线程解压还没有实现。它仅适用于包含多个块且在块头中具有大小信息的文件。在多线程模式下压缩的所有文件都满足此条件，但在单线程模式下压缩的文件即使使用 --block-size=size 也不满足。

自定义过滤器链允许详细指定压缩设置，而不是依赖与预设关联的设置。指定自定义过滤器链时，会忘记命令行中较早的预设选项 (-0 ... -9 和 --extreme) 。如果在一个或多个自定义过滤器链选项之后指定了预设选项，则新预设会生效，并且之前指定的自定义过滤器链选项会被遗忘。

过滤器链类似于命令行上的管道。压缩时，未压缩的输入进入第一个过滤器，其输出进入下一个过滤器（如果有）。最后一个过滤器的输出被写入压缩文件。链中过滤器的最大数量为四个，但通常一个过滤器链只有一个或两个过滤器。

许多过滤器对它们在过滤器链中的位置有限制：一些过滤器只能作为链中的最后一个过滤器，一些只能作为非最后一个过滤器，还有一些可以在链中的任何位置工作。根据过滤器的不同，此限制要么是过滤器设计所固有的，要么是为了防止安全问题而存在的。

自定义过滤器链是通过按照过滤器链中所需的顺序使用一个或多个过滤器选项来指定的。也就是说，过滤器选项的顺序很重要！解码原始流 (--format=raw) 时，过滤器链的指定顺序与压缩时指定的顺序相同。

过滤器将特定于过滤器的 options 作为逗号分隔的列表。 options 的额外逗号将被忽略。每个选项都有一个默认值，因此您只需指定要更改的选项。

要查看整个过滤器链和 options, 请使用 xz -vv (即使用 --verbose 两次）。这也适用于查看预设使用的过滤器链选项。

--lzma1[=options]

--lzma2[=options]

将 LZMA1 或 LZMA2 过滤器添加到过滤器链中。这些过滤器只能用作链中的最后一个过滤器。

LZMA1 是一个旧版过滤器，几乎完全是由于旧版 .lzma 文件格式（仅支持 LZMA1）而受到支持。 LZMA2 是 LZMA1 的更新版本，修复了 LZMA1 的一些实际问题。 .xz 格式使用 LZMA2，根本不支持 LZMA1。 LZMA1和LZMA2的压缩速度和压缩比几乎相同。

LZMA1 和 LZMA2 共享相同的 options 集：

preset=preset

将所有 LZMA1 或 LZMA2 options 重置为 preset 。 Preset 由一个整数组成，后面可以跟单字母的预设修饰符。整数可以是 0 到 9, 匹配命令行选项 -0 ... -9。目前唯一支持的修饰符是 e, 它匹配 --extreme 。如果未指定 preset ，则 LZMA1 或 LZMA2 options 的默认值取自预设 6 。

dict=size

字典（历史缓冲区） size 表示最近处理的未压缩数据中有多少字节保存在内存中。该算法试图在未压缩的数据中找到重复的字节序列（匹配），并将它们替换为对当前字典中数据的引用。字典越大，找到匹配项的机会就越高。因此，增加字典 size 通常会提高压缩率，但是比未压缩文件大的字典会浪费内存。

典型的字典 size 从 64 KiB 到 64 MiB。最小值为 4 KiB。当前最大压缩为 1.5 GiB (1536 MiB)。解压缩器已经支持最多小于 4 GiB 的一个字节的字典，这是 LZMA1 和 LZMA2 流格式的最大值。

字典 size 和匹配查找器 (mf) 共同决定了 LZMA1 或 LZMA2 编码器的内存使用情况。解压缩时需要与压缩时使用的字典 size 相同（或更大），因此解码器的内存使用量由压缩时使用的字典大小决定。 .xz 标头将字典 size 存储为 2^n 或 2^n + 2^(n-1), 因此这些 sizes 在某种程度上更适合压缩。存储在 .xz 标头中时，其他 sizes 将被四舍五入。

lc=lc

指定文字上下文位的数量。最小值为0，最大值为4；默认值为 3。此外， lc 和 lp 之和不得超过 4。

所有不能编码为匹配的字节都被编码为文字。也就是说，文字只是一次编码一个的 8 位字节。

文字编码假设前一个未压缩字节的最高 lc 位与下一个字节相关。例如，在典型的英文文本中，一个大写字母通常跟在一个小写字母之后，而一个小写字母通常跟在另一个小写字母之后。在 US-ASCII 字符集中，最高三位是 010 表示大写字母，011 表示小写字母。当 lc 至少为 3 时，文字编码可以在未压缩数据中利用此属性。

默认值 (3) 通常很好。如果您想要最大压缩率，请测试 lc=4 。有时它会有所帮助，有时它会使压缩变得更糟。如果它变得更糟，也测试一下 lc=2 。

lp=lp

指定文字位置位的数量。最小值为0，最大值为4；默认值为 0。

Lp 影响编码文字时假定的未压缩数据中的哪种对齐方式。有关对齐的更多信息，请参见下面的 pb below for more information about alignment.

pb=pb

指定位置位数。最小值为0，最大值为4；默认值为 2。

Pb 影响一般假设的未压缩数据中的对齐类型。默认表示四字节对齐 (2^pb=2^2=4), 当没有更好的猜测时，这通常是一个不错的选择。

当对齐已知时，相应地设置 pb 可能会稍微减小文件大小。例如，对于具有一字节对齐的文本文件（US-ASCII、ISO-8859-*、UTF-8），设置 pb=0 可以稍微提高压缩率。对于 UTF-16 文本， pb=1 是一个不错的选择。如果对齐是一个奇数，比如 3 个字节， pb=0 可能是最好的选择。

尽管可以使用 pb 和 lp 调整假设的对齐方式，但 LZMA1 和 LZMA2 仍然略微倾向于 16 字节对齐。在设计可能经常使用 LZMA1 或 LZMA2 压缩的文件格式时，可能值得考虑。

mf=mf

匹配查找器对编码器速度、内存使用和压缩率有重大影响。通常哈希链匹配查找器比二叉树匹配查找器更快。默认取决于 preset: 0 使用 hc3, 1-3 使用 hc4, 其余使用 bt4 。

支持以下匹配查找器。下面的内存使用公式是粗略的近似值，当 dict 是 2 的幂时最接近实际情况。

hc3

具有 2 字节和 3 字节散列的散列链- nice: 的最小值：3- 内存使用情况：- dict * 7.5 (if dict <= 16 MiB);- dict * 5.5 + 64 MiB (if dict > 16 MiB)

hc4

具有 2、3 和 4 字节散列的散列链- nice 的最小值：4- 内存使用情况：- dict * 7.5 (if dict <= 32 MiB);- dict * 6.5 (if dict > 32 MiB)

bt2

具有 2 字节散列的二叉树- nice 的最小值：2- 内存使用： dict * 9.5

bt3

具有 2 字节和 3 字节散列的二叉树- nice 的最小值：3- 内存使用情况- dict * 11.5 (if dict <= 16 MiB);- dict * 9.5 + 64 MiB (if dict > 16 MiB)

bt4

具有 2、3 和 4 字节散列的二叉树- nice 的最小值：4- 内存使用情况：- dict * 11.5 (if dict <= 32 MiB);- dict * 10.5 (if dict > 32 MiB)

mode=mode

压缩 mode 指定分析匹配查找器生成的数据的方法。支持的 modes 是 fast 和 normal 。 presets 0-3 的默认设置为 fast ， presets 4-9 的默认设置为 normal 。

通常 fast 与哈希链匹配查找器一起使用，而 normal 与二叉树匹配查找器一起使用。这也是 presets 的作用。

nice=nice

指定匹配的合适长度。一旦找到至少 nice 的字节匹配，算法就会停止寻找可能更好的匹配。

Nice 可以是 2-273 字节。较高的值往往会以牺牲速度为代价提供更好的压缩比。默认值取决于 preset 。

depth=depth

在匹配查找器中指定最大搜索深度。默认是特殊值 0，这使得压缩器从 mf 和 nice 中确定一个合理的 depth 。

哈希链的合理 depth 是 4-100 和二叉树的 16-1000 。使用非常高的 depth 值会使编码器对某些文件非常慢。避免将 depth 设置为超过 1000，除非您准备中断压缩以防压缩时间过长。

解码原始流 (--format=raw), 时，LZMA2 只需要字典 size 。 LZMA1 还需要 lc, lp 和 pb 。

--x86[=options]

--powerpc[=options]

--ia64[=options]

--arm[=options]

--armthumb[=options]

--sparc[=options]

将分支/调用/跳转 (BCJ) 过滤器添加到过滤器链。这些过滤器只能用作过滤器链中的非最后一个过滤器。

BCJ 过滤器将机器代码中的相对地址转换为绝对地址。这不会改变数据的大小，但会增加冗余，这可以帮助 LZMA2 生成小 0-15 % 的 .xz 文件。 BCJ 过滤器始终是可逆的，因此对错误类型的数据使用 BCJ 过滤器不会导致任何数据丢失，尽管它可能会使压缩率稍微变差。

可以对整个可执行文件应用 BCJ 过滤器；无需仅将其应用于可执行部分。在包含可执行文件和不可执行文件的存档上应用 BCJ 过滤器可能会或可能不会产生好的结果，因此在压缩二进制包以进行分发时盲目地应用 BCJ 过滤器通常是不好的。

这些 BCJ 过滤器速度非常快，并且使用的内存量很小。如果 BCJ 过滤器提高了文件的压缩率，它可以同时提高解压缩速度。这是因为，在同样的硬件上，LZMA2 的解压速度大致是每秒压缩数据的固定字节数。

这些 BCJ 滤波器存在与压缩比相关的已知问题：

某些类型的包含可执行代码的文件（例如目标文件、静态库和 Linux 内核模块）在指令中的地址填充了填充值。这些 BCJ 过滤器仍会进行地址转换，这会使这些文件的压缩效果更差。
对包含多个类似可执行文件的存档应用 BCJ 过滤器会使压缩率比不使用 BCJ 过滤器更差。这是因为 BCJ 过滤器不检测可执行文件的边界，也不为每个可执行文件重置地址转换计数器。

上述两个问题都将在未来的新过滤器中得到解决。旧的 BCJ 滤波器在嵌入式系统中仍然有用，因为新滤波器的解码器会更大并且使用更多内存。

不同的指令集有不同的对齐方式：

Filter

Alignment

Notes

x86

32-bit or 64-bit x86

PowerPC

Big endian only

ARM

Little endian only

ARM-Thumb

Little endian only

IA-64

Big or little endian

SPARC

Big or little endian

由于 BCJ 过滤的数据通常使用 LZMA2 进行压缩，如果将 LZMA2 选项设置为匹配所选 BCJ 过滤器的对齐方式，则压缩率可能会略有提高。例如，使用 IA-64 过滤器，最好使用 LZMA2 (2^4=16) 设置 pb=4 。 x86 过滤器是一个例外；在压缩 x86 可执行文件时，最好坚持 LZMA2 的默认四字节对齐方式。

所有 BCJ 过滤器都支持相同的 options:

start=offset

指定在相对地址和绝对地址之间转换时使用的起始 offset 。 offset 必须是过滤器对齐的倍数（见上表）。默认为零。在实践中，默认是好的；指定自定义 offset 几乎没有用处。

--delta[=options]

将 Delta 过滤器添加到过滤器链中。 Delta 过滤器只能用作过滤器链中的非最后一个过滤器。

目前仅支持简单的逐字节增量计算。它在压缩例如未压缩的位图图像或未压缩的 PCM 音频时很有用。但是，专用算法可能会提供比 Delta + LZMA2 更好的结果。对于音频尤其如此，它可以更快更好地压缩，例如使用 flac(1) 。

支持的 options:

dist=distance

以字节为单位指定增量计算的 distance 。 distance must 必须为 1-256。默认值为 1。

例如，在 dist=2 和 8 字节输入 A1 B1 A2 B3 A3 B5 A4 B7 时，输出将为 A1 B1 01 02 01 02 01 02。

-q, --quiet

禁止警告和通知。指定两次以抑制错误。此选项对退出状态没有影响。也就是说，即使警告被抑制，仍然使用指示警告的退出状态。

-v, --verbose

详细一点。如果标准错误连接到终端， xz 将显示进度指示器。指定 --verbose 两次将给出更详细的输出。

进度指示器显示以下信息：

如果输入文件的大小已知，则会显示完成百分比。也就是说，百分比不能显示在管道中。
产生（压缩）或消耗（解压缩）的压缩数据量。
消耗（压缩）或生成（解压缩）的未压缩数据量。
压缩率，通过将到目前为止处理的压缩数据量除以迄今为止处理的未压缩数据量来计算。
压缩或解压速度。这是以每秒消耗（压缩）或生成（解压缩）的未压缩数据量来衡量的。它在 xz 开始处理文件后几秒钟后显示。
M:SS 或 H:MM:SS 格式的经过时间。
仅当输入文件的大小已知并且自 xz 开始处理文件以来已经过去了几秒钟时，才会显示估计的剩余时间。时间以不包含任何冒号的不太精确的格式显示，例如 2 分 30 秒。

当标准错误不是终端时， --verbose 将使 xz 在压缩或解压缩文件后将文件名、压缩大小、未压缩大小、压缩率，以及单行上的速度和经过时间打印到标准错误。仅当操作至少花费几秒钟时才会包括速度和经过时间。如果操作没有完成，例如由于用户中断，如果输入文件的大小已知，也会打印完成百分比。

-Q, --no-warn

即使检测到值得警告的条件，也不要将退出状态设置为 2。此选项不会影响详细级别，因此必须使用 --quiet 和 --no-warn 来不显示警告和不更改退出状态。

--robot

以机器可解析的格式打印消息。这是为了方便编写想要使用 xz 而不是 liblzma 的前端，这可能是各种脚本的情况。启用此选项的输出意味着在 xz 版本中保持稳定。有关详细信息，请参阅 机器人模式 部分。

--info-memory

以人类可读的格式显示 xz 认为系统有多少物理内存 (RAM) 以及压缩和解压缩的内存使用限制，并成功退出。

-h, --help

显示描述最常用选项的帮助消息，并成功退出。

-H, --long-help

显示描述 xz 所有功能的帮助信息，并成功退出

-V, --version

以人类可读的格式显示 xz 和 liblzma 的版本号。要获得机器可解析的输出，请在 --version 之前指定 --robot 。

使用 --robot 项激活机器人模式。它使 xz 的输出更容易被其他程序解析。目前 --robot 仅与 --version, --info-memory 和 --list 一起支持。以后会支持压缩和解压。

xz --robot --version 将按以下格式打印 xz 和 liblzma 的版本号：

XZ_VERSION=XYYYZZZS- LIBLZMA_VERSION=XYYYZZZS

主要版本。

YYY

小版本。偶数是稳定的。奇数是 alpha 或 beta 版本。

ZZZ

稳定版本的补丁级别或只是开发版本的计数器。

稳定。 0是alpha，1是beta，2是稳定的。当 YYY 为偶数时， S 应始终为 2。

如果 xz 和 liblzma 来自同一个 XZ Utils 版本，则两行上的 XYYYZZZS 相同。

示例：4.999.9beta 是 49990091 , 5.0.0 是 50000002 。

xz --robot --info-memory 打印一行，其中包含三个制表符分隔的列：

以字节为单位的物理内存 (RAM) 总量

压缩的内存使用限制（以字节为单位）。特殊的零值表示默认设置，对于单线程模式与无限制相同。

用于解压缩的内存使用限制（以字节为单位）。特殊的零值表示默认设置，对于单线程模式与无限制相同。

将来， xz --robot --info-memory 的输出可能会有更多列，但不会超过一行。

xz --robot --list 使用制表符分隔的输出。每行的第一列都有一个字符串，指示在该行中找到的信息的类型：

name

开始列出文件时，这始终是第一行。该行的第二列是文件名。

file

此行包含有关 .xz 文件的全部信息。此行始终打印在 name 行之后。

stream

此行类型仅在指定 --verbose 时使用。在 .xz 文件中有多少流，就有多少 stream 行。

block

此行类型仅在指定 --verbose 时使用。块行数与 .xz 文件中的 block 数一样多。 block 行显示在所有 stream 行之后；不同的线型不交错。

summary

仅当 --verbose 指定两次时才使用此行类型。此行在所有 block 行之后打印。与 file 行一样， summary 行包含有关 .xz 文件的全部信息。

totals

此行始终是列表输出的最后一行。它显示总计数和大小。

file 行的列：

文件中的流数

流中的总块数

压缩后的文件大小

文件未压缩大小

压缩比，例如 0.123。 如果比率超过 9.999，将显示三个破折号 (---) ，而不是比率。

以逗号分隔的完整性检查名称列表。以下字符串用于已知检查类型： None, CRC32, CRC64 和 SHA-256。对于未知支票类型，使用 Unknown-N ，其中 N 是十进制数形式的支票 ID（一位或两位）。

文件中流填充的总大小

stream 线的列：

流号（第一个流为1）

流中的块数

压缩起始偏移

未压缩的起始偏移量

压缩大小（不包括流填充）

未压缩大小

压缩率

完整性检查的名称

流填充的大小

block 行的列：

包含此块的流的编号

相对于流开头的块号（第一个块为 1）

相对于文件开头的块号

相对于文件开头的压缩起始偏移量

相对于文件开头的未压缩起始偏移量

块的总压缩大小（包括标题）

未压缩大小

压缩率

完整性检查的名称

如果 --verbose 指定了两次，则在 block 行中包含其他列。这些不会用单个 --verbose 显示，因为获取此信息需要多次查找，因此可能很慢：

十六进制完整性检查的值

块头大小

块标志： c 表示存在压缩大小， u 表示存在未压缩大小。如果未设置该标志，则会显示破折号 (-) 以保持字符串长度固定。将来可能会将新标志添加到字符串的末尾。

块中实际压缩数据的大小（不包括块头、块填充和校验字段）

使用此 xz 版本解压缩此块所需的内存量（以字节为单位）

过滤器链。请注意，无法知道压缩时使用的大多数选项，因为只有解压缩所需的选项存储在 .xz 标头中。

summary 行的列：

使用此 xz 版本解压缩此文件所需的内存量（以字节为单位）

yes 或 no 表示是否所有块头都存储了压缩大小和未压缩大小

Since xz 5.1.2alpha 开始：

解压文件所需的最低 xz 版本

totals 行的列：

流数

块数

压缩尺寸

未压缩大小

平均压缩比

文件中存在的完整性检查名称的逗号分隔列表

流填充大小

文件数。这是为了保持前面列的顺序与 file 行的顺序相同。

如果 --verbose 指定了两次，则 totals 行中会包含其他列：

使用此 xz 版本解压缩文件所需的最大内存量（以字节为单位）

yes 或 no 表示是否所有块头都存储了压缩大小和未压缩大小

Since xz 5.1.2 开始：

解压文件所需的最低 xz 版本

未来的版本可能会添加新的线型和新的列可以添加到现有的线型，但现有的列不会改变。

一切都很好。

发生错误。

发生了值得警告的事情，但没有发生实际错误。

在标准错误上打印的通知（不是警告或错误）不会影响退出状态。

在从命令行解析选项之前， xz 按此顺序从环境变量 XZ_DEFAULTS 和 XZ_OPT 中解析以空格分隔的选项列表。请注意，只有选项是从环境变量中解析出来的；所有非选项都被默默忽略。解析是使用 getopt_long(3) 完成的，它也用于命令行参数。

XZ_DEFAULTS

用户特定或系统范围的默认选项。通常这是在 shell 初始化脚本中设置的，以默认启用 xz 的内存使用限制器。排除 shell 初始化脚本和类似的特殊情况，脚本绝不能设置或取消设置 XZ_DEFAULTS 。

XZ_OPT

这是为了在无法直接在 xz 命令行上设置选项时将选项传递给 xz 。例如当 xz 由脚本或工具运行时就是这种情况，例如 GNU tar(1):

XZ_OPT=-2v tar caf foo.tar.xz foo

脚本可以使用 XZ_OPT 例如设置特定于脚本的默认压缩选项。如果这是合理的，仍然建议允许用户覆盖 XZ_OPT ，例如在 sh(1) 脚本中，可能会使用如下内容：

XZ_OPT=${XZ_OPT-"-7e"} export XZ_OPT

xz 的命令行语法实际上是 LZMA Utils 4.32.x 中的 lzma, unlzma 和 lzcat 的超集。在大多数情况下，可以用 XZ Utils 替换 LZMA Utils，而不会破坏现有脚本。但是有一些不兼容的地方，有时可能会导致问题。

xz 和 LZMA Utils 中的压缩级别预设的编号不相同。最重要的区别是字典大小如何映射到不同的预设。字典大小大致等于解压缩器的内存使用量。

Level

LZMA Utils

-0

256 KiB

N/A

-1

1 MiB

64 KiB

-2

2 MiB

1 MiB

-3

4 MiB

512 KiB

-4

4 MiB

1 MiB

-5

8 MiB

2 MiB

-6

8 MiB

4 MiB

-7

16 MiB

8 MiB

-8

32 MiB

16 MiB

-9

64 MiB

32 MiB

字典大小的差异也会影响压缩器内存的使用，但 LZMA Utils 和 XZ Utils 之间还有一些其他差异，这使得差异更大：

Level

LZMA Utils 4.32.x

-0

3 MiB

N/A

-1

9 MiB

2 MiB

-2

17 MiB

12 MiB

-3

32 MiB

12 MiB

-4

48 MiB

16 MiB

-5

94 MiB

26 MiB

-6

94 MiB

45 MiB

-7

186 MiB

83 MiB

-8

370 MiB

159 MiB

-9

674 MiB

311 MiB

LZMA Utils 中的默认预设级别为 -7 而 XZ Utils 中的默认预设级别为 -6, 因此默认情况下两者都使用 8 MiB 字典。

文件的未压缩大小可以存储在 .lzma 标头中。LZMA Utils 在压缩常规文件时会这样做。另一种方法是标记未压缩的大小未知，并使用有效负载结束标记来指示解压缩器应该停止的位置。 LZMA Utils 在未压缩大小未知时使用此方法，例如在管道中就是这种情况。

xz 支持解压缩带有或不带有 end-of-payload 标记的 .lzma 文件，但是 xz 创建的所有 .lzma 文件都将使用 end-of-payload 标记，并且在 .lzma 标头中将未压缩大小标记为未知。在一些不常见的情况下，这可能是一个问题。例如，嵌入式设备中的 .lzma 解压缩器可能仅适用于已知未压缩大小的文件。如果遇到此问题，您需要使用 LZMA Utils 或 LZMA SDK 创建已知未压缩大小的 .lzma 文件。

.lzma 格式允许 lc 值最大为 8， lp 值最大为 4。 LZMA Utils 可以使用任何 lc 和 lp 解压缩文件，但总是创建 lc=3 和 lp=0 的文件。使用 xz 和 LZMA SDK 可以使用其他 lc 和 lp 创建文件。

liblzma 中 LZMA1 过滤器的实现要求 lc 和 lp 之和不能超过4。因此，超出此限制的 .lzma 文件无法使用 xz 解压缩。

LZMA Utils 仅创建字典大小为 2^n 2 的幂）但接受任何字典大小的文件的 .lzma 文件。 liblzma 只接受字典大小为 2^n 或 2^n + 2^(n-1) 的 .lzma 文件。这是为了在检测 .lzma 文件时减少误报。

这些限制在实践中应该不是问题，因为实际上所有 .lzma 文件都已使用 liblzma 可接受的设置进行压缩。

解压缩时，LZMA Utils 会默默地忽略第一个 .lzma 流之后的所有内容。在大多数情况下，这是一个错误。这也意味着 LZMA Utils 不支持解压缩连接的 .lzma 文件。

如果在第一个 .lzma 流之后还有数据， xz 会认为该文件已损坏，除非使用了 --single-stream 。这可能会破坏那些假设尾随垃圾被忽略的晦涩脚本。

即使压缩选项相同，从相同未压缩输入文件生成的确切压缩输出也可能在 XZ Utils 版本之间有所不同。这是因为可以在不影响文件格式的情况下改进编码器（更快或更好的压缩）。如果使用不同的构建选项，即使在相同 XZ Utils 版本的不同构建之间，输出也会有所不同。

上面的意思是一旦实现了 --rsyncable ，除非新旧文件都用相同的 xz 版本压缩，否则生成的文件不一定是 rsyncable 的。如果编码器实现的一部分被冻结以保持跨 xz 版本的 rsyncable 输出稳定，则可以修复此问题。

XZ Embedded 等嵌入式 .xz 解压缩器实现不一定支持使用除 none 和 crc32 之外的完整性 check 类型创建的文件。由于默认值为 --check=crc64, 因此在为嵌入式系统创建文件时必须使用 --check=none 或 --check=crc32 。

在嵌入式系统之外，所有 .xz 格式的解压缩器都支持所有 check 类型，或者如果不支持特定 check ，至少能够在不验证完整性检查的情况下解压缩文件。

XZ Embedded 支持 BCJ 过滤器，但仅支持默认起始偏移。

使用默认压缩级别 (-6) 将文件 foo 压缩为 foo.xz ，如果压缩成功则删除 foo :

xz foo

将 bar.xz 解压成 bar ，即使解压成功也不要删除 bar.xz :

xz -dk bar.xz

使用预设 -4e (-4 --extreme) 创建 baz.tar.xz ，它比默认值 -6 慢，但需要更少的内存用于压缩和解压缩（分别为 48 MiB 和 5 MiB）：

tar cf - baz | xz -4e > baz.tar.xz

可以使用单个命令将压缩和未压缩文件的混合解压缩到标准输出：

xz -dcf a.txt b.txt.xz c.txt d.txt.lzma > abcd.txt

在 GNU 和 *BSD 上， find(1) 和 xargs(1) 可用于并行压缩许多文件：

find . -type f \! -name '*.xz' -print0 \ | xargs -0r -P4 -n16 xz -T1

xargs(1) 的 -P 选项设置并行 xz 进程的数量。 -n 选项的最佳值取决于要压缩的文件数量。如果只有几个文件，则该值应该是 1；对于数以万计的文件，100 甚至更多可能适合减少 xargs(1) 最终创建的 xz 进程的数量。

xz 的选项 -T1 用于强制它进入单线程模式，因为 xargs(1) 用于控制并行化的数量。

计算压缩多个文件后总共节省了多少字节：

xz --robot --list *.xz | awk '/^totals/{print $5-$4}'

脚本可能想知道它正在使用足够新的 xz 。以下 sh(1) 脚本检查 xz 工具的版本号是否至少为 5.0.0。此方法与不支持 --robot 选项的旧 beta 版本兼容：

if ! eval "$(xz --robot --version 2> /dev/null)" || [ "$XZ_VERSION" -lt 50000002 ]; then echo "Your xz is too old." fi unset XZ_VERSION LIBLZMA_VERSION

使用 XZ_OPT 为解压设置内存使用限制，但如果已经设置了限制，则不要增加它：

NEWLIM=$((123 << 20)) # 123 MiB OLDLIM=$(xz --robot --info-memory | cut -f3) if [ $OLDLIM -eq 0 -o $OLDLIM -gt $NEWLIM ]; then XZ_OPT="$XZ_OPT --memlimit-decompress=$NEWLIM" export XZ_OPT fi

自定义过滤器链的最简单用途是自定义 LZMA2 预设。这可能很有用，因为预设仅涵盖了可能有用的压缩设置组合的子集。

在自定义 LZMA2 预设时，选项 -0 ... -9 和 --extreme 描述中的表格的 CompCPU 列很有用。以下是从这两个表中收集的相关部分：

Preset

CompCPU

-0

-1

-2

-3

-4

-5

-6

-5e

-6e

如果您知道一个文件需要较大的字典（例如 32 MiB）才能很好地压缩，但您想比 xz -8 更快地压缩它，则可以修改具有低 CompCPU 值（例如 1）的预设以使用更大的字典：

xz --lzma2=preset=1,dict=32MiB foo.tar

对于某些文件，上述命令可能比 xz -6 更快，同时压缩效果明显更好。但是，必须强调的是，只有一些文件可以从大字典中受益，同时保持 CompCPU 值较低。最明显的情况是，大字典可以提供很大帮助，即存档包含非常相似的文件，每个文件至少有几兆字节。字典大小必须比任何单个文件大得多，以允许 LZMA2 充分利用连续文件之间的相似性。

如果非常高的压缩器和解压缩器内存使用率很好，并且被压缩的文件至少有几百兆字节，那么使用比 xz -9 使用的 64 MiB 更大的字典可能会很有用：

xz -vv --lzma2=dict=192MiB big_foo.tar

在上面的示例中使用 -vv (--verbose --verbose) 对于查看压缩器和解压缩器的内存需求很有用。请记住，使用大于未压缩文件大小的字典会浪费内存，因此上述命令对小文件没有用处。

有时压缩时间无关紧要，但解压器内存使用量必须保持在较低水平，例如才能在嵌入式系统上解压文件。以下命令使用 -6e (-6 --extreme) 作为基础并将字典设置为仅 64 KiB。生成的文件可以使用大约 100 KiB 的内存使用 XZ Embedded（这就是存在 --check=crc32 的原因）进行解压缩。

xz --check=crc32 --lzma2=preset=6e,dict=64KiB foo

如果您想挤出尽可能多的字节，调整文字上下文位 (lc) 的数量和位置位 (pb) 的数量有时会有所帮助。调整文字位置位 (lp) 的数量也可能有所帮助，但通常 lc 和 pb 更重要。例如，源代码存档主要包含 US-ASCII 文本，因此类似以下的内容可能会给出比 xz -6e 稍小的文件（如 0.1 %）（也可以尝试不使用 lc=4):

xz --lzma2=preset=6e,pb=0,lc=4 source_code.tar

将另一个过滤器与 LZMA2 一起使用可以改进某些文件类型的压缩。例如，使用 x86 BCJ 过滤器压缩 x86-32 或 x86-64 共享库：

xz --x86 --lzma2 libfoo.so

请注意，过滤器选项的顺序很重要。如果在 --lzma2, 之后指定 --x86 ， xz 会报错，因为LZMA2 之后不能有任何过滤器，也因为x86 BCJ 过滤器不能用作链中的最后一个过滤器。

Delta 过滤器与 LZMA2 一起可以为位图图像提供良好的效果。它通常应该击败 PNG，它具有比简单 delta 更高级的过滤器，但使用 Deflate 进行实际压缩。

图像必须以未压缩的格式保存，例如未压缩的 TIFF。 Delta 过滤器的距离参数设置为匹配图像中每个像素的字节数。例如 24 位 RGB 位图需要 dist=3, 也可以将 pb=0 传递给 LZMA2 以适应三字节对齐：

xz --delta=dist=3 --lzma2=pb=0 foo.tiff

如果已将多个图像放入单个存档（例如 .tar), 则只要所有图像的每个像素具有相同的字节数，Delta 过滤器也会对其起作用。

xzdec(1), xzdiff(1), xzgrep(1), xzless(1), xzmore(1), gzip(1), bzip2(1), 7z(1)

2020-02-01

Tukaani

最后更新于1年前

这有帮助吗？