问为什么*.tar.gz仍然比*.tar.xz普遍得多？

EN

“最小公分母”。节省的额外空间很少值得失去互操作性。大多数嵌入式Linux系统都有gzip，但没有xz。许多旧系统也是如此。Gnu是行业标准，它支持通过gzip处理的标志-z，通过bzip2处理的和-j，但一些旧系统不支持xz的-J标志，这意味着它需要两步操作(以及大量额外的磁盘空间用于未压缩的.tar，除非您使用|tar xf -的语法-许多人不知道这一点)。此外，在嵌入式ARM上从tar.gz解压大约10MB的完整文件系统需要大约2分钟，这并不是真正的问题。没有关于xz的线索，但是bzip2大约需要10-15分钟。绝对不值得节省带宽。

最终的答案是可访问性，第二个答案是目的。XZ不一定像Gzip那样合适的原因：

• 嵌入式和遗留系统更有可能缺乏足够的可用内存来解压缩诸如XZ之类的LZMA/LZMA2存档。例如，如果XZ可以将发往OpenWrt路由器的数据包的KiB (vs. Gzip)减少400，那么如果路由器有16 MiB的内存，节省的空间又有什么好处呢？类似的情况出现在非常旧的计算机系统上。
• 这类系统的处理器速度通常很慢，解压时间增加会非常快。在200 MHz的ARM内核或50 MHz的microSPARC上，在酷睿i5上额外解压3秒可能会非常长。与所有更好的压缩方法(如XZ甚至Bzip2)相比，Gzip压缩在这样的处理器上非常快。在过去20年中创建的所有类UNIX系统(以及几乎所有非类UNIX系统)几乎都支持
• Gzip。XZ的可用性要有限得多。如果没有解压的能力，压缩是无用的。
• 更高的压缩率需要很长时间。如果压缩时间比压缩比更重要，则Gzip优于XZ。老实说，lzop比Gzip快得多，而且压缩效果也不错，所以那些需要尽可能快的压缩和不需要Gzip的普遍性的应用程序应该考虑一下这一点。我经常使用诸如"tar -c *| lzop -1 | socat -u - tcp-connect:192.168.0.101:4444“这样的命令在可信的局域网连接上快速地洗牌文件夹，Gzip可以在速度更慢的链路上使用类似的方法(即，通过互联网上的SSH隧道执行我刚才描述的相同操作)。

现在，在另一方面，XZ压缩在某些情况下是非常优越的：

• 通过慢速链路发送数据。Linux3.7内核源代码XZ格式比Gzip格式小34 MiB。如果你有一个超快的连接，选择XZ可能意味着节省一分钟的下载时间；在廉价的DSL连接或3G蜂窝连接上，它可以减少一个小时或更多的下载time.
• Shrinking备份档案。使用" Gzip -9“与"xz -9e”压缩Apache的httpd-2.4.2的源代码，得到的XZ归档的大小是Gzip归档的62.7%。如果在您当前存储为100 GiB的.tar.gz归档的数据集中存在相同的可压缩性，则转换为.tar.xz归档将大幅削减备份集的37.3 GiB。将整个备份数据集复制到USB 2.0硬盘驱动器(最多30 MiB/秒的传输)作为this数据将需要55分钟，但XZ压缩将使备份时间缩短20分钟。假设您将在具有充足CPU能力的现代台式机系统上处理这些备份，并且一次性压缩速度不是一个严重问题，那么使用XZ压缩通常更有意义。如果您不需要to?
• Distributing大量可能高度可压缩的数据，为什么还要处理额外的数据呢？如前所述，Linux3.7的源代码对于.tar.xz是67 MiB，对于.tar.gz是101 MiB；未压缩的源代码大约是542 MiB，并且几乎全是文本。由于内容中的冗余量，源代码(以及一般的文本)通常是高度可压缩的，但像Gzip这样使用小得多的字典运行的压缩器无法利用超出其字典大小的冗余。

最终，这一切都归结为四个方面的权衡:压缩大小、压缩/解压缩速度、复制/传输速度(从磁盘/网络读取数据)和压缩器/解压缩器的可用性。选择高度依赖于“您打算如何处理这些数据？”这一问题。

还有check out this related post，我从中学到了一些我在这里重复的东西。

来自Lzip压缩实用程序的作者：

Xz具有复杂的格式，部分专门用于可执行文件的压缩，并设计为通过专有格式进行扩展。在这里测试的四个压缩器中，xz是唯一一个不符合Unix“做一件事，做好它”的概念的压缩器。它不太适合数据共享，也不适合长期归档。

一般来说，格式越复杂，将来被解码的可能性就越小。但是xz格式，就像它臭名昭著的前身lzma一样，设计得特别糟糕。Xz复制了gzip的几乎所有缺陷，然后添加了更多的缺陷，比如脆弱的可变长度整数。只需在可变长度整数的任何字节的第7位中进行一位翻转，整个xz流就会像纸牌屋一样倒塌。除了压缩生命周期短的可执行文件之外，使用xz做任何事情都是不可取的。

别误会我。我非常感谢Igor Pavlov发明/发现了LZMA，但xz是他的追随者第三次尝试利用7zip的流行，用不适当或设计糟糕的格式取代gzip和bzip2。尤其令人遗憾的是，GNU和Linux都实现了对lzma的单独支持。

http://www.nongnu.org/lzip/lzip_benchmark.html