💡 完整可运行示例可在 GitHub 上获取：
sanitize-office-document-pii-python

The Data Nobody Reviews Before Hitting Send

一份季度董事会报告会发送给外部审计员。正文毫无瑕疵；经过三轮审阅才确保如此。文件本身却是另一番景象。它的属性仍然记录着起草该报告的分析师、重新编辑的经理、拥有模板的公司子公司、截止日前一晚的 LastPrinted 时间戳，以及内部签署工作流中的 SharePoint 审批人 ID。这些信息并未出现在任何页面上，却随文件一起流转。

PII 删除是通过 .NET 为 Python 提供的 GroupDocs.Metadata 工作流，用于以编程方式剥离 Word、Excel 和 PowerPoint 文件中的这些身份属性。本文比较了 API 提供的三种方法：基于标签的身份字段删除、基于名称模式的属性族删除，以及一次性调用 sanitize() 清除所有内容。你还会看到大多数清理脚本会跳过的步骤——一次验证扫描，用以证明清理确实生效。

Why Metadata PII Deserves Its Own Pipeline

内容审阅工具检查人们阅读的内容，却不检查文件系统存储的内容，这一缺口正是合规事故的来源。GDPR 请求同样涵盖 Author 和 Manager 字段中的个人数据，就像文本中的数据一样。法律发现会读取修订计数器和编辑时间总计，以重建立场文件的协商时长。投标审阅者可以通过 SharePoint 工作流属性绘制你的组织结构，而新闻稿的评论字段则会保留审阅者姓名以及草稿阶段的备注。每一项都是潜在的泄露点，但它们都不出现在文档正文中。

Prerequisites

在开始之前，请确保你具备：

  • Python 3 与 pip
  • 通过 .NET 为 Python 提供的 GroupDocs.Metadata，示例仓库固定在 26.5 版本
  • 一个带有真实属性的 Office 文件，用于练习

Installation

pip install groupdocs-metadata-net==26.5

companion repository 中提供了示例 DOCX，并将下面的每段代码作为已断言的管道运行。

Method 1: Tag-Driven Identity Removal

最敏感的四个字段——Author、LastSavedBy、Manager 和 Company——在不同的 Office 格式中拥有不同的内部名称。标签系统解决了这个问题：不再按属性名称，而是按标记为“人”或“公司”的所有项进行匹配。

# Match identity properties by meaning, not by format-specific name
with Metadata("board-report.docx") as metadata:
    removed = metadata.remove_properties(lambda p:
        Tags.person.creator in list(p.tags)     # Author, LastSavedBy
        or Tags.person.editor in list(p.tags)
        or Tags.person.manager in list(p.tags)
        or Tags.corporate.company in list(p.tags))
    metadata.save("board-report-clean.docx")

print(f"{removed} identity properties removed")

关键要点：

  • 格式独立：相同的 lambda 可清理 DOCX、XLSX 和 PPTX，因为标签是按角色分类的。
  • 可计数的结果：remove_properties 返回匹配的属性数量，可写入审计日志。
  • 复制语义：保存到新路径可保留原始文件以备记录。

💡 提示：此过程会保留 Title、Subject 等描述性字段，使文件仍然友好于搜索和 DMS 索引。

Method 2: Name-Pattern Removal for Property Families

标签覆盖了已分类的概念。泄露字段的整族往往位于标签未覆盖的范围：评论属性、修订计数、SharePoint 工作流标记。对于这些，需要直接匹配属性名称本身。

# Comment fields often live in custom properties the tag system
# does not classify, so match them by name substring
with Metadata("board-report.docx") as metadata:
    removed = metadata.remove_properties(lambda p:
        p.name is not None and (
            "Comment" in p.name
            or "Reviewer" in p.name
            or "Reviewed" in p.name))
    metadata.save("board-report-no-comments.docx")

相同的结构可处理另外两族，只需更改子字符串列表：

家族 需要匹配的子字符串
修订轨迹 Revision, TrackedChange, LastPrinted, TotalEditingTime, EditTime
服务器 / 工作流 Server, Workflow, Approver, ContentType, Template

这是一种以覆盖面换取精确度的做法："Comment" 也会匹配 Comments 与 CommentCount，这正是大多数清理过程想要的。宽泛的子字符串可能会匹配到无害的模板字段，因此请将返回计数与预期进行比对。

💡 提示：当审计日志需要按类别计数时，可将每个家族单独运行；若不需要，可将所有子字符串合并到一个谓词中。

Method 3: The One-Call Full Sanitize

当文件离开组织且元数据层不应保留任何信息时，直接使用一次性调用即可。

# One call, every detected metadata package
with Metadata("board-report.docx") as metadata:
    removed = metadata.sanitize()
    metadata.save("board-report-final.docx")

print(f"sanitize() removed {removed} properties")

sanitize() 会清除库检测到的所有包：文档信息身份字段、评论、修订历史、已跟踪更改的作者以及自定义 OOXML 部分。其行为在 Clean metadata 页面有详细说明。它的优势也是它的代价——Title 和 Subject 会随 PII 一起消失，因此更适合作为导出关口的操作，而非协作工作流的中间步骤。

Do I need all four targeted passes?

不需要。每一次清理对应不同团队负责的风险。身份字段会让隐私官员不安，评论轨迹会让法务部门担忧，修订计数会让谈判者头疼，服务器字段会让安全团队警觉。只需运行与你的审阅者对应的那些步骤，顺序随意，因为每一步都会生成自己的输出副本。当没有任何字段需要保留时，直接使用 sanitize() 并进行验证即可。

Comparing the Three Approaches

方法 适用场景 关键优势 限制
基于标签的删除 工作副本、多格式管道 格式无关，保留描述性字段 仅覆盖标签已分类的概念
基于名称模式的删除 评论、修订、服务器字段 能触及标签未覆盖的自定义属性 子字符串需根据环境调优
完整 sanitize() 组织外部的最终导出 不会遗漏任何遗留属性 会清除无害字段

这三种方法可以自然组合：文档活跃期间使用有针对性的清理，导出时使用 sanitize()。

Verify Before You Trust It

仅凭删除调用返回的计数并不能证明文件已彻底清洁。仓库在每次运行结束后都会重新打开已清理的输出，并使用 find_properties 进行扫描，谓词结合了上述所有步骤的标签规则和名称规则。

def is_pii(p):
    if p.name is None:
        return False
    return (
        Tags.person.creator in list(p.tags)
        or Tags.person.editor in list(p.tags)
        or Tags.person.manager in list(p.tags)
        or Tags.corporate.company in list(p.tags)
        or any(n in p.name for n in (
            "Comment", "Reviewer", "Revision", "TrackedChange",
            "Classification", "Department", "Server", "Workflow")))

with Metadata("board-report-final.docx") as metadata:
    for p in metadata.find_properties(is_pii):
        value = (str(p.interpreted_value) if p.interpreted_value is not None
                 else (str(p.value) if p.value is not None else ""))
        if value and value not in ("0", "0.0"):
            print(f"LEAK {p.name}={value}")

仓库中的完整版本会将残留分为两类，这一点很重要。元数据泄露必须为零。内容层面的残余——如 Word 注释气泡和 word/document.xml 中的已跟踪更改——属于正文内容，元数据 API 无法触及；需要使用如 Aspose.Words 之类的内容编辑库来处理。诚实的报告会列出这两类，而不是在第一类清零后就宣称胜利。第一次在“干净”文件上运行此扫描时，我发现了一个部门字段，它是公司模板悄悄数月重新添加的。

Best Practices and Tips

  • 对副本进行清理，绝不直接修改原文件：本文所有代码片段均写入新路径，保留源文件以满足记录和保留策略。
  • 记录计数：remove_properties 与 sanitize() 的返回值即为审计轨迹。请按文件、按步骤存储。
  • 将验证集成到 CI 中：泄露检查导致构建失败，可在模板回归出现的当天捕获，而不是等到客户发现。
  • 注意元数据与内容的边界：当正文层面的注释仍在时，切勿报告文件已清洁；应将其作为单独的发现报告。
  • 授权：评估模式可以复现本文所有示例；生产环境请使用正式授权，以免评估标记出现在外发文件中。

Conclusion

三种方法，一条决策规则。概念已被标签分类且文件仍需可用时使用标签匹配；概念位于自定义属性时使用名称匹配；文件跨越信任边界时调用 sanitize()，并通过回读扫描进行验证，无论走哪条路，都要确保最终结果干净。

想进一步深入？以下是后续步骤：

Additional Resources

如有疑问或想分享实现方案，请前往 support forum 与我们交流。