Word 的作者和修订属性，导出前要不要保留

本文使用合成样本演示处理方法。代码已通过隔离环境中的示例检查；这不代表对所有真实文件或产品效果的保证。处理重要文件前，请保留原件，并按文中的边界与验收项复核。 这篇先解决哪一个问题 字符串核心属性可以清空，但日期属性不能赋 None。下面保留日期，只演示字符串字段清理和序列化回读；这不是完整脱敏器，批注、修订、正文和自定义属性需另查。 自包含的合成示例 依赖见导入列表。代码在内存中构造输入；运行记录单独提供，不代表对所有真实文件的保证。 from docx import Document from io import BytesIO from datetime import datetime doc = Document() doc.core_properties.author = "Synthetic Author" doc.core_properties.title = "Synthetic Draft" doc.core_properties.created = datetime(2024, 6, 1) original_date = doc.core_properties.created for field in ("author", "title", "subject", "keywords", "comments", "last_modified_by"): setattr(doc.core_properties, field, "") stream = BytesIO() doc.save(stream) stream.seek(0) result = Document(stream) assert result.core_properties.author == "" assert result.core_properties.title == "" assert result.core_properties.created == original_date try: doc.core_properties.created = None except ValueError: pass else: raise AssertionError("date setter must not silently accept None") 导出Word前的元数据陷阱：为什么清空author还不够 当你用脚本批量生成或转换Word文档时，最尴尬的瞬间往往不是格式错乱，而是交付给客户后，对方在文件属性里看到了你的本地用户名、测试时的草稿备注，甚至是上一份无关文档的标题。 python-docx 提供了 core_properties 接口来读写这些 Dublin Core 标准属性，但它不会自动替你做任何“安全清洗”。更关键的是， core_properties 只是文档元数据的一小部分，它不包含批注作者、修订记录、自定义XML字段或嵌入对象的元信息。把清理 core_properties 等同于完整的隐私扫描，是工程上最常见的误判。 本文聚焦于如何正确、可验证地处理 core_properties ，并明确它的边界。我们不提供一键脱敏工具，而是给出一套可复现的校验逻辑和验收标准，帮助你在自动化流程中建立可靠的检查点。 合成示例：正确清理与典型错误输入 以下是一个完全自包含的合成示例，用于演示 core_properties 的清理逻辑。 注意：此代码不读取真实文件，所有数据均在内存中构造，仅用于说明API行为和边界处理。若需处理真实文档，请自行准备 .docx 文件路径或字节流对象作为 Document() 的参数。 验收清单：代码能做什么，不能做什么 检查项 代码可处理 需人工/其他工具 处理决定 core_properties.author/title/comments等14项 ✅ ❌ 按类型规则清空或重写 批注中的author/initials ❌ ✅ 遍历doc.comments单独处理 修订记录中的作者信息 ❌ ✅ 需解析w:ins/w:del XML节点 自定义文档属性（custom properties） ❌ ✅ 需通过底层XML或专用库访问 嵌入OLE对象/图片的EXIF/元数据 ❌ ✅ 需专用媒体处理库 文档模板路径或宏代码 ❌ ✅ 检查settings及vbaProject last_printed等非敏感但冗余字段 ✅ ⚠️ 按合规要求决定是否保留 此表明确区分了 core_properties 的作用域。例如，即使你将 core_properties.author 清空，文档中每条评论仍可能携带原始作者名；修订历史也可能完整保留编辑者身份。这些都不在 CoreProperties 类的管辖范围内。因此，任何声称“已清理文档元数据”的自动化脚本，若只操作了 core_properties ，其结论都是不完整的。验收时必须逐项核对上表，对“需人工/其他工具”列标记为✅的项目安排额外处理或审查。 参考与下一步 python-docx Document API 下一步行动：在你的CI/CD或文档发布流水线中加入 core_properties 校验步骤，使用本文提供的断言逻辑作为基础模板。同时，梳理你的文档类型，为上表中“需人工/其他工具”的项目制定专项处理SOP。不要假设清理了 author 就等于完成了隐私保护——真正的安全来自对边界的清醒认知。 将这份检查清单用于文档翻译 Word 翻译容易把内容问题与格式问题混在一起。把样式、页眉和表格等检查项留到交付清单里，让审校知道该在哪里检查。 OmniDoc（产品入口） 提供多格式文档翻译入口，官网介绍了 OCR、术语表与双语对照功能。对希望直接从文件开始处理的团队，这是一条值得用实际样本评估的路径。请使用有权上传的脱敏文件，并用本篇的检查项复核结果；这里不声称 OmniDoc 使用了本文的开源库或内部算法，也不以示例代替产品性能测试。 - 1 -