7-Zip 打包不算压缩？归档压缩与内容压缩的本质区别

压缩原理 2026-07-29 · 丑梨数据

一个让无数人困惑的现象

你一定遇到过这样的场景：同事发来一份 50MB 的 PDF 报告，你嫌太大，顺手用 7-Zip 打了个压缩包，满怀期待地等待体积骤降——结果压缩包是 49MB。你发给对方，对方解压之后，文件还是 50MB，一个字节都没少。

这不是个例。把一个已经压缩过的 MP4、JPG 或 PDF 塞进 ZIP 压缩包，体积几乎纹丝不动。但同样用 7-Zip，把一堆没压缩过的 TXT、BMP、CSV 打包，体积却能缩到原来的十分之一。

为什么会出现这种天壤之别？答案藏在一个被大多数人忽略的概念里：归档压缩和内容压缩是两件完全不同的事。理解这个区别，你才能在正确的场景下用对工具，而不是对着一个 49MB 的压缩包干瞪眼。

一、归档压缩：打包容器的艺术

归档压缩（Archive Compression）做的是"容器层面"的事情。它的核心动作有两个：第一，把多个文件打包成一个容器；第二，用无损压缩算法消除数据中的冗余。

常见的归档格式——ZIP、7Z、TAR.GZ、RAR——背后都跑着类似的压缩算法。ZIP 默认使用 DEFLATE 算法，它由 LZ77 和 Huffman 编码两部分组成：LZ77 负责找出数据中重复出现的字节串，用"距离+长度"的引用替代原始数据；Huffman 编码再对出现频率不同的字符分配不等长的二进制编码，高频字符用短码，低频字符用长码。7-Zip 的 7Z 格式则默认使用 LZMA 算法，它在 LZ77 的基础上引入了范围编码（Range Coding），并支持更大的字典窗口，压缩率通常比 DEFLATE 更高。

关键在于：归档压缩从不改变文件内容本身。它只是把文件看作一串字节流，寻找字节流中的统计冗余。当你解压一个 ZIP 包时，得到的文件和压缩前逐字节相同，连一个像素都不会变。

这就解释了开头那个现象。PDF 文件内部早就用 DEFLATE 压缩过图片和字体流，JPG 本身就是压缩格式，MP4 用 H.264/H.265 编码压缩了视频帧。这些文件里的冗余已经被"榨干"了，归档压缩算法再怎么聪明，也榨不出多少油水。相反，BMP 位图、未压缩的 WAV、纯文本 CSV 里充斥着大量可压缩的重复模式，归档压缩才能大展身手。

归档压缩真正擅长的，是处理多个文件之间的冗余。比如一个文件夹里有 100 张截图，每张都带有相同的 logo 水印和相似的工具栏，LZMA 的大字典能识别出这些跨文件的重复数据，从而实现比单文件压缩更可观的压缩率。这也是为什么"打包多个文件"比"逐个压缩再发送"更高效。

这里有必要解释一下压缩字典的作用。DEFLATE 和 LZMA 都维护一个滑动窗口——也就是字典——用来匹配最近出现过的数据。DEFLATE 的窗口固定为 32KB，能回溯查找的重复距离有限；LZMA 则允许配置 64MB 甚至更大的字典，意味着第一个文件里出现的模式，到最后一个文件出现时仍能被引用。这就是为什么把许多相似文件打成一个大压缩包，比把它们分别打成多个小压缩包效果更好：字典能利用的素材更多，跨文件冗余得以捕获。如果每个文件单独打包，每个压缩包都从空字典开始，文件间的冗余就白白浪费了。

二、内容压缩：从内部重新构造数据

内容压缩（Content Compression）走的是另一条路。它不关心文件有几份，也不做打包，而是直接钻进单个文件的内部结构，针对文件的具体类型重新优化数据。

不同类型的文件，内容压缩的手法完全不同：

图片可以重采样（把 4000×3000 的原图缩到 1920×1080）、重编码（把 PNG 转成 WebP 或 AVIF）、降低色深（24 位降到 8 位索引色）。一张 8MB 的手机照片，合理调整分辨率和质量参数后，常常能压到 500KB 以下，而肉眼几乎看不出差别。

PDF 可以对内嵌的图片重新采样、把未压缩的字体流转成 CFF 子集、删除未引用的对象、把重复的 XObject 合并。一份满是高清插图的 50MB 设计稿，经过内容压缩往往能瘦身到 5-8MB。

PDF 是个特别值得剖析的例子，因为它本身就是个容器。一个 PDF 把每张图片存成流对象，每个字体存成另一个流，正文则存为编码后的内容流。大多数生成器已经对文本和字体流做了 DEFLATE 压缩，对照片类图片用了 JPEG 或 DCT。这正是一份 PDF 喂给归档工具几乎纹丝不动的原因——容易摘的果子早被摘光了。内容压缩则逐个流重新审视：把分辨率超出目标显示需求的图片降采样，在可接受时把无损图片流转成 JPEG，丢弃内嵌缩略图、隐藏图层这类元数据，合并重复的表单 XObject。结果不是"同一份数据套了个更小的壳"，而是一份从根本上更精简的文档。

字体可以做子集化（Subsetting），只保留文档中实际用到的几十个字形，而不是把整个包含上万字形的字库文件全塞进去。

视频/音频可以用更高效的编码器重新编码，比如把 H.264 升级到 H.265，码率减半而画质不变。

内容压缩有一个根本特征：它往往会改变文件的内部数据，很多时候是有损的。压缩后的图片无法还原成原始像素，子集化后的字体也拼不回完整字库。换来的是，文件体积从源头变小了，使用时无需解压，直接打开就是优化后的状态。

三、两种压缩的流程对比

下图直观展示了归档压缩与内容压缩在流程上的本质差异：

流程图 1

左边这条线是"打包-传输-解压-恢复"的循环，文件内容自始至终没变；右边这条线是"分析-优化-生成"的单向过程，文件本身被重新构造了。

四、代码演示：一眼看出区别

用 Python 可以非常清楚地演示两种压缩的差异。

归档压缩：用 zipfile 打包


import zipfile
import os

# 归档压缩：把多个文件打包成一个 zip
source_files = ['report.pdf', 'photo.jpg', 'data.csv']
archive_name = 'bundle.zip'

with zipfile.ZipFile(archive_name, 'w', zipfile.ZIP_DEFLATED) as zf:
    for file in source_files:
        zf.write(file)

# 计算压缩效果
original = sum(os.path.getsize(f) for f in source_files)
packed = os.path.getsize(archive_name)
print(f"原始总大小: {original / 1024 / 1024:.2f} MB")
print(f"压缩包大小: {packed / 1024 / 1024:.2f} MB")
print(f"压缩率: {packed / original * 100:.1f}%")

# 典型输出（文件已被各自格式压缩过）:
# 原始总大小: 58.30 MB
# 压缩包大小: 57.10 MB
# 压缩率: 97.9%

注意看压缩率——几乎没变。因为这些文件本身已经是压缩格式，归档压缩无能为力。

内容压缩：用 PIL 优化图片


from PIL import Image
import os

# 内容压缩：直接优化图片本身的数据
src = 'photo.jpg'
dst = 'photo_optimized.jpg'

img = Image.open(src)
before = os.path.getsize(src)

# 三管齐下的内容压缩
img.thumbnail((1920, 1080))  # 降低分辨率
img.save(dst, 'JPEG',
         quality=75,        # 降低质量
         optimize=True,     # 优化 Huffman 表
         progressive=True)  # 渐进式编码

after = os.path.getsize(dst)
print(f"原始大小: {before / 1024 / 1024:.2f} MB")
print(f"优化后大小: {after / 1024:.2f} KB")
print(f"压缩率: {after / before * 100:.1f}%")

# 典型输出:
# 原始大小: 8.20 MB
# 优化后大小: 480.50 KB
# 压缩率: 5.7%

同样是"压缩"，一个把 58MB 压成 57MB，一个把 8MB 压成 480KB——差距来自压缩对象不同：前者只动容器，后者动了内容。

五、对比一览表

维度归档压缩内容压缩
做什么打包多个文件并消除冗余优化单个文件的内部数据
压缩对象文件容器（多文件层面）文件内容（数据层面）
压缩方式DEFLATE / LZMA 等无损算法重采样 / 转码 / 子集化等
是否有损无损，解压后完全还原多数有损，不可逆
使用方式需要解压后才能使用直接使用，无需解压
典型场景传输多个文件、备份归档减小体积、网页优化、邮件附件
压缩效果取决于冗余度，已压缩文件几乎无效可达 10 倍以上压缩比

六、实战案例：50MB PDF 的两种命运

拿一份真实的 50MB PDF（内含多页高清扫描图）做对比：

方案 A：归档压缩

  • 工具：7-Zip，LZMA2 极限压缩
  • 结果：50MB → 49.2MB
  • 原因：PDF 内部的图片流早已用 JPEG + DCTDecode 压缩，字体流也做了 FlateDecode，归档压缩找不到可榨的冗余。

方案 B：内容压缩

  • 操作：对内嵌图片降采样到 150 DPI、把 JPEG 质量降到 75、字体子集化、删除未引用对象
  • 结果：50MB → 6.8MB
  • 原因：直接动了 PDF 内部最占体积的部分——高清扫描图。150 DPI 对于屏幕阅读完全够用，肉眼几乎察觉不到画质损失。

两种"压缩"的结局差了 7 倍。如果你只是想把这份 PDF 发邮件，方案 B 才是正解；方案 A 只会白费功夫。

七、选择正确的方案

手握两种工具，决策其实很清晰。先问自己要达成什么目的：

  • 要一次搬运很多文件？ 用归档压缩。它一步完成打包、校验和消冗，适合备份、源码分发、传输整个目录结构。
  • 要让单个文件变小？ 用内容压缩。一份要发邮件的 50MB PDF 放进 ZIP 不会变小，但把内部图片降采样后却能大幅瘦身。
  • 两者都要？ 先对每个文件做内容压缩，再用归档压缩打包。顺序不能反：内容优化必须在文件内部结构还可访问时进行，一旦封进压缩包就无法介入了。

一个有用的心智模型：归档压缩降低的是"传输"成本，内容压缩降低的是"存储"成本。如果文件已经小到能传输、却要长期挂在服务器上，内容压缩能在每次下载时省下带宽；如果只是临时搬运一批文件，归档压缩是更轻量的选择。

八、常见问题 FAQ

Q1：为什么 7-Zip 压缩 PDF / JPG / MP4 几乎没效果？

因为这些文件本身已经是压缩格式。PDF 内部用 DEFLATE 压缩了图片和字体流，JPG 用 DCT 变换压缩了图像数据，MP4 用 H.264/H.265 压缩了视频帧。归档压缩算法面对的是"已经压缩过"的数据，找不到可消除的统计冗余，自然压不动。归档压缩真正有效的是未压缩的原始数据，如 BMP、WAV、纯文本。

Q2：内容压缩会损失质量吗？如何平衡体积和质量？

多数内容压缩是有损的，但损失程度可控。图片可以通过调整分辨率和质量参数在体积与清晰度间权衡——屏幕展示用 72-96 DPI、质量 75 通常足够，打印才需要 300 DPI。字体子集化是无损的，不影响显示。关键是根据使用场景决定压缩力度，而不是一刀切。

Q3：归档压缩和内容压缩可以一起用吗？

可以，而且常常这样组合。典型流程是：先做内容压缩，把每个文件从源头缩小；再做归档压缩，把缩小后的文件打包传输。顺序很重要——先内容后归档。如果反过来，归档压缩会锁死文件结构，内容压缩就无法介入了。先优化内容，再打包归档，才能同时拿到两端的收益。

总结

归档压缩和内容压缩虽然都叫"压缩"，却是两个层面的操作：归档压缩在容器层面打包消冗，无损可还原，但对已压缩文件效果有限；内容压缩在数据层面重新构造文件，有损不可逆，但能从源头大幅瘦身。

下次再遇到"压了半天没变小"的尴尬，先问问自己：我压的是容器，还是内容？选对层面，压缩才能真正发挥作用。

相关阅读：