使用7 Zip压缩文件时，最佳选择是什么？

我经常不得不收集日志文件并将其上传到中央服务器（由另一家公司拥有）。中央服务器具有文件的大小限制，因此我试图创建可能仍为zip格式的最小文件。

当我只需要很小的文件大小时，将文本文件压缩为zip格式时，最佳的设置是什么？

我已经做了明显的选择超压缩，并且我注意到LZMA比放气更胜一筹，但是对于我来说，要测试所有这些选项，还有太多其他选择。

要创建7-Zip可以创建的最小的标准ZIP文件，请尝试：

7z a -mm=Deflate -mfb=258 -mpass=15 -r foo.zip C:\Path\To\Files\*

^{资料来源：如何获得最佳的标准ZIP压缩？}

否则，如果您不关心ZIP标准，请使用以下超级设置：

7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on archive.7z dir1

哪个是：

-t7z   7z archive

-m0=lzma
       lzma method

-mx=9  level of compression = 9 (Ultra)

-mfb=64
       number of fast bytes for LZMA = 64
-md=32m
       dictionary size = 32 megabytes

-ms=on solid archive = on

如果您可以使用.7z格式而不是.zip格式，那么我将简单地将PPMD与以下选项一起使用，并将其他所有设置保留在“压缩级别”中：

• 存档格式：7z
• 压缩方式：PPMD
• 压缩等级：超

我定期使用这些选项压缩服务器/文本日志（60MB +），它们通常以原始大小的1-2％出现。

我在VM上使用p7zip [64] 9.20在Ubuntu服务器14.04.03中比较了db.fdb 1,2 GB（1236598784 B）：

1. 7z a -mx=9 1.7z db.fdb
2. 7z a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on 2.7z db.fdb
3. 7z a -t7z -m0=lzma -mx=9 -mfb=258 -md=32m -ms=on 3.7z db.fdb
4. 7z a -t7z -m0=lzma -mx=9 -mfb=258 -md=32m -ms=on -pass=15 4.7z db.fdb
5. 7z a -mx=9 -mmt=on 5.7z db.fdb
6. 7z a -t7z -m0=lzma -mx=9 -mfb=258 -md=32m -ms=on -mmt=on 6.7z db.fdb

并得到以下结果：

1.7z 96 MB (100108731 B) with 6' 25"
2.7z 95 MB ( 99520375 B) with 5' 18"
3.7z 93 MB ( 97512311 B) with 9' 19"
4.7z 93 MB ( 97512345 B) with 9' 40"
5.7z 96 MB (100108731 B) with 5' 26"
6.7z 93 MB ( 97512311 B) with 9' 09"

我认为第二种方法效果很好=（几乎）以最佳时间进行最佳压缩。但是为了获得最佳的“视图”，并且容易记住的是第一种方法-文件较小且没有最大压缩点。在2和3方法之间，我们不会获得更小的7z，但要多花近两倍的压缩时间。任何人都可以自己决定。

经过大量的实验，深入研究了详细的7zip文档，并阅读了一些有关高级LZMA2参数的7z源代码，这是下面的一种更好的方法。与之前在此处甚至在7z手册中发布的解决方案相比，它减少了一些1GB的实际测试文件2到4倍以上。

7z a -t7z -mx=9 -mfb=273 -ms -md=31 -myx=9 -mtm=- -mmt -mmtf -md=1536m -mmf=bt3 -mmc=10000 -mpb=0 -mlc=0 archive.7z inputfileordir

这里假定使用LZMA2压缩，但是通过传递高级LZMA2选项（例如-m0=LZMA2:27或-m0=LZMA2:d25）或参数数组（例如），您可能能够在7zip中获得更好的性能。

-m0=BCJ2 -m1=LZMA:d25 -m2=LZMA:d19 -m3=LZMA:d19 -mb0:1

我测试过的7z版本似乎并不尊重这些参数，但是您可能想进一步探索或修补7z代码以正确解析它们。又或者它应该可以工作，并且在经过测试的版本中被破坏了。

将“拆分为卷，字节”字段设置为服务器允许的最大文件大小（我认为，以字节为单位，尽管看起来它接受“ KB”和“ MB”之类的常见缩写）。如果zip文件超过该大小，则7-zip会自动将其拆分为多个文件，例如integration_serviceLog.zip.001，integration_serviceLog.zip.002等。（回想一下，PK Zip使用此文件将zip文件跨多个软盘。）您将需要提供所有文件来解压缩它们。使用它，而不用担心用于任何特定文件集的绝对最佳压缩设置，因为一个文件的最佳选择可能与另一文件的不同，并且您不想每次都需要进行此操作复制日志。

我从@ 91735472开始，从上面的答案开始，然后绕到其他地方。我的用例可能有点不寻常：我正在压缩80 GB Windows磁盘的dd映像以用于非营利性Windows翻新商。我们使用Acronis 2015（最后一个具有克隆功能的机器）将它们克隆到要翻新的计算机上。我们有带有不同驱动程序的版本，依此类推。我在自己的服务器级Linux机器上执行此操作：双Xeon总共具有16个内核（32个线程）和256GB主RAM。

我尝试了两个与原始卷略有不同的版本：在制作克隆之前已将其清零。我想看看所有未触及的零会产生多大的变化。它有助于压缩时间和压缩文件的大小，特别是在时间上。

使用原始答案中的7z参数，仅更改为使用16个线程，并且最大程度地占用了一些内存，“脏”克隆花费了120分钟，而置零的克隆仅花费了95分钟。压缩率仅提高了11％。到目前为止，所有测试中的解压缩时间均为8分钟零30秒（解压缩为stdout，重定向至/ dev / null）。压缩后的映像位于3个驱动器的带区RAID上，无论从dd到/ dev / null的复制所需的2秒时间来看，所有映像均位于缓存中。

无论如何，要达到真正的结果。剧透：进行实验很有意义。一种尺寸并不适合所有尺寸。我找不到上面原始答案的所有参数的文档，因此我删除了我不理解的参数。一切都变得越来越小，越来越快。然后，我查看了已记录的内容，并删除了似乎不适用于我的用例的内容。更好。对于“脏”案，我要花费47分43秒，对于归零案，我要花费41m 55s。文件大小仍然较小，但不是很大。最大的收获是压缩时间约为原始答案给我的1/3。

到目前为止，这是我的赢家：7z a -t7z -mx = 9 -md = 31 -mtm =--mmt = 16 -mmtf -md = 1536m

您可能没有16个线程，或者我没有所有的RAM，所以一定要尝试一下。

我的探索尚未完成。我可以指定更多或更少的线程。我只是注意到我有两个-md参数，应该使用它。