如何检查DWG图纸文件是否被他人修改过

DWG图纸在工程协作中经常被多人反复编辑，一旦出现尺寸偏差、标注错误或交付纠纷，第一件事就是判断文件是否被别人修改过。很多人第一反应是打开AutoCAD看“最后保存时间”，但这个时间很容易被系统时间或重新保存操作影响，单独依赖它并不能证明内容是否被改动。真正可靠的做法是把技术证据分两层看：一层是图纸内部的元数据，另一层是文件的整体哈希指纹，两者配合才能形成完整的变更记录。

元数据只能告诉你“谁在什么环境下保存过”，不能单独证明内容一致性。DWG内部会记录 AutoCAD 版本、创建者和最后保存者、保存时间、编辑时间、文件大小、单位、图层信息等字段，这些信息在反复转存、另存为不同版本时会被更新。读取这些信息可以帮助还原编辑链，但它们本身是可以被修改的，因此要把它当作线索而不是结论。与元数据不同，SHA-256、MD5、CRC32 这类哈希值是基于文件全部字节计算的指纹，哪怕改动一个空格，哈希都会完全改变。用哈希做对比，才能在技术层面回答“这个文件和上一个版本是不是同一个文件”。

DWG 的元数据结构比较特殊，它既有 AutoCAD 自身的私有信息块，也会携带操作系统的文件系统时间。实际工作中常见的判断点包括 Last Saved By、Last Saved Time、Application Version、Drawing Units、Thumbnail 是否变化等。如果图纸是从外部接收的，保留原始文件的哈希基准非常重要。拿到图纸后第一时间计算哈希并做好记录，后续每次接收新版本都重新计算并比对，变化就一目了然。这种方法同样适用于图纸包里的配套文件，比如 PDF 输出、STL 或 STEP 模型，对比逻辑是一致的。

一个典型的落地场景是，甲方在项目里程碑时要求乙方提交最终版机电图。乙方提交文件后，甲方立刻对文件做哈希采集并存档，同时导出元数据快照。一个月后发现现场施工与图纸不符，甲方拿出新收到的“修订版”图纸，与存档的哈希值对比，发现 SHA-256 完全不同，进一步比对元数据发现 Last Saved By 变成了另一个账号，Last Saved Time 也在交付之后。这种技术记录本身不判定责任归属，但为后续沟通、审计或协商提供了可验证的客观依据。

在实际操作中，手动计算哈希和读取元数据既费时也容易出错，特别是批量图纸。此时可以使用专业的在线取证工具来完成采集和报告。FilesAudit 这类平台支持上传 DWG 文件后自动提取 AutoCAD 元数据、文件系统时间、以及计算 SHA-256、MD5、CRC32 指纹，并生成带时间戳的 PDF 报告，报告内容可直接用于存档和内部审计。你可以在 文件元数据指南 中了解不同格式的典型字段差异，也能查看 支持的格式列表 确认 DWG、PDF、ZIP 等工程常用格式是否在范围内。

很多团队会把哈希存证和时间证明结合起来使用。如果需要证明“文件在某个时间点就已经存在且未被篡改”，仅靠本地记录说服力有限，结合哈希时间戳存证方法可以把指纹上链或写入可信时间戳服务，形成更强的技术证据链。FilesAudit 的桌面版也支持本地批量处理，适合对图纸包做离线、无网络的统一采集，避免上传敏感设计文件到公网的顾虑。

需要明确的是，元数据分析和哈希比对属于技术验证手段，不能等同于法律上的所有权或真实性认定。它能证明“两个文件是否相同”以及“文件是否被修改过”，但不能证明谁有合法修改权、修改是否授权。最终的法律判断仍需结合合同、邮件、版本管理记录和授权流程。技术证据的价值在于它客观、可重复、可审计，能把主观争议转化为可核查的数据。

因此，日常的最佳实践是：收到重要 DWG 后立刻固定哈希，保存一份只读备份，并定期导出元数据快照。每次变更都重新采集并与基准对比，重要节点生成带时间戳的 PDF 报告归档。遇到纠纷时，先用哈希确认文件是否被改动，再用元数据还原编辑路径，最后配合项目管理记录形成完整说明。这样既能快速发现异常，也能避免因时间戳误读而产生不必要的误会。