Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 26300-2 — 办公应用开放文档格式 v1.3 第2部分
可复用的OpenDocument格式（ODF）包与包级元数据规范
ISO/IEC 26300-2是办公应用开放文档格式（ODF）v1.3标准的第2部分，规定了将ODF内容、元数据和相关资源封装到单个文件中的包格式。第1部分定义了XML内容模式（包内以XML文件形式表示的实际文档结构），第2部分则定义了这些XML文件如何组装到基于ZIP的容器中，并附带清单条目、元数据流和数字签名支持。理解包层面对于从事文档处理、归档或互操作性工作的任何工程师来说都是必不可少的。
ODF包是有效的ZIP文件，但并非所有ZIP文件都是有效的ODF包。包格式要求特定文件（META-INF/manifest.xml、mimetype）、特定条目顺序（mimetype必须是第一个条目，且不压缩存储）和特定目录结构。使用修改ODF文件的通用ZIP工具可能会生成违反这些约束的包。
包结构与要求
ODF包格式建立在ZIP存档规范之上，并增加了确保跨实现可预测处理的额外约束：
| 包元素 | 必需 | 位置 | 用途 |
|---|---|---|---|
| mimetype条目 | 是 | ZIP中第一个条目，不压缩 | 媒体类型标识（例如 application/vnd.oasis.opendocument.text） |
| META-INF/manifest.xml | 是 | META-INF目录中的标准XML文件 | 文件列表、媒体类型、加密信息和版本元数据 |
| META-INF/signatures.xml | 否 | META-INF目录中的可选文件 | 用于文档完整性和身份验证的XML数字签名 |
| 内容文件 | 是 | 根目录或子目录 | content.xml、styles.xml、meta.xml、settings.xml和嵌入资源 |
| META-INF/manifest.key | 否 | META-INF目录中的可选文件 | 密码保护文档的加密密钥派生数据 |
mimetype条目是包中约束最严格的元素。它必须是ZIP存档中的第一个条目，不压缩存储，且恰好包含媒体类型字符串后跟一个换行符（0x0A）。这种设计允许文件类型检测工具（如Unix的file命令）通过读取文件的前50-80字节来识别ODF文档，而无需解析完整的ZIP结构——显著提高了大型文档存档上的检测性能。
manifest.xml文件作为包的目录。包中的每个文件（除了mimetype条目本身）都必须在清单中列出，附带其媒体类型，以及可选的加密信息。清单还存储ODF版本和处理包内容所需的任何命名空间声明。
ODF v1.3中的manifest.xml得到了显著增强，支持更丰富的元数据，包括文件之间的关系类型、嵌入媒体的更好MIME类型描述，以及对可访问性元数据的改进支持。这些增强使ODF v1.3包比以前的版本更具自描述性。
数字签名与文档完整性
ISO/IEC 26300-2规定了基于信封和基于清单的数字签名机制。信封签名将整个包作为二进制大对象进行签名，而清单签名对包内的各个文件进行签名，通过其清单条目路径进行标识。
信封签名更简单但灵活性较差：签名检测包中任何文件的任何修改。这适用于文档完整性至关重要的归档用例。然而，当应用程序需要向包添加元数据（如打印时间戳）而不使原始签名无效时，信封签名就会失效。
基于清单的签名通过独立签名各个文件解决了这一灵活性问题。应用程序可以向包添加新文件（例如扩展元数据流），并仅对该新文件进行签名，而不影响现有内容文件的签名。清单跟踪哪些文件已签名以及每个文件由哪个签名覆盖。
数字签名格式使用XML签名语法和处理规范（XML-DSig，W3C推荐标准），支持X.509证书、基于HMAC的密钥和引用签名格式。ODF v1.3增加了对长期验证（LTV）配置的支持，使签名在签名证书过期数十年后仍可验证——这是电子记录管理的关键要求。
在实现ODF数字签名验证时，始终验证manifest.xml文件本身。攻击者可以通过修改清单以移除签名条目同时保留signatures.xml文件完整，从而从ODF包中剥离签名。在任何签名验证开始之前，必须对清单进行身份验证。
ODF包处理的工程见解
构建稳健的ODF处理工具需要仔细关注包层面的细节，而这些细节经常被专注于XML内容的开发者忽视：
流式处理与随机访问处理：对于大型ODF包（例如嵌入视频的演示文稿，或包含数千张图像的电子表格），随机访问ZIP读取至关重要。清单提供了每个条目的字节偏移量，使阅读器可以直接定位到特定文件，而无需解压缩整个包。当性能至关重要时，请使用支持条目级随机访问的ZIP实现，而不是顺序解压缩。
加密处理：ODF v1.3支持包级加密（整个内容被加密）和文件级加密（包内的单个文件被加密）。文件级加密更加灵活，但需要仔细的密钥管理。manifest.xml存储每个加密文件的加密算法、密钥派生方法（具有可配置迭代次数的PBKDF2）和初始化向量。实现必须至少支持CBC模式下的AES-128，使用SHA-256作为密钥派生的哈希算法。
向后兼容性：ODF v1.3包设计为可由ODF v1.2实现读取，前提是v1.2实现忽略了清单和内容文件中的未知元素。然而，v1.3特定功能（新的元数据元素、增强的数字签名、额外的媒体类型）会被v1.2处理器静默忽略。应用程序应始终在清单中声明覆盖其使用功能的最小ODF版本。
切勿通过手动连接ZIP条目来构造ODF包。始终使用遵循ODF特定约束的合规ZIP库：mimetype条目必须存储（非压缩），必须是第一个条目，且必须包含完全正确的媒体类型字符串。与规范的一个字节偏差都可能导致文档处理器（LibreOffice、带ODF插件的Microsoft Word、在线查看器）拒绝该文档。
常见问题解答 (FAQ)
问1：ODF v1.3第1部分和第2部分有什么区别？
第1部分（ISO/IEC 26300-1）定义了文档内容的XML模式——文本文档、电子表格、演示文稿、绘图、图表和公式的结构。第2部分（ISO/IEC 26300-2）定义了包格式——这些XML文件如何在ZIP容器中组织，以及清单、加密和数字签名处理。
第1部分（ISO/IEC 26300-1）定义了文档内容的XML模式——文本文档、电子表格、演示文稿、绘图、图表和公式的结构。第2部分（ISO/IEC 26300-2）定义了包格式——这些XML文件如何在ZIP容器中组织，以及清单、加密和数字签名处理。
问2：能否使用标准ZIP工具提取ODF内容？
可以，因为ODF包是有效的ZIP文件。您可以使用任何ZIP工具提取内容XML文件。然而，使用标准ZIP工具修改ODF包可能会破坏ODF特定约束（mimetype顺序、压缩设置）。为安全修改，请使用专门为ODF处理设计的库。
可以，因为ODF包是有效的ZIP文件。您可以使用任何ZIP工具提取内容XML文件。然而，使用标准ZIP工具修改ODF包可能会破坏ODF特定约束（mimetype顺序、压缩设置）。为安全修改，请使用专门为ODF处理设计的库。
问3：ODF包加密与加密ZIP相比如何？
ODF在包内使用文件级XML加密，而加密ZIP（AES-2方案）在ZIP条目级加密。ODF的方法允许选择性加密包内的单个文件——例如，仅加密content.xml而保持元数据文件不加密以便于索引。
ODF在包内使用文件级XML加密，而加密ZIP（AES-2方案）在ZIP条目级加密。ODF的方法允许选择性加密包内的单个文件——例如，仅加密content.xml而保持元数据文件不加密以便于索引。
问4：哪些工具支持ODF v1.3数字签名？
LibreOffice 7.3+支持ODF v1.3数字签名。多个商业文档管理系统和电子签名平台也支持该格式。参考实现可通过ODF Toolkit项目获得，该项目提供了用于创建和验证ODF包签名的Java库。
LibreOffice 7.3+支持ODF v1.3数字签名。多个商业文档管理系统和电子签名平台也支持该格式。参考实现可通过ODF Toolkit项目获得，该项目提供了用于创建和验证ODF包签名的Java库。
