```html

xzutils 是一组命令行小工具的合集，最初由 Lasse Collin 开发，现在通常随 XZ Utils 软件包一起分发。你如果用过 xz 压缩文件，那已经间接接触了它——但 xzutils 本身远不止一个压缩程序。它包含 xz、unxz、xzcat、lzma、lzcat、xzdec 等十几个命令，核心都是围绕 LZMA2 压缩算法做文章。简单说，它是 Linux 和类 Unix 系统上处理 .xz 与 .lzma 格式文件的主力工具集。

我最早注意到 xzutils 是因为下载 Linux 内核源码。kernel.org 提供的压缩包从 .gz 换到 .xz 之后，下载体积小了将近三成。那会儿我还在用老式 ADSL，带宽按 KB 算钱，这个差别很实在。后来查了一下，.xz 格式默认用 LZMA2 算法，压缩率通常比 gzip 高 15% 到 30%，比 bzip2 也高出一截，代价是压缩时更吃 CPU 和内存。xzutils 就是让你在命令行里方便地使用这套算法的工具包。

它最常用的命令是 xz。直接 xz file.txt 会把原文件替换成 file.txt.xz，原文件消失。想保留原文件得加 -k。解压用 unxz file.txt.xz 或者 xz -d file.txt.xz。查看压缩文件内容不一定要解压到磁盘，xzcat file.txt.xz 直接输出到标准输出，管道给 grep 或者 less 都行。这些操作和 gzip、bzip2 的用法几乎对称，学过其中一个，另外两个上手很快。

但 xzutils 有个坑，很多人第一次用会踩：默认压缩级别是 6，对普通文本够用，可你要是压一个几百 MB 的日志文件，它可能跑上十几分钟。我试过用默认参数压一个 2GB 的数据库导出文件，机器风扇狂转，半小时才完事。后来改成 xz -1，速度立刻上来了，压缩率只损失一点点。所以实际用的时候，得根据文件大小和机器性能选级别，1 到 9 之间调，9 最狠但也最慢。

另一个值得说的命令是 xzdec。它只做解压，不依赖 liblzma 库，静态链接，体积很小。嵌入式系统或者恢复环境里经常用它——你没法装完整 xzutils 的时候，扔一个 xzdec 二进制进去就能解 .xz 文件。这个设计思路挺务实，不追求功能全，只解决特定场景下的刚需。

xzutils 还包含 lzmainfo，用来查看 .lzma 文件的头信息，比如字典大小、压缩级别。以及 xzmore、xzgrep、xzless 这些包装脚本，让你不用手动解压就能搜索或分页查看压缩文件内容。这些脚本本身很短，就是调用 xz 和对应的查看工具，但省了不少事。我经常用 xzgrep 在压缩日志里找报错，比先解压再 grep 再删掉临时文件干净得多。

说到实际案例，Arch Linux 的包管理系统 pacman 就用 xzutils 压缩软件包。你下载的 .pkg.tar.xz 文件，背后就是 xz 在干活。Debian 系从某个版本开始也把 .deb 的默认压缩从 gzip 换成了 xz。这些发行版的选择不是随意的——软件包体积小了，镜像站带宽压力就小，用户下载也快。当然代价是安装时解压多花几毫秒，但现代 CPU 完全扛得住。

不过 xzutils 也出过大事。2024 年初那个后门事件，攻击者试图在 xz 的构建脚本里植入恶意代码，影响 SSH 认证。虽然最终被及时发现，但这件事让很多人重新审视了开源基础设施的供应链安全。xzutils 本身功能没变，可它作为底层依赖的广泛性暴露了出来——从内核到发行版到容器镜像，到处都有它的影子。一个压缩工具能搅动整个生态，这大概是 Lasse Collin 当初没想到的。

日常使用中，我一般不会直接调 xz，而是通过 tar 的 -J 选项。 tar -cJf archive.tar.xz dir/ 创建压缩包， tar -xJf archive.tar.xz 解压。这样不用记 xz 的具体参数，tar 帮你调好。但知道底层是 xzutils 在跑，遇到性能问题或者格式兼容问题时，排查方向就明确多了。

如果你只是偶尔压个文件发给别人，用 zip 或者 gzip 更省事，因为对方大概率不用装额外软件。但要是处理大文件、做备份、或者给软件打包分发，xzutils 值得花十分钟学一下。它的手册页写得很清楚， man xz 比网上大多数教程都靠谱。命令行工具就是这样，学会了就一直在那儿，不更新也能用，比很多花哨的 GUI 软件活得久。

```