拒绝Word“所见非所得”：DocFence 深度审查隐藏的 XML 数据绑定

大家好，我是提米哥。今天我们来聊聊 Word 文档里一个很容易被忽视，但却可能带来大麻烦的隐藏机制。

你看到的 Word 文本，真的是它本来的样子吗？

在使用 Word 时，我们经常会用到“内容控件”（比如特定的文本框、下拉列表等）。这些控件看起来和普通文本没什么两样，但它们背后可能藏着一个 XML 映射（XML mapping）。

这是什么意思呢？简单来说，这个控件显示的文字，可能并不是它自己“写死”的，而是从文档底层隐藏的一个“数据仓库（自定义 XML 数据部分）”里自动抓取过来的。这就导致了一个问题：你肉眼看到的文字，和文档底层实际存储的数据，可能根本不是一回事。

在文档交接、合规审查或者模板生成的场景下，这种“所见非所得”的状态是一个非常危险的盲区。

DocFence：让隐藏状态“原形毕露”

为了解决这个问题，DocFence 0.6.0 应运而生。它不是用来帮你排版或渲染 Word 文档的，而是一个专门用来“查户口”的底层审查工具。

DocFence 能够深入文档底层，把那些隐藏的 XML 映射、存储 ID 以及关联的自定义 XML 数据部分全部盘点清楚，作为审查证据。最重要的是，它非常注重隐私和安全，绝对不会把具体的 XPath 表达式、XML 值、命名空间或部件名称等敏感信息输出到 JSON、Markdown 或 SARIF 报告中。

它能查出什么？（核心审查指标）

DocFence 不会去猜测 Word 会怎么渲染文档，它只做客观的静态盘点。它的公开审查报告只包含以下五个核心计数指标：

• 映射总数：文档中一共存在多少个 XML 数据映射。
• 带存储 ID 的映射：明确指定了数据来源仓库的映射数量。
• 不带存储 ID 的映射：没有指定仓库，Word 可能会自己去搜索的映射数量。
• 引用的自定义 XML 数据部分：文档中实际被关联到的隐藏数据仓库数量。
• 未匹配的存储 ID：控件绑定了某个数据仓库，但这个仓库在文档里根本找不到（这是一个非常明确的异常证据）。

如果发现有“未匹配的存储 ID”，DocFence 会直接将其标记为异常证据，而不是自己去瞎猜目标。对于没有存储 ID 的映射，它也会如实记录，但不会越俎代庖去猜测 Word 最终会选择哪个数据部分。

灵活的审查策略配置

在实际业务中，我们对文档的安全要求是不同的。DocFence 提供了非常灵活的策略配置。

场景一：绝对干净的交接
如果你要求交接的文档必须绝对干净，不允许包含任何隐藏的存储映射，可以开启以下策略：

rules:
  # 强制要求文档中不能包含任何数据绑定映射，确保文档绝对干净
  require_no_data_bindings: true

注：如果检测到映射，工具会抛出 DFP023 警告。

场景二：允许保留模板映射，但禁止篡改
如果你的文档是一个合法的模板，本身就需要保留这些映射，但你希望确保在流转过程中，这些底层绑定关系没有被偷偷修改，可以使用以下策略：

rules:
  # 允许存在数据绑定，但禁止对现有的绑定关系及底层数据进行任何修改
  no_data_binding_changes: true

注：如果底层的绑定关系或关联的 XML 数据发生了改变，工具会抛出 DFP024 警告。如果你还希望严格限制所有自定义 XML 的修改，可以同时加上 no_custom_xml_changes 规则。

严谨的发布与验证

作为一个安全审查工具，DocFence 自身的严谨性也做得很到位。它不仅兼容标准的和严格的 OOXML 格式，还经过了各种极端情况的测试（比如未限定范围的映射、多个控件映射到同一个部分、关系 ID 重新编号、格式错误的属性根等）。

此外，开发团队还使用独立的 OOXML 参考语料库进行了分析验证，确保工具在不重现文档内容的情况下，能精准报告控件和映射数量。安装包和源代码归档在相同的环境变量下进行了两次独立构建，结果字节完全一致。发布的资源包含了 wheel 包、源码包和 SHA-256 校验清单，确保你下载到的工具绝对安全、未被篡改。

总结

DocFence 是一个专注于“存储状态证据”的利器。它不是 Word 渲染器，也不是模板引擎，它只负责客观、安全地告诉你：这个 Word 文档底层到底绑定了什么。对于需要处理大量自动化文档、合规审查或模板开发的团队来说，这是一个不可多得的排雷工具。

直达网址：https://sybilgambleyyu.github.io/posts/docfence-060.html