ExifCleaner：一个用 Perl 写成的桌面隐私工具，靠 ExifTool 撑起批量清理
该项目围绕「Cross-platform desktop GUI app to clean image metadata. ExifCleaner Desktop app to clean metadata from images, videos, PDFs, and other files.」构建，适用于实际场景的开源实践，提供可复用的工具链与集成方式。
秒懂
- 它是什么？
- ExifCleaner 是一个跨平台桌面应用，用 ExifTool 的 stay-open 协议批量清除图片、视频和 PDF 的元数据。它拒绝代码签名，也拒绝遥测，代价是首次启动要手动放行。
- 适合谁用？
- ExifCleaner 适合需要批量清理元数据、且愿意接受手动放行未签名应用的隐私敏感用户，尤其是 macOS 和 Windows 上不想碰命令行的普通人。不适合需要处理 MKV、需要 PDF 元数据不可恢复擦除、或者要求企业级代码签名信任链的团队。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Perl（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是元数据擦除的最后一公里
照片、视频和 PDF 里藏着的位置信息、设备型号、编辑历史，不是删除文件就能带走的。命令行里 ExifTool 能做这件事，但大多数人不想记参数，也不想在终端里处理批量文件。ExifCleaner 把这一层封装成桌面 GUI：拖文件夹进去，点一下，完事。它面向的是记者、律师、摄影师这类需要发布文件前清理元数据的群体，也面向任何不想让照片暴露家庭地址的普通用户。项目用 Perl 写，界面层是 Electron，核心处理全靠 ExifTool，这个分工在 README 里写得很清楚。
stay-open 协议是批量速度的关键
ExifCleaner 没有自己实现元数据解析，它调用 ExifTool 作为子进程。批量处理的速度瓶颈通常在于反复启动外部程序的开销。README 明确提到它使用 ExifTool 的 stay-open 协议，也就是让 ExifTool 进程常驻，通过标准输入输出持续交换数据，避免每个文件都重新拉起一次进程。这个设计直接决定了它处理成百上千个文件时的体验。另一个细节是文件夹递归：拖入一个目录，它会遍历内部所有支持格式的文件。这两点合起来，让它的定位从单文件工具变成了批量流水线。
安装方式：下载、校验、然后绕过系统警告
官方发布渠道只有 GitHub releases，提供 macOS 的 dmg（区分 arm64 和 Intel）、Windows 的便携版 exe 和安装器、Linux 的 AppImage、deb、rpm。Arch 用户可以用 paru -S exifcleaner-bin。所有安装包都不带代码签名，所以第一次启动时 macOS 的 Gatekeeper 和 Windows 的 SmartScreen 都会拦一下。README 给出了具体步骤：macOS 14 及更早版本右键打开，macOS 15 需要去系统设置里点 Open Anyway；Windows 点 More info 再 Run anyway。校验和验证命令是 sha256sum -c SHASUMS256.txt 2>&1 | grep OK。不签名的原因是证书费用和匿名维护者身份的矛盾，这个取舍在隐私工具里不算罕见，但它把信任成本转嫁给了用户。
格式支持列表是承诺，也是边界
ExifCleaner 只接受 README 里列出的格式，图片有 jpg、png、heic、cr2、nef 等，媒体有 mp4、mov、avi，文档只有 pdf。这个列表是经过验证的 intake 合同，不是 ExifTool 的全部能力。但列表本身不保证清除效果。RAF 格式会被直接拒绝写入，因为项目无法保证安全清理后的文件可用。TIFF 的清除可能不完整，IFD0 里可能残留元数据，这是个未关闭的调查项。AVIF 也有一个用户报告的部分清除案例在查。这些限制不是 bug，而是 ExifTool 写入能力的结构性约束，ExifCleaner 选择在无法保证时拒绝操作，而不是假装成功。
PDF 和 MKV：两个最容易被误解的失败模式
PDF 是唯一被支持的文档格式，但 README 明确说 ExifTool 对 PDF 的更新是可逆的，原始元数据仍然可以恢复。这意味着 ExifCleaner 不能对 PDF 做出不可逆擦除的保证。对需要彻底清除 PDF 元数据的场景，这个工具是错的。MKV 则更直接：ExifTool 能读 Matroska 的元数据，但写不了标签，所以 ExifCleaner 在 intake 阶段就拒绝 MKV 文件，根本不会处理。这两个例子说明，一个工具的支持列表不等于它的能力上限，用户必须清楚自己要清理的格式是否属于可逆写入或只读类型。
隐私设计：零遥测和不自动更新是卖点，也是维护策略
ExifCleaner 宣称没有自动更新，没有网络流量，没有遥测。这对隐私工具来说是合理底线，但也意味着安全修复只能靠用户手动下载新版本。v4.0 引入了 CSP、Electron Fuses、IPC 验证、导航加固和权限门控，这些是针对 Electron 应用常见攻击面的硬化措施。CI 会在每次发布时安装并运行真实的 dmg、exe 和 AppImage，从测试图片里剥离元数据，确认产物可用才放行。这套流程弥补了不签名的部分信任缺口，但它不能替代签名，因为签名解决的是分发过程中的篡改问题，而 CI 只能保证构建产物本身没问题。
维护成本与许可证：MIT 下的匿名维护
项目以 MIT 许可证发布，可以自由使用和修改。但维护者保持匿名，这直接影响升级路径。v4.0 是 2021 年 v3.6.0 之后的首个版本，中间隔了五年，说明维护节奏不稳定。每次大版本更新都依赖 ExifTool 的能力变化，比如新增格式支持或写入改进，这些都要跟着上游走。对于企业用户，匿名维护和未签名构建可能构成供应链风险，因为无法验证维护者的身份，也无法建立长期支持合同。个人用户则要习惯手动检查 release 页面，因为没有自动更新提醒。
替代方案的差异在于抽象层次
最直接的替代是直接用 ExifTool 命令行，比如 exiftool -all= file.jpg。区别在于 ExifCleaner 提供了图形界面、批量拖拽、前后差异查看和语言切换，而 ExifTool 需要自己写脚本处理递归和错误处理。另一个方向是 exiftool 的 GUI 前端，比如 ExifToolGUI，但那是 Windows 专属，且界面老旧。ExifCleaner 的差异化在于跨平台一致性和隐私承诺，它把 ExifTool 的能力封装成现代桌面应用，同时明确暴露格式限制。如果你已经熟悉命令行，ExifCleaner 的便利性会被脚本的灵活性抵消；如果你要处理的是团队共享的批量流程，脚本更容易集成到 CI 里。
编辑结论
ExifCleaner 适合需要批量清理元数据、且愿意接受手动放行未签名应用的隐私敏感用户，尤其是 macOS 和 Windows 上不想碰命令行的普通人。不适合需要处理 MKV、需要 PDF 元数据不可恢复擦除、或者要求企业级代码签名信任链的团队。采用前先验证两件事：一是下载后核对 SHA-256 校验和，二是检查你要处理的格式是否在支持列表里，特别是 TIFF 和 AVIF 的已知部分清除问题是否影响你的文件。它的核心价值在于把 ExifTool 的强大封装成了拖拽即用的界面，但这份便利建立在 ExifTool 的写入能力边界之上，PDF 的可逆更新和 MKV 的拒收就是这条边界的具体表现。
社区笔记