为什么* .tar.gz比* .tar.xz更普遍？
每当我看到一些用GZip压缩的源代码包或二进制文件时，我想知道是否还有理由赞成gz over xz（不包括2000年的时间旅行），LZMA压缩algorithm的节省是相当大的，并且减压不是大于gzip的。
“最常见的分母”。 节省的额外空间很less值得互操作性。 大多数embedded式Linux系统都有gzip，但不是xz。 许多老系统也是如此。 Gnu Tar是行业标准，支持标志-z通过gzip进行处理， -j通过bzip2进行处理，但是一些旧系统不支持xz的-J标志，这意味着它需要2步操作（而且很多除非你使用|tar xf - – 很多人不知道的语法，另外，从embedded式ARM的tar.gz解压一些10MB的完整文件系统需要2分钟，isn'这真的是一个问题，对xz毫无头绪，但bzip2需要10-15分钟左右，绝对不值得节省带宽。
无论如何，目前的“现代替代”，你牺牲CPU的权力，有利于磁盘空间（…这仍然是一个受欢迎的交易 – 带宽和磁盘空间很便宜，人们讨厌，当系统由于一些更新运行停止运行在后台） – 是bzip2.
最终的答案是无障碍，二次回答的目的。 XZ不一定适合Gzip的原因：
-
embedded式和遗留系统更可能缺乏足够的可用内存来解压LZMA / LZMA2档案，如XZ。 举例来说，如果XZ可以将一个打包到OpenWrt路由器的软件包的400 KiB（而不是Gzip）刮掉，那么如果路由器有16 MiB的RAM，那么节省的空间有多less呢？ 类似的情况出现在非常老的计算机系统中。 有人可能会嘲笑下载和编译最新版本的Bash的32MB的古老的SparcStation LX的想法，但它发生。
-
这样的系统通常具有较慢的处理器，并且减压时间增加可能非常高。 在200 MHz的ARM内核或50 MHz的microSPARC上，在Core i5上解压三秒的时间可能会很长。 与所有更好的压缩方法（如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可以在相当慢的链接即，通过互联网上的SSH隧道来做同样的事情）。
现在，另一方面，有些情况下XZ压缩比较好：
-
通过慢速链接发送数据。 Linux 3.7内核源代码在XZ格式中比在Gzip格式中小34ByB。 如果你有一个超快的连接，selectXZ可能意味着节省一分钟的下载时间; 在一个便宜的DSL连接或3G蜂窝连接，它可以削减一个小时或更多的下载时间。
-
缩减备份档案。 使用“gzip-9”与“xz-9e”压缩Apache的httpd-2.4.2的源代码产生的XZ档案占Gzip档案大小的62.7％。 如果在数据集中存在相同的可压缩性，那么当前存储的数据集为.tar.gz存档的100 GiB，则转换为.tar.xz存档将会削减备份集高达37.3吉比特。 将整个备份数据集复制到USB 2.0硬盘驱动器（最大传输速率大约为30 MiB /秒），因为GZipped数据需要55分钟，但是XZ压缩会使备份时间减less20分钟。 假设您将在具有大量CPU能力的现代桌面系统上使用这些备份，一次压缩速度不是一个严重问题，使用XZ压缩通常更有意义。 如果你不需要，为什么要在额外的数据上进行混洗？
-
分发大量可能高度压缩的数据。 如前所述，Linux 3.7源代码为.tar.xz为67 MiB，.tar.gz为101 MiB; 未压缩的源代码约为542兆字节，几乎全是文本。 源代码（和一般的文本）通常是高度可压缩的，因为内容中的冗余数量很大，但像Gzip这样的压缩程序（用更小的字典操作）不能利用超出字典大小的冗余。
最终，这一切都归结为四方面的折衷：压缩大小，压缩/解压缩速度，复制/传输速度（从磁盘/networking读取数据）以及压缩器/解压缩器的可用性。 这个select很大程度上取决于“您打算如何处理这些数据？”这个问题。
也看看这个相关的post ，我从中学到了一些我在这里重复的东西。
我在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通过文件滚轮或tar与-z或-J选项一起使用 – 保留压缩本地与tar和保留权限（也可select.tar.7z或.tar.rar可以使用）
更新：作为tar只保留正常的权限，而不是无论如何，也可以使用通过getfacl和sefacl手动清除.7z加上备份和恢复权限和ACL，这似乎是文件归档或系统文件备份的最佳select，因为它会满保留权限和ACL，具有校验和，完整性testing和encryptionfunction，唯一的缺点是p7zip无处不在
老实说，我只是从培训材料中知道.xz格式。 所以我只是用它的git回购做testing。 git是git：//git.free-electrons.com/training-materials.git，我也编译了三个训练幻灯片。 目录总大小为91M，包含文本和二进制数据。
这是我的快速结果。 也许人们仍然青睐tar.gz，因为压缩速度要快得多。 我个人甚至使用普通的tar来压缩时没有太多好处。
[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
来自Lzip压缩工具的作者：
Xz具有复杂的格式，部分专用于可执行文件的压缩，并被devise为通过专有格式进行扩展。 在这里testing的四台压缩机中，xz是唯一一个与“做一件事，做得好”的Unix概念不同的人。 数据共享不太合适，长期归档也不合适。
一般来说，格式越复杂，未来可能被解码的可能性越小。 但是xz格式，就像臭名昭着的前任lzma一样，是特别糟糕的devise。 Xz几乎复制了gzip的所有缺陷，然后增加了一些，比如脆弱的可变长度整数。 在一个可变长整数的任何一个字节的第7位只有一个位翻转，整个xzstream就像一幢房子一样翻倒。 除了压缩短期可执行文件之外，不build议使用xz。
不要误解我的意思。 我非常感谢Igor Pavlov发明/发现LZMA，但是xz是他的追随者利用7zip的stream行优势并用不适当或者devise不当的格式来replacegzip和bzip2的第三次尝试。 特别是，在GNU和Linux中都支持lzma，这是可耻的。
出于同样的原因，Windows（r）中的用户使用压缩文件而不是7zip，有些仍然使用rar而不是其他格式。或者，mp3用于音乐，而不是aac +等等。
每种格式都有其优点，人们使用它们来坚持他们开始使用计算机时学到的解决scheme。 把它添加到硬盘的向后兼容性和快速带宽+ GB或TB空间中，并且更大的压缩的好处将不会是相关的。
gz支持无处不在，便于携带。
XZ是新的，现在广泛或良好的支持。 它比gzip更复杂，压缩选项更多。
这不是人们可能不会总是使用xz的唯一原因。 xz可能需要很长的时间来压缩，而不是一个微不足道的时间，所以即使它可以产生出色的结果，也不总是被选中。 另一个弱点是它可以使用大量的内存，特别是对于压缩。 你想压缩一个项目的时间越长，这就是指数递减的回报。
然而，在我的经验xz的大二进制项目的压缩级别1中，通常可以在比第9级别的zlib更less的时间内产生更小的结果。这有时会是非常显着的差异，与zlib，xz可以创build文件这是zlib文件大小的一半。
bzip2也有类似的情况，但是xz拥有更加优越的优势和强大的整体performance。
gzip的一个重要的一点是它可以与rsync / zsync互操作。 这对于带宽来说可能是巨大的好处。 LZMA / bzip2 / xz不支持rsync，可能不会很快支持。
LZMA的特点之一是它使用安静的大窗口。 为了使rsync / zsync友好，我们可能需要减less这个会降低压缩性能的窗口。
