压缩率多少合适,没有统一答案。jpg、mp4、docx 这类文件内部已经做过压缩,再压一遍体积基本不降,这种情况只打包不重压更省时间;txt、log、bmp 这类还能压动的文件,才值得往高档位调。
压出来时大时小、档位拉到最高体积也不降,多数是文件类型和档位没对上,文件本身大多没坏,不用急着换软件,也不用反复重压。在 D:\data 里把 3.2GB 的 jpg 图片压成 zip,进度条几秒走完,包体积还是 3.19GB,压缩率显示 0%;换成 7z 的 -mx=9 极限档重压,等了二十多分钟,480MB 只掉到 476MB。这两种情况与软件质量无关,是文件内容本身已经压不动了。
先判断文件能不能压,再确认档位设置,比直接拉最高档省下大量等待时间。 下面这些步骤在 Windows 10/11 上实测可用。
两个数方向相反,口径没统一,就会出现「一次 40%、一次 90%」的错觉:压缩率看的是压掉了多少,压缩比看的是原始大小与压缩后大小的关系。同一批文件里,一个变大,另一个必然变小。

记反了容易出岔子:同一批文件里压缩率变大,压缩比必然变小。
口径统一之后,用同一个公式去算两次压缩的结果,就能判断到底是设置问题还是文件问题。
能压到什么程度由文件内容决定,档位只决定花多少时间。已经压过的格式,档位从 1 调到 9,体积往往只差百分之几。

可压文件单独压一遍再合并,通常比整包硬压更省时间,压出来的总体积也更小。
-mx 档位不是越高越好,谁的降幅大、谁花的时间少,实测一次就清楚。三个档位跑完大概十分钟,比反复猜快得多。
Win+R → cmd,先切到目标目录cd /d D:\data
7z a -mx=1 fast.7z D:\data
7z a -mx=5 normal.7z D:\data
7z a -mx=9 max.7z D:\data
7z a -mm=LZMA2 out.7z D:\data若从 -mx=5 到 -mx=9 的体积降幅不足 5%,日常就用 -mx=5,多出来的那点体积不值得等。

档位已经到顶还嫌大,就换算法或者分卷,继续加档几乎没有意义。同一批文件换成 LZMA2,收益往往比升档更明显。
7z a -v100m out.7z D:\data,生成每卷 100MB 的分卷包7z t out.7z,确认无误再删除原始文件分卷包必须整组放在同一个文件夹里才能解压,用移动硬盘或者网盘传输时别漏卷,漏掉一卷整个包都打不开。
情况 | 表现 | 处理 |
|---|---|---|
已压缩格式(jpg / mp4 / docx) | 档位 1 调到 9 体积几乎不变, | 选「仅存储」,只打包不重压 |
同一个文件夹压两次 | 体积差几百字节 | 时间戳与压缩包头部带来的正常差异,不必重压 |
目标体积卡得很死 | 升档已经没有收益 | 换 LZMA2 算法,或叠加分卷分批发 |
需要整组传输的分卷包 | 缺一卷整个包都打不开 | 整组放在同一目录,校验通过再删原始文件 |
看文件类型。已经压过的文件,档位高低对体积影响很小,选「仅存储」只打包更省时间;txt、日志、bmp 才值得上高档位。目标是刚够满足体积要求,把档位拉满并不划算。
不够。最高档耗时成倍增加,对已压缩格式的降幅可能不到 1%。先用 -mx=5 压一次看体积,达不到目标再升到 -mx=9,或者把算法换成 LZMA2。
文件内部已经是压缩格式,没有多余内容可压。JPG、MP4 的编码本身已经去掉了重复数据,-mx 只控制算法花多少力气,改不了文件本身的信息量。
方向相反。压缩率 =(原始大小 − 压缩后大小)÷ 原始大小 × 100%,数值越大压得越多;压缩比写成「原始:压缩后」,数值越大表示压得越少。同一批文件,压缩率 40% 对应的压缩比约 1.67:1。
正常。两次选的文件列表、格式、档位只要有一项不同,体积就会变;时间戳和压缩包头部信息也会让同一个算法压出几百字节的差异。
档位挑到刚够满足体积的那一档就停下,为最后百分之几的体积把时间翻几倍,不划算。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。