每当我看到一些用 GZip 压缩的源包或二进制文件时，我想知道是否还有理由偏爱 gz 而不是 xz（不包括到 2000 年的时间旅行），LZMA 压缩算法的节省是可观的，解压缩并不比压缩包。
问问题
55071 次
9 回答
72
“最小公分母”。节省的额外空间很少值得失去互操作性。大多数嵌入式 Linux 系统都有 gzip，但没有 xz。许多旧系统也是如此。作为行业标准的 Gnu Tar 支持-z通过gzip处理标志和-j通过bzip2处理标志，但是一些旧系统不支持xz-J标志，这意味着它需要两步操作（以及大量额外的磁盘空间用于未压缩，除非您使用的语法是很多人不知道的。）此外，从嵌入式 ARM 上解压缩大约 10MB 的完整文件系统需要大约 2 分钟，这并不是一个真正的问题。不知道但是.tar|tar xf -tar.gzxzbzip2大约需要 10-15 分钟。绝对不值得节省带宽。
于 2011-06-27T13:25:15.953 回答
67
最终答案是可访问性，目的是次要答案。XZ 不一定像 Gzip 那样适合的原因：
嵌入式和遗留系统更可能缺乏足够的可用内存来解压缩 LZMA/LZMA2 档案，例如 XZ。例如，如果 XZ 可以从用于 OpenWrt 路由器的包中减少 400 KiB（与 Gzip 相比），那么如果路由器有 16 MiB 的 RAM，那么节省的少量空间有什么好处？非常旧的计算机系统也会出现类似的情况。人们可能会嘲笑在具有 32MB RAM 的古老 SparcStation LX 上下载和编译最新版本的 Bash，但它确实发生了。
此类系统通常具有较慢的处理器，并且解压缩时间的增加可能非常高。在 200 MHz ARM 内核或 50 MHz microSPARC 上，在 Core i5 上额外解压 3 秒可能会非常长。与所有更好的压缩方法（例如 XZ 甚至 Bzip2）相比，Gzip 压缩在此类处理器上的速度非常快。
Gzip 几乎得到了过去二十年中创建的所有类 UNIX 系统（以及几乎所有非类 UNIX 系统）的普遍支持。XZ 的可用性要有限得多。如果没有解压缩的能力，压缩是没有用的。
更高的压缩率需要很多时间。如果压缩时间比压缩比更重要，Gzip 胜过 XZ。老实说，lzop 比 Gzip 快得多，并且仍然可以压缩，因此需要尽可能快的压缩并且不需要 Gzip 无处不在的应用程序应该考虑使用它。我经常使用诸如“tar -c * | lzop -1 | socat -u - tcp-connect:192.168.0.101:4444”之类的命令在受信任的 LAN 连接上快速打乱文件夹，并且 Gzip 可以类似地在慢得多的链接上使用（即通过 Internet 上的 SSH 隧道执行我刚才描述的相同操作）。
现在，另一方面，在某些情况下 XZ 压缩非常出色：
通过慢速链接发送数据。XZ 格式的 Linux 3.7 内核源代码比 Gzip 格式小 34 MiB。如果你有超快的连接，选择 XZ 可能意味着节省一分钟的下载时间；在廉价的 DSL 连接或 3G 蜂窝连接上，它可以减少一个小时或更长时间的下载时间。
缩小备份档案。使用“gzip-9”与“xz -9e”压缩 Apache 的 httpd-2.4.2 的源代码会产生一个大小为 Gzip 存档大小 62.7% 的 XZ 存档。如果您当前存储为价值 100 GiB 的 .tar.gz 存档的数据集中存在相同的可压缩性，则转换为 .tar.xz 存档将从备份集中减少高达 37.3 GiB 的空间。将整个备份数据集复制到 USB 2.0 硬盘驱动器（最大传输速度约为 30 MiB/秒）作为 Gzip 压缩数据需要 55 分钟，但 XZ 压缩会使备份时间减少 20 分钟。假设您将在具有大量 CPU 能力且一次性压缩速度不是严重问题的现代桌面系统上使用这些备份，则使用 XZ 压缩通常更有意义。如果你不这样做，为什么要随机播放额外的数据？
分发大量可高度压缩的数据。如前所述，Linux 3.7 源代码对于 .tar.xz 为 67 MiB，对于 .tar.gz 为 101 MiB；未压缩的源代码约为 542 MiB，几乎完全是文本。由于内容中的冗余量，源代码（以及一般的文本）通常是高度可压缩的，但是像 Gzip 这样使用更小的字典运行的压缩器无法利用超出其字典大小的冗余。
最终，这一切都回到了四方面的权衡：压缩大小、压缩/解压缩速度、复制/传输速度（从磁盘/网络读取数据）以及压缩器/解压缩器的可用性。选择高度依赖于“您打算如何处理这些数据？”这个问题。
还可以查看这个相关的帖子，我从中学到了一些我在这里重复的东西。
于 2012-12-15T19:50:06.447 回答
16
来自 Lzip 压缩实用程序的作者：
Xz 具有复杂的格式，部分专门用于压缩可执行文件，并旨在通过专有格式进行扩展。在这里测试的四个压缩器中，xz 是唯一一个与 Unix 的“做一件事，做好”的概念格格不入。它不太适合数据共享，根本不适合长期存档。
一般来说，格式越复杂，将来被解码的可能性就越小。但是 xz 格式，就像它臭名昭著的前身 lzma 一样，设计得特别糟糕。Xz 几乎复制了 gzip 的所有缺陷，然后添加了更多，比如脆弱的变长整数。一个可变长度整数的任何字节的第 7 位只需翻转一个位，整个 xz 流就会像纸牌屋一样倒塌。不建议将 xz 用于压缩短期可执行文件以外的任何内容。
不要误解我的意思。我非常感谢 Igor Pavlov 发明/发现 LZMA，但 xz 是他的追随者第三次尝试利用 7zip 的流行，并用不适当或设计不良的格式替换 gzip 和 bzip2。特别是在 GNU 和 Linux 中都实现了对 lzma-alone 的支持是可耻的。
于 2016-02-24T11:20:59.867 回答
13
我在 1.1GB Linux 安装 vmdk 映像上做了自己的基准测试：
rar =260MB comp= 85s decomp= 5s
7z(p7z)=269MB comp= 98s decomp=15s
tar.xz =288MB comp=400s decomp=30s
tar.bz2=382MB comp= 91s decomp=70s
tar.gz =421MB comp=181s decomp= 5s
最大的所有压缩级别，CPU Intel I7 3740QM，内存 32GB 1600，RAM 磁盘上的源和目标
我通常使用 rar 或 7z 来归档文档等普通文件。
对于归档系统文件，我使用 .tar.gz 或 .tar.xz 通过 file-roller 或带有 -z 或 -J 选项的 tar 以及 --preserve 使用 tar 进行本机压缩并保留权限（也可以选择 .tar.7z 或.tar.rar 可以用）
更新：因为 tar 只保留正常权限而不是 ACL，所以也可以使用普通的 .7z 加上备份和恢复权限以及手动通过 getfacl 和 sefacl 的 ACL，这似乎是文件归档或系统文件备份的最佳选择，因为它将完整保留权限和 ACL，具有校验和、完整性测试和加密功能，唯一的缺点是 p7zip 并非随处可用
于 2014-09-18T05:01:21.383 回答
8
老实说，我只是从培训材料中了解 .xz 格式。所以我只是用它的 git repo 来做一个测试。git 是 git://git.free-electrons.com/training-materials.git，我还整理了三张培训幻灯片。总目录大小为 91M，混合了文本和二进制数据。
这是我的快速结果。也许人们仍然喜欢 tar.gz 仅仅是因为它的压缩速度更快？当压缩没有太多好处时，我个人甚至使用普通的焦油。
[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/
real 0m3.371s
user 0m3.208s
sys 0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/
real 0m34.557s
user 0m33.930s
sys 0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/
real 0m0.117s
user 0m0.020s
sys 0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz
real 0m0.719s
user 0m0.536s
sys 0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar
real 0m0.189s
user 0m0.004s
sys 0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz
real 0m3.116s
user 0m2.612s
sys 0m0.184s
于 2012-07-09T07:04:17.167 回答
3
出于同样的原因，Windows (r) 中的人们使用 zip 文件而不是 7zip，有些人仍然使用 rar 而不是其他格式……或者在音乐中使用 mp3，而不是 aac+，等等。
每种格式都有其优点，人们习惯于坚持他们在开始使用计算机时学到的解决方案。将此添加到向后兼容性和快速带宽 + 硬盘驱动器中的 GB 或 TB 空间，更大压缩的好处不会那么相关。
于 2011-06-27T13:45:53.423 回答
3
gz 在任何地方都受支持，并且有利于便携性。
xz 较新，现在得到了广泛或良好的支持。它比 gzip 更复杂，具有更多压缩选项。
这不是人们可能并不总是使用 xz 的唯一原因。xz 可能需要很长时间来压缩，而不是微不足道的时间，因此即使它可以产生出色的结果，它也可能并不总是被选择。另一个弱点是它会占用大量内存，尤其是在压缩方面。您想压缩项目的时间越长，所需的时间越长，这是指数级的，收益递减。
但是，在我的经验中，对于大型二进制项目，在压缩级别 1 下，xz 通常可以在比级别 9 的 zlib 更短的时间内产生更小的结果。这有时可能是一个非常显着的差异，与 zlib 一样，xz 可以创建一个文件这是 zlib 文件大小的一半。
bzip2 处于类似的情况，但是 xz 具有更优越的优势和强大的窗口，它在所有方面都表现得更好。
于 2015-11-02T12:42:18.833 回答
1
gzip 的另一重要点是它可以与rsync/zsync互操作。在某些情况下，这对于带宽来说可能是巨大的好处。LZMA/bzip2/xz 不支持 rsync 并且可能不会很快支持它。
LZMA的特点之一是它使用安静的大窗口。为了使它对rsync/zsync友好，我们可能需要减少这个窗口，这会降低它的压缩性能。
于 2015-01-05T14:06:45.247 回答
1
是的，我的想法是，这些天最初的问题可以被重新提出为“为什么 tar.gz 比 tar.lz 更常见”（因为lz似乎压缩得比 tar.lz稍微好一点xz，xz据说这是一个糟糕的存档选择，尽管确实如此提供一些不错的功能，例如随机访问）。我想答案是人们习惯使用它的“势头”，有很好的库支持等等。lz的引入可能意味着xz现在的增长速度会变慢，同样，FWIW...
然而，话虽如此，lz 的解压速度似乎比 xz 慢，并且出现了像 Brotli 这样的新事物，因此尚不清楚在受欢迎程度方面会发生什么……但我似乎在野外 FWIW 中有一些 .lz 文件...
于 2018-03-23T18:16:06.177 回答