Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29500-2 — Office Open XML 文件格式 — 第2部分：开放打包约定
OPC 包模型：关系、部件、内容类型与物理包装工程
ISO/IEC 29500-2 定义了开放打包约定（OPC），这是支撑所有 OOXML 文档格式的基础包装技术。OPC 规定了应用数据——部件、关系和元数据——如何通过使用 ZIP 归档作为物理容器，组织成一个自包含的包。虽然 OPC 是为 OOXML 设计的，但其通用架构已被其他标准采用，包括 XPS（OpenXPS）文档格式和各种行业特定容器格式。理解 OPC 对于任何从事结构化文档格式工作的工程师来说都是必不可少的。
任何有效的 OPC 包也是一个有效的 ZIP 归档。这意味着你可以使用任何标准 ZIP 工具检查任何 .docx、.xlsx 或 .pptx 文件的原始内容。这种可调试性是 OPC 相对于不透明二进制格式的最大实际优势之一。
1. OPC 包模型：部件与关系
OPC 模型建立在两个基本抽象之上：部件和关系。部件是一个逻辑存储单元，具有 MIME 内容类型和 ZIP 归档内的压缩流。关系是源部件和目标部件（或外部资源）之间的类型化有向链接。关系存储在称为关系部件的 XML 片段中，通常以 .rels 后缀命名。
| OPC 概念 | 描述 | 示例 |
|---|---|---|
| 部件 | 具有内容类型的命名流 | /word/document.xml (Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document.main+xml) |
| 关系 | 从源部件到目标的类型化链接 | rId1 → /word/media/image1.png (Type: http://schemas.openxmlformats.org/officeDocument/2006/relationships/image) |
| 包级别关系 | 源为包根的关系 | Package → /word/document.xml (Type: …/officeDocument) |
| 内容类型 | 标识部件格式的 MIME 类型 | [Content_Types].xml — 路由所有内容类型的单一部件 |
| 部件名称 | 使用正斜杠路径表示法的 Unicode 字符串 | /word/theme/theme1.xml |
OPC 中的部件名称遵循严格规则：它们必须是有效的绝对 URI 路径，以 “/” 开头，使用正斜杠，并且避免需要使用百分比编码的字符（除非无法避免）。部件名称不区分大小写但保留大小写——这一设计选择简化了跨平台互操作性。
以编程方式构建 OPC 包时，始终遵循”关系优先”模式：(1) 创建部件及其内容，(2) 为每个有传出关系的部件创建 .rels 文件，(3) 创建包级别的 .rels 文件，(4) 最后生成 [Content_Types].xml。遇到没有内容类型条目的部件时，工具会优雅地失败，但缺失关系文件可能导致静默数据丢失。
2. 物理包：ZIP 格式详情
物理 OPC 包是具有特定约束的标准 ZIP 归档。ZIP 格式必须对部件使用 DEFLATE 压缩（允许存储方法但不推荐），并且归档不能跨多个卷。[Content_Types].xml 部件必须是 ZIP 文件中的第一个条目——这是唯一的有序约束，它实现了 OPC 包的流式消费。
| ZIP 特性 | OPC 要求 | 工程影响 |
|---|---|---|
| 压缩 | DEFLATE（允许存储方法） | 已压缩的图像和媒体应使用”store”以避免双重压缩 |
| 加密 | 不允许标准 ZIP 2.0 加密 | 使用 OPC 数字签名或打包级加密 |
| 条目排序 | [Content_Types].xml 必须是第一个 | 流式读取器依赖此项进行内容类型解析 |
| 条目名称 | UTF-8（无 CP437/IBM437 编码） | 跨平台兼容性需要在 ZIP 本地头中设置 UTF-8 标志 |
| 分段 | 不支持多卷归档 | OPC 包始终是单文件；大型文档使用 OPC 分块 |
一个常见的与 ZIP 相关的陷阱是在 ZIP 内部使用 Windows-1252（CP437）编码的条目名称。OPC 强制要求 UTF-8。使用 Java 的 java.util.zip 或 Python 的 zipfile 模块时，在每个 ZipEntry 或 ZipInfo 对象上显式设置 UTF-8 标志。未能这样做会产生无法通过 OPC 一致性验证的包。
3. 内容类型路由与 [Content_Types].xml
[Content_Types].xml 部件充当整个包的 MIME 类型目录。包中的每个部件必须有对应的内容类型条目，可以通过部件特定的覆盖或默认扩展名映射来实现。解析算法很简单：(1) 精确部件名称匹配优先，(2) 如果没有覆盖存在，则使用文件扩展名的默认值，(3) 如果两者都不存在，则包无效。
从工程角度看，覆盖/默认的双重性实现了高效的规范：常见的扩展名（例如 .xml、.png、.rels）获得单个默认条目，而具有非标准或上下文特定类型的部件使用覆盖。这减少了包含许多相似部件的包的 [Content_Types].xml 大小。
最常见的 OPC 验证失败之一是部件缺少内容类型条目。向现有包添加部件时，始终更新 [Content_Types].xml。调试提示：如果 OOXML 应用程序报告”内容无法读取”而没有进一步详情，第一步诊断是验证 ZIP 中所有部件是否有对应的内容类型条目。
4. 数字签名与包安全
OPC 规定了全面的数字签名框架。签名作为 OPC 部件存储在 /_xmlsignatures/ 下，并通过关系引用已签名的部件。该框架支持多个签名者、签名策略（例如，仅签名部件、签名关系）和共同签名场景。签名验证涉及验证 XML 签名、检查没有未签名的部件被添加，以及确认没有已签名的部件被修改。
签名框架使用 W3C XML 签名（XMLDSIG）标准并带有特定的 OPC 配置文件。实现 OPC 签名验证的工程师应仔细注意转换链：OPC 要求在签名前进行信封式签名转换和关系转换，以规范化关系内容。
问：我可以在不破坏 OPC 包的情况下向其中添加任意文件吗？
答：可以，但你必须使用新部件的条目更新 [Content_Types].xml。此外，如果你希望该部件可被发现，你需要从已知部件（或从包根）添加一个关系指向它。没有入站关系的部件不能通过标准 OPC 导航 API 访问，但如果其内容类型已注册，则仍然有效。
问：OPC 中部件大小的上限是多少？
答：OPC 没有规定部件大小限制。但是，底层的 ZIP 格式将 DEFLATE 压缩条目的未压缩数据限制为 2^32 – 1 字节（约 4 GB）。对于更大的内容，使用 OPC 分块模式——通过容器关系将内容分割到多个顺序部件中。
问：OPC 如何处理外部关系？
答：外部关系引用包外部的资源（例如，指向 Web URL 的超链接或网络共享上的链接文件）。这些存储在带有 TargetMode=”External” 的关系部件中。OPC API 解析外部关系，但不验证外部目标的存在性或可访问性。
问：对于大型包，关系性能开销是否显著？
答：对于包含数千个部件的包，关系遍历开销可能很明显。推荐的优化方法是尽可能扁平化深层嵌套的关系链。此外，许多 OPC 实现会缓存解析后的关系 XML，因此在初始加载后重复查找的成本很低。
