清除 JPEG 照片中的 EXIF 数据
01 为什么大多数"清除 EXIF"工具都是围绕 JPEG 打造的
JPEG 历史悠久（诞生于 1992 年），至今仍是大多数老式相机和手机的默认输出格式。它的元数据存放在文件内部编号的 "APP"标记段中——APP1 通常携带 EXIF（相机型号、GPS、时间戳），有时也携带 XMP；APP2 通常携带内嵌的 ICC 色彩配置文 件；一个简单的 COM 段则可以包含任意的自由文本注释。这些内容全部位于真正的图像数据之前，只要用对工具就能轻松读取 ——这正是为什么清除 JPEG 元数据是这整个领域中最成熟、竞争最激烈的一块。
深入了解：量化表、缩略图，以及"质量"选项究竟改变了什么
JPEG 的 DQT（量化表）标记控制着图像每个 8x8 像素块被压缩的激进程度——本工具会直接读取真实的表数值并展示，而 不是像某些取证工具那样去猜测一个"质量分数"。EXIF 中通常还携带第二张更小的内嵌缩略图，只生成一次，且在之后的 编辑中常常没有同步更新——如果这张缩略图显示了主图像中没有的内容，那就是一个真实、可核实的迹象，说明照片之后 被编辑过，元数据页面对此有更详细的说明。
还有一个真实且独立的风险值得了解：JPEG 的图像结束标记（0xFFD9）定义得很明确，但许多损坏或被刻意构造的文件会 在其后附加额外数据——这是一种经典的"多格式混合"手法，第二个文件（脚本、压缩包）会隐藏在看起来只是一张普通照 片的内容中随之传播。无论选择哪种预设，这里实际发生的完整像素重建都会作为一项结构性保证，拒绝一切位于该标记之 后的内容，而不是当作特殊检查项来处理。
一段值得了解的真实历史
图像解码库有据可查地存在过严重的安全漏洞——这不是假设性的风险。"ImageTragick"（CVE-2016-3714）是 2016 年一个被 广泛使用的图像库中的漏洞，攻击者可以通过一个精心构造的图像文件，在处理该文件的服务器上执行命令，而且这一漏洞被发 现曾在实际环境中被利用过。完整的像素重建正是为了防范这类事情而设计的：无论其他地方的解码器 bug 原本会放过什么， 原始文件中的任何一个字节都不会到达能够执行它的地方。
专门针对 JPEG 选择压缩预设
与 PNG 或 GIF 不同，JPEG 的质量是一项真实且有意义的取舍——这里的"无损"模式追求极高质量（由于优先考虑保真度而非 体积，有时甚至可能比压缩很狠的原图更大），"均衡"模式追求合理的折中，而"超级压缩"则在文件大小比完美像素 质量更重要时切实减小体积。三者同样都会去除每一个字节的元数据——预设只改变像素压缩方式，绝不会改变被去除的内容。