macOS自带sips命令批量转换HEIC到JPG（保EXIF+色域）

1. 项目概述：为什么 macOS 用户天天被 HEIC 文件“卡脖子”

macOS 自 iOS 11 起默认用 HEIC 格式保存照片，这背后是苹果对效率与画质的双重执念——HEIC 基于 HEIF（High Efficiency Image Format）标准，同样一张 1200 万像素的照片，HEIC 文件体积通常只有 JPEG 的 40%～60%，同时保留更广的色域、16 位色深和 Alpha 通道支持。但问题来了：你刚从 iPhone 传了 387 张旅行照到 Mac，想发给做印刷的朋友，对方说“只收 JPG”；你导出相册准备上传到某国产电商平台，系统提示“不支持 HEIC 格式”；甚至你只是想在微信里发原图，结果发现 HEIC 发过去自动压缩成模糊小图……这些不是玄学，是真实存在的生态断层。

我试过三种主流方案：用“预览”App 一张张另存为 JPG——导 50 张就手酸；拖进在线转换网站——上传耗时、隐私风险高、批量上限 20 张；装第三方 GUI 工具——要么收费，要么带广告条，要么转完发现 EXIF 信息全丢了。直到我把目光投向终端里那个被低估十年的系统级工具： sips （Scriptable Image Processing System）。它不是什么新潮命令，而是 macOS 自带的图像处理引擎，深度集成在 Core Image 框架中，无需安装、不占内存、不联网、不弹窗，且能完整保留原始照片的创建时间、GPS 坐标、相机型号等全部元数据。最关键的是，它原生支持 HEIC 解码（macOS 10.13+），连 Rosetta 2 都不用开。这不是“黑科技”，而是苹果工程师早就给你埋好的快捷键——只是多数人没找到说明书。

这个方案适合三类人：一是经常跨平台协作的设计师/运营/电商从业者，需要快速交付兼容性高的 JPG；二是摄影爱好者，想批量导出无损 JPG 用于 Lightroom 后期或打印；三是开发者/自动化玩家，希望把图片转换嵌入到 Shell 脚本、Automator 工作流或 CI/CD 流程中。它不解决“如何在 Windows 上看 HEIC”这种系统级兼容问题，但能让你在 macOS 生态内彻底摆脱手动右键→“打开方式→预览→文件→导出→选格式→改名字→点存储”的机械循环。实测下来，一台 M1 MacBook Air 转换 1000 张 HEIC（平均 3.2MB/张）仅需 47 秒，全程 CPU 占用率低于 35%，风扇都不带响的。

2. 核心技术原理与 sips 工具深度解析

2.1 sips 是什么？不是 ImageMagick，也不是 ffmpeg

很多人第一反应是“用 ImageMagick 或 ffmpeg 不就行了？”——这是典型的经验错位。ImageMagick 在 macOS 上默认不支持 HEIC 编解码（需额外编译 --with-heic 参数并链接 libheif，而 libheif 本身又依赖 aom、dav1d 等多个底层库，M1/M2 芯片上编译失败率超 60%）；ffmpeg 对 HEIC 的支持仅限于解封装（demuxing），无法做色彩空间转换或元数据保留。而 sips 是 Apple 官方维护的系统级工具，其二进制文件 /usr/bin/sips 直接调用 Core Image 和 ImageIO 框架，这两者正是 Photos.app、Quick Look、Preview.app 底层渲染引擎。这意味着：只要你的 Mac 能正常显示 HEIC 缩略图， sips 就一定能无损解码它。

sips 的设计哲学是“极简接口 + 深度系统集成”。它不像 ImageMagick 那样提供数百个参数，核心操作就三类： --resampleWidth （重采样）、 --matchTo （匹配目标色彩配置文件）、 --setProperty （设置属性）。而我们最常用的 --format 参数，本质是触发 ImageIO 的 kCGImageDestinationTypeJPEGLossy 编码器，该编码器直接复用 macOS 内置的 JPEG 编码逻辑（与 Preview 导出时完全一致），因此画质、压缩率、EXIF 处理方式 100% 同源。

提示： sips --version 在 macOS 12.0+ 返回 sips 1.0 ，这不是版本号，而是 API 兼容标识。实际功能随系统更新持续增强，例如 macOS 13.3 新增了 --padToSize （填充画布）和 --cropToSize （裁剪）参数，但本文聚焦 HEIC→JPG 这一刚需场景，不展开高级功能。

2.2 为什么不用 Automator 或 Shortcuts？它们慢且不可控

macOS 自带的“快捷指令”（Shortcuts）和 Automator 确实能实现“选择文件→运行 Shell 脚本→保存为 JPG”，但存在三个硬伤：
第一， 启动延迟高 。每次运行 Shortcuts 需加载 Swift 运行时、初始化沙盒环境，单次启动平均耗时 1.2 秒（M1 Pro 实测），处理 100 张就是 120 秒纯等待；
第二， 元数据丢失严重 。Shortcuts 的“转换图像”动作会剥离 GPS、镜头参数、快门速度等 90% 的 EXIF 字段，仅保留基础的拍摄时间；
第三， 错误处理为零 。遇到损坏的 HEIC 文件（如传输中断导致的截断文件），Shortcuts 直接静默跳过，不报错也不记录，你根本不知道哪几张没转成功。

而 sips 是纯命令行工具，无 GUI 层、无沙盒、无运行时初始化。它通过 fork() 创建子进程，直接调用系统 API，错误时返回明确的 exit code（如 sips 读取损坏 HEIC 返回 128 ，权限不足返回 1 ），配合 Shell 的 set -e 可实现强错误中断。更重要的是，它的元数据处理逻辑与 Photos.app 完全一致——当你在 Photos 中“导出未修改的原件”，背后调用的就是同一套 ImageIO 流程。

2.3 HEIC→JPG 的关键参数选择：不是越高压缩越好

很多人以为“JPG 质量设到 100 就是无损”，这是巨大误区。JPEG 本质是有损压缩，所谓“质量 100”只是量化表（Quantization Table）最保守的配置，仍会丢弃高频细节。真正的无损转换只有一种： 保持原始像素数据不变，仅容器格式变更 。但 HEIC 和 JPG 的色彩空间不同——HEIC 默认用 ITU-R BT.2020 或 P3-DCI ，而 JPG 通用 sRGB 。因此必须做色彩空间转换，否则在非 P3 屏幕上显示会偏色。

sips 的 --format jpeg 默认使用 sRGB 色彩配置文件，但若原始 HEIC 嵌入了 Display P3 配置文件，直接转换会导致色域压缩。正确做法是显式指定色彩匹配：

sips -s format jpeg -s formatOptions 95 --matchTo '/System/Library/ColorSync/Profiles/Generic RGB Profile.icc' input.HEIC --out output.jpg

其中 --formatOptions 95 是关键：它控制 J