最后更新：2026年9月10日

How Compression Works Inside EPUB, DOCX, XLSX, & PPTX: The Hidden ZIP Architecture

压缩在 EPUB、DOCX、XLSX 和 PPTX 中的工作原理

如果你将 .docx、.xlsx、.pptx 或 .epub 文件重命名为 .zip 并双击它，会出现令人惊讶的情况：它不会报错。你的操作系统会将其打开为一个包含子目录、XML 配置文件、样式表、字体和嵌入图像的文件夹。

现代文档架构在数十年前就抛弃了单块二进制文件。取而代之的是行业标准——即 Microsoft Office 的 Open Packaging Conventions (OPC) 和 EPUB 的 Open Container Format (OCF)——采用了一个出人意料的简洁基础：朴素的 ZIP archive。

了解这些格式内部的压缩工作原理，就能揭示现代文档为何如此坚韧、轻量且可扩展——以及为何有些文件能压缩至原始大小的 90%，而另一些几乎没有缩小。

1. 容器架构：伪装的 ZIP 包

在了解压缩算法本身之前，先弄清楚为何现代文档格式被构建为包而不是独立的原始文件会更有帮助。

传统二进制格式的问题

在整个 1990 年代和 2000 年代初，Microsoft Office 使用专有的二进制格式（.doc、.xls、.ppt）。这些文件本质上是围绕复合文件二进制格式（Compound File Binary Format (CFBF)）结构的内存转储。它们以极其脆弱而闻名：

  • 一次单比特翻转就可能破坏整个文件结构。
  • 嵌入图像会导致文件大小不可预测地急剧膨胀。
  • 解析需要逆向工程繁复的二进制规范。
  • 跨平台互操作性是一场噩梦。

向开放、模块化容器的转变

在2000年代中期，发生了两条平行的演进：

  1. Office Open XML (OOXML / ISO/IEC 29500)： 微软推出了以 x 结尾的基于 XML 的格式（DOCX、XLSX、PPTX）。在内部，这些文件遵循 Open Packaging Conventions (OPC)。
  2. EPUB (IDPF / W3C)： 数字出版从专有阅读器格式转向基于标准网页技术（HTML、CSS、SVG）的方式，并封装在 EPUB Open Container Format (OCF) 中。

这两种架构都依赖于标准的 PKZIP 2.0 / ZIP 规范。文件扩展名仅决定了预期的模式、默认的查看器应用程序以及 MIME 类型声明。

Sample DOCX File (Unzipped):
├── [Content_Types].xml        <-- Registry of MIME types for parts
├── _rels/                     <-- Package-level relationships
│   └── .rels
├── docProps/                  <-- Core and extended metadata
│   ├── app.xml
│   └── core.xml
└── word/                      <-- Main content payload
    ├── document.xml           <-- Text, paragraphs, and tags
    ├── styles.xml             <-- Typography and presets
    ├── numbering.xml          <-- Lists and counters
    ├── media/                 <-- Embedded images (PNG, JPG)
    └── _rels/
        └── document.xml.rels  <-- Internal hyperlinks & resource pointers

2. 引擎内部：DEFLATE 算法

当软件应用程序保存 DOCX 或 EPUB 文件时，它不仅仅是将文件存入未压缩的归档中，而是使用 DEFLATE（在 RFC 1951 中规定）对内部资源进行压缩。

DEFLATE 是一种两层无损压缩系统，结合了两种基础的计算机科学算法：

步骤 1：LZ77（Lempel-Ziv 1977）— 滑动窗口冗余消除

XML 和 HTML 非常冗长。考虑在标准的 document.xml 或 chapter1.xhtml 文件中标签出现的频率：

  • <w:p><w:r><w:rPr><w:sz w:val=\"24\"/></w:rPr><w:t> 在 Word 中重复出现数千次。
  • row r=\"1\" spans=\"1:15\"><c r=\"A1\" t=\"s\"><v> 在 Excel 中遍布数万单元格。
  • <p class=\"calibre1\"><span class=\"body-text\"> 在 EPUB 书籍章节中重复出现。

LZ77 使用滑动字典窗口（通常为 32 KB）扫描数据流。当它遇到最近出现过的字符序列时，会用一个微小的后向指针替换重复的文本：

  • (distance, length) — 例如，“回退 142 字节，复制 28 字节”。

与其一次又一次地存储冗长的标记，LZ77 将成千上万的重复 XML 标签压缩为紧凑的坐标引用。

步骤 2：霍夫曼编码 — 可变长频率编码

在 LZ77 用长度-距离标记替换冗余序列后，霍夫曼编码 会分析流中每个符号的出现频率：

  • 经常出现的符号（如常见字符 e、t、空格或常见距离标记）被分配短的二进制位码（例如，2 到 4 位）。
  • 很少使用的符号会获得更长的二进制位码（例如，12 到 16 位）。

结果是一串可变长度的位码，将纯文本 XML 压缩至 75% 到 88%。

3. 按格式拆解：每种格式如何处理压缩

虽然 DOCX、XLSX、PPTX 和 EPUB 都使用相同的 ZIP 包装，但它们内部数据特性差异极大。

A. DOCX：文本与样式的平衡艺术

  • 内容包括： 纯 XML (word/document.xml)，字体表，样式，关系目录，以及 word/media/ 文件夹。
  • 压缩表现：
    • 原始文本和 XML 标记能够实现巨大的压缩比（通常从 5 MB 的原始 XML 降至 500 KB）。
    • 然而，现代文档常常嵌入截图、插图和照片。由于 JPEG 和 PNG 文件 已经压缩，DEFLATE 无法进一步缩小它们。事实上，对已经压缩的图像使用 DEFLATE 几乎没有任何节省（甚至可能因压缩头而略微增大）。
    • 因此，没有图像的 DOCX 文件异常小巧，而图像密集的报告几乎与其包含的图像文件大小相同。

B. XLSX：大容量数值数据与共享字符串

电子表格带来了独特的挑战：一个工作表可能包含数十万行，如果处理不当，XML 文件大小会变得天文般庞大。

  • 共享字符串策略 (xl/sharedStrings.xml):
    • 如果像 “United States” 或 “In Progress” 这样的文本标签在电子表格中出现 50,000 次， 在 50,000 个单元格中存储 <c t=\"inlineStr\"><is><t>United States</t></is></c> 会导致未压缩的 XML 膨胀到数千兆字节。
    • Excel 在压缩前通过将每个唯一字符串仅存储一次在共享字符串表中，并通过数值索引进行引用（例如 <v>0</v>、<v>1</v>）来去重文本。
  • 为什么 XLSX 能显著压缩:
    • 数值行记录（sheet1.xml）遵循重复且可预测的语法。
    • DEFLATE 能轻松检测表格 XML 中的重复模式。通常，一个 120 MB 的原始 sheet1.xml 文件在 XLSX 压缩包中会缩小到不足 6 MB。

C. PPTX：媒体重的幻灯片套件

演示文稿在本质上与文档和电子表格不同：

  • 图像困境: PPTX 文件通常主要由矢量形状、背景图形、视频剪辑和高分辨率幻灯片构成。
  • 压缩概述: 当 ppt/slides/slide1.xml 到 slideN.xml 能够高效压缩时，媒体负载（ppt/media/）占整个归档重量的 85% 到 95%。
  • 重新压缩 PPTX 并不会改变任何内容: 如果你尝试使用 7-Zip 或 WinRAR 对已保存的 PPTX 文件再次压缩，你会发现几乎没有尺寸减小。因为内部已经是一个使用 DEFLATE 压缩的 ZIP 存档，里面包含预先压缩好的 JPEG 和 MP4，熵已经接近最大。

D. EPUB：带有必需未压缩头部的网络技术

EPUB 文件本质上是一个响应式、打包的微型网站，包含 XHTML 章节、CSS 样式表、TTF/WOFF 字体和元数据。然而，EPUB 有一条严格的打包规则，使其区别于 Microsoft Office 文件：

EPUB Internal Structure:
├── mimetype                    <-- MUST be uncompressed (Stored) & at byte offset 38
├── META-INF/
│   └── container.xml           <-- Tells reader where the OPF manifest lives
└── OEBPS/ (or EPUB/)
    ├── content.opf             <-- Manifest of all book assets
    ├── toc.ncx / nav.xhtml     <-- Table of contents navigation
    ├── styles/style.css        <-- CSS formatting
    ├── images/                 <-- Book cover & illustrations
    └── text/                   <-- chapter1.xhtml, chapter2.xhtml
  • 神奇的 mimetype 文件:
    • 电子阅读器需要立即识别 EPUB，而无需提取整个归档或运行解压管道。
    • 开放容器格式（OCF）规定 mimetype 文件必须：
      1. 必须是 ZIP 归档中的第一个文件。
      2. 必须恰好包含字符串 application/epub+zip。
      3. 不得压缩 (ZIP 压缩方法 0 / “存储”).
      4. 必须没有额外的字段数据，确保 MIME 字符串始终在物理文件的第 38 字节开始。
  • 文本压缩： 所有其余文件（.xhtml、.css、.opf）使用标准 DEFLATE（ZIP 方法 8）进行压缩，使完整的小说可以缩小到几百千字节。

4. 比较不同格式的压缩

格式核心负载主要冗余来源典型压缩比（文本/标记）媒体处理
DOCXWordprocessingML (document.xml)重复的 XML 段落/运行标签75% – 85%存储在 word/media/（大多数已预压缩）
XLSXSpreadsheetML (sheet*.xml)重复的单元格/行标签；共享字符串80% – 92%稀疏；images/charts 位于 xl/media/
PPTXPresentationML (slide*.xml)幻灯片布局元数据，形状坐标70% – 80%庞大的 ppt/media/ 负载限制了整体节省
EPUBXHTML、CSS、OPF、NCXHTML 标签、重复的 CSS 选择器65% – 80%mimetype 未压缩；媒体在子文件夹中

5. 实用要点：如何优化您的文档

因为您现在了解内部打包的工作原理，您可以利用压缩机制来解决实际问题：

  1. 修复损坏的文档： 如果文档拒绝打开，将扩展名更改为 .zip 可以让您提取内容，并从 document.xml 中恢复原始文本，或从 EPUB 的 text/ 目录中获取各章节。
  2. 压缩巨大的 Office 文件： 由于 XML 压缩已经过优化，巨大的文件几乎总是由 media/ 中未优化的图像导致的。与其使用第三方 PDF 或 DOCX 压缩工具，不如打开 ZIP 容器，提取图像，使用图像优化器（如 WebP、TinyPNG 或 MozJPEG）进行优化，然后将其替换回归档中。
  3. 自动化文档生成: 开发者无需使用重量级的办公套件来生成报告。您可以生成原始 XML 模板，使用标准的 zlib/ZIP 库进行打包，并以毫秒级的速度以编程方式输出有效的 DOCX 或 XLSX 文件。

6. 常见问题解答 (FAQ)

我可以仅通过重命名文件扩展名将 DOCX 或 EPUB 转换为 ZIP 文件吗？ 是的；将扩展名重命名为 .zip 可让任何标准归档工具（如 7-Zip、macOS Archive Utility 或 Windows Explorer）直接打开并检查内部文件。

为什么使用 7-Zip 压缩 DOCX 或 PPTX 并不会显著变小？ 因为该文件已经是内部压缩的 ZIP 档案，包含 DEFLATE 编码的 XML 和预先压缩的图像，几乎没有冗余可供外部工具进一步删除。

为什么 EPUB 规范要求 mimetype 文件未压缩？ 它允许电子阅读器软件通过在固定的字节偏移处检查 MIME 字符串来验证文件是正宗的 EPUB，而无需初始化解压引擎。

更改 Excel 中的单元格格式会增加压缩后的 XLSX 文件大小吗？ 是的；大量的自定义格式会打破单元格之间的统一模式重复，生成更长的 XML 定义，从而降低 DEFLATE 的压缩效率。

是否可以从 Word 或 PowerPoint 文件中提取高分辨率的原始图像而不损失质量？ 是的；将文件重命名为 .zip，打开 word/media 或 ppt/media 文件夹，你会发现原始的、未压缩的源图像，正如它们被插入时的样子。

另见