8 个常见图片处理步骤，没有一个能同时在 JPEG 和 PNG 保住 XMP 元数据
起因是亚马逊 7 月 22 日给第三方卖家发的通知：商品图、A+ 内容和商品视频里，如果出现**完全由 AI 生成的写实人物**，上传前必须用支持 IPTC/XMP 的编辑器，把关键词 [contains-synthetic-performer](https://disclosetag.com/contains-synthetic-performer) 写进图片 XMP 的 `dc:subject` 字段。背后是纽约州 General Business Law 396-b （ 6 月 9 日生效），首次违规民事罚款 1000 刀，之后每次 5000 刀。
写这个标签本身不难，exiftool 一行就完事了。真正麻烦的是另一件事：**亚马逊是在你上传那一刻去读这个字段的**，所以中间任何一个环节把它吃掉，结果和你从来没打过标一模一样。而我能找到的所有说法——平台公告、咨询机构的合规指南——都停在同一句话上：「某些系统会在导出时移除嵌入的元数据」。**从来没有一份说过是哪些。**
那就自己测一遍。每一步都从一张全新的 1200×1200 图开始，先打上标签，过一个处理步骤，再读回两次：一次用自己的读取器，一次用 Pillow 独立的 XMP 解析器，两个读数不一致的行就作废重来（这次没出现不一致）。另有一行「原样复制」当对照组——它要是也报丢，说明测量方法本身有问题，其余所有行全部作废。
结果：**能脚本化测的 8 个处理步骤里，没有一个能在 JPEG 和 PNG 上同时保住标签。**其中 5 个两种格式都丢，3 个 JPEG 活下来、PNG 死了。
| 处理步骤 | JPEG | PNG |
| ---------------------- | ----- | ----- |
| 原样复制文件（对照组） | 保留 | 保留 |
| Pillow 重新保存 | 剥掉 | 剥掉 |
| Pillow 缩放后保存 | 剥掉 | 剥掉 |
| Pillow 降质压缩 | 剥掉 | 剥掉 |
| Pillow 保存时把 xmp= 传回去 | 保留 | 剥掉 |
| macOS sips 缩放 | 保留 | 剥掉 |
| macOS sips 转格式 | 保留 | 剥掉 |
| ffmpeg 重编码 | 剥掉 | 剥掉 |
| Squoosh （ mozJPEG / OxiPNG 默认档）| 剥掉 | 剥掉 |
三条我自己没想到的结论：
1. **只要重新保存一次就可能丢。**不用裁剪、不用调压缩、不用点导出对话框，单纯用 Pillow 打开再存一次，XMP 就没了。任何把图过一遍脚本的环节都值得怀疑。
2. **PNG 比 JPEG 脆。**所有在 JPEG 上活下来的步骤，换成 PNG 全军覆没。
3. **这是可以避免的，不是宿命。**同一个 Pillow ，保存时多传一个 `xmp=` 参数，JPEG 就保住了。工具丢元数据是因为没人要求它保留，不是因为做不到。
另外两个是手工测的往返路径，单独说，因为它们比脚本那几行更有意思：
**Canva 什么都没删。**导出的文件里 XMP 还在——只不过换成了 Canva 自己那一份，描述的是 Canva 的文档，原本躺在 `dc:subject` 里的东西不在里面了。如果你的检查逻辑只是粗略问一句「这文件有没有元数据」，它能干干净净地通过，而真正要读的那个东西已经没了。这也是为什么验标必须报三种状态而不是两种：标签在 / 有元数据但没有标签 / 什么都没有。中间那种才是坑。
**微信是这次最干净的一组对照**，因为同一个 App 、同一个动作，只差一个勾选框，结果完全相反：
- 手机发送时**勾上「原图」**：SHA-256 与原文件一致，仍是 2752×1536 ，标签完好。
- **不勾**（也就是默认）：图被缩到 2293×1280 、体积只剩原来的 41%，XMP 整块消失。
- 桌面版「文件传输助手」：界面上根本没有原图选项，但收到的文件逐字节一致。
微信本身没什么特殊。它转交文件时标签活着，它重新编码时标签就死了——和表里每一行落在同一条线上。所以判断任何一个环节，该问的不是「这是哪个 App 」，而是**它有没有重新编码这张图**。压缩、缩放、转格式、编辑器打开再保存，都是；复制、打包、以文件形式发送，都不是。
顺手把工具也做了：**[https://disclosetag.com/](https://disclosetag.com/) （中文版 [https://disclosetag.com/zh](https://disclosetag.com/zh)）**
- 拖进去先检测已有标签，只给缺的补，批量处理，出 ZIP 和一份逐文件的处理报告
- 读和写全在浏览器里跑，**文件不上传**，没有登录、没有付费墙、没有额度
- 图片写 XMP `dc:subject`；**视频那部分是实验性的**——亚马逊到现在也没公布视频该用哪个元数据字段，我写的是容器标签（ comment / description / keywords ），这个我不敢说它构成合规，页面上也是这么标的。
---
原文链接：[点击查看](https://www.v2ex.com/t/1230537)
写这个标签本身不难，exiftool 一行就完事了。真正麻烦的是另一件事：**亚马逊是在你上传那一刻去读这个字段的**，所以中间任何一个环节把它吃掉，结果和你从来没打过标一模一样。而我能找到的所有说法——平台公告、咨询机构的合规指南——都停在同一句话上：「某些系统会在导出时移除嵌入的元数据」。**从来没有一份说过是哪些。**
那就自己测一遍。每一步都从一张全新的 1200×1200 图开始，先打上标签，过一个处理步骤，再读回两次：一次用自己的读取器，一次用 Pillow 独立的 XMP 解析器，两个读数不一致的行就作废重来（这次没出现不一致）。另有一行「原样复制」当对照组——它要是也报丢，说明测量方法本身有问题，其余所有行全部作废。
结果：**能脚本化测的 8 个处理步骤里，没有一个能在 JPEG 和 PNG 上同时保住标签。**其中 5 个两种格式都丢，3 个 JPEG 活下来、PNG 死了。
| 处理步骤 | JPEG | PNG |
| ---------------------- | ----- | ----- |
| 原样复制文件（对照组） | 保留 | 保留 |
| Pillow 重新保存 | 剥掉 | 剥掉 |
| Pillow 缩放后保存 | 剥掉 | 剥掉 |
| Pillow 降质压缩 | 剥掉 | 剥掉 |
| Pillow 保存时把 xmp= 传回去 | 保留 | 剥掉 |
| macOS sips 缩放 | 保留 | 剥掉 |
| macOS sips 转格式 | 保留 | 剥掉 |
| ffmpeg 重编码 | 剥掉 | 剥掉 |
| Squoosh （ mozJPEG / OxiPNG 默认档）| 剥掉 | 剥掉 |
三条我自己没想到的结论：
1. **只要重新保存一次就可能丢。**不用裁剪、不用调压缩、不用点导出对话框，单纯用 Pillow 打开再存一次，XMP 就没了。任何把图过一遍脚本的环节都值得怀疑。
2. **PNG 比 JPEG 脆。**所有在 JPEG 上活下来的步骤，换成 PNG 全军覆没。
3. **这是可以避免的，不是宿命。**同一个 Pillow ，保存时多传一个 `xmp=` 参数，JPEG 就保住了。工具丢元数据是因为没人要求它保留，不是因为做不到。
另外两个是手工测的往返路径，单独说，因为它们比脚本那几行更有意思：
**Canva 什么都没删。**导出的文件里 XMP 还在——只不过换成了 Canva 自己那一份，描述的是 Canva 的文档，原本躺在 `dc:subject` 里的东西不在里面了。如果你的检查逻辑只是粗略问一句「这文件有没有元数据」，它能干干净净地通过，而真正要读的那个东西已经没了。这也是为什么验标必须报三种状态而不是两种：标签在 / 有元数据但没有标签 / 什么都没有。中间那种才是坑。
**微信是这次最干净的一组对照**，因为同一个 App 、同一个动作，只差一个勾选框，结果完全相反：
- 手机发送时**勾上「原图」**：SHA-256 与原文件一致，仍是 2752×1536 ，标签完好。
- **不勾**（也就是默认）：图被缩到 2293×1280 、体积只剩原来的 41%，XMP 整块消失。
- 桌面版「文件传输助手」：界面上根本没有原图选项，但收到的文件逐字节一致。
微信本身没什么特殊。它转交文件时标签活着，它重新编码时标签就死了——和表里每一行落在同一条线上。所以判断任何一个环节，该问的不是「这是哪个 App 」，而是**它有没有重新编码这张图**。压缩、缩放、转格式、编辑器打开再保存，都是；复制、打包、以文件形式发送，都不是。
顺手把工具也做了：**[https://disclosetag.com/](https://disclosetag.com/) （中文版 [https://disclosetag.com/zh](https://disclosetag.com/zh)）**
- 拖进去先检测已有标签，只给缺的补，批量处理，出 ZIP 和一份逐文件的处理报告
- 读和写全在浏览器里跑，**文件不上传**，没有登录、没有付费墙、没有额度
- 图片写 XMP `dc:subject`；**视频那部分是实验性的**——亚马逊到现在也没公布视频该用哪个元数据字段，我写的是容器标签（ comment / description / keywords ），这个我不敢说它构成合规，页面上也是这么标的。
---
原文链接：[点击查看](https://www.v2ex.com/t/1230537)
评论
暂无评论。