用 EXIF 拍摄时间批量重命名照片——从 IMG_xxxx 到 2024-03-15_142307 的实战流程

Q: {exif-date} 和 {mtime} 看着都是日期，到底差在哪？该用哪个？

两者根本不同。(1) {exif-date} 读的是图片文件内部 EXIF 的 DateTimeOriginal 字段——相机/手机在按下快门那一刻写进去的，反映真实拍摄时间。(2) {mtime} 读的是文件系统的最后修改时间——经过任何拷贝、剪辑、转码、AirDrop、QQ/微信传输都可能被更新成"今天"。90% 场景应该用 {exif-date}：原图（包括 RAW、HEIC、JPG）从相机/手机直接导出、没经过编辑——拍摄时间稳定可靠。{mtime} 兜底：视频文件（EXIF 不支持视频）、被压缩处理过的图片、截图——视频建议用 {mtime}，但要确认中间没经过微信/QQ 二次转发（那会改 mtime）。实战推荐：模板填 {exif-date}_{exif-time}{ext}，没 EXIF 的图自动留空——再用兜底模板 {exif-date}{name}{ext} 保证至少不丢原名。

Q: 为什么导出的照片时间和我拍照时差几小时？

多半是时区问题。EXIF 的 DateTimeOriginal 本身不带时区，只是个本地时间字符串"2024:03:15 14:23:07"。常见错位场景：(1) 相机没设时区——出国旅行用的胶片相机/单反，设的还是国内时间，但你想要拍摄当地的时间；(2) 手机自动同步出错——iPhone/Android 偶尔会因 GPS 时区识别错误把照片打上"上午 2 点"的标；(3) 跨时区导入后又换电脑——同一张图在不同电脑读到的 mtime 不同，EXIF 反而稳定。处理思路：(1) 拖入工具前先用 [[photo-info]] 看一张样本图的 EXIF，确认时间和你预期是否吻合；(2) 偏差固定（如全集差 12 小时）——这工具不支持批量加减时间，可以先用 [[exif-clean]] 或 ExifTool 命令行修正再回来重命名；(3) 偏差是个别图——重命名后手动改文件名解决。关键认知：EXIF 时间是相机记的"本地时间"，不是 UTC——出国旅行前先把相机时间调成目的地时区。

Q: iPhone HEIC、Android JPG、单反 RAW、无人机 DNG 都能读 EXIF 吗？

主流格式全支持，靠 exifr 库覆盖。(1) JPG / JPEG —— 通用 EXIF，所有相机/手机/导出工具都写。(2) HEIC / HEIF —— iPhone 默认格式（iOS 11+），EXIF 完整。(3) TIFF —— EXIF 原生，扫描件 / 部分相机直出。(4) RAW 家族：Nikon NEF、Canon CR2/CR3、Sony ARW、Fuji RAF、Panasonic RW2、Pentax PEF、Olympus ORF、DJI DNG、Adobe DNG——全部能读 DateTimeOriginal。(5) WebP —— 部分写 EXIF 部分不写（Google Photos 导出的通常有，浏览器另存的没有）。不支持的：(1) PNG —— PNG 标准不含 EXIF，但 macOS / iPhone 导出的 PNG 里有时藏在私有 chunk，exifr 读不到，当无 EXIF 处理；(2) 截图 —— 几乎都没 EXIF（系统截图工具不写）；(3) 网络下载图 —— 多数 CDN 处理后 EXIF 被剥光保护用户隐私。无 EXIF 时 {exif-date} 输出空字符串，记得加 {name} 兜底避免空文件名冲突。

Q: "原地改名"和"ZIP 下载"该选哪个？原地改名是什么原理？

原地改名直接改原文件，没副本——浏览器调用 File System Access API 请求该目录的写权限，然后逐个 move() 重命名，不需要把文件读进内存。优点：(1) 万级文件也不卡——文件不全量加载；(2) 不占下载带宽，不产生临时 ZIP 占硬盘；(3) 修改时间通常保留（rename 不动 mtime）。前提：Chrome / Edge / Opera 等 Chromium 系列 + 新版 Safari 支持；Firefox 不支持。必须用左下"选择文件夹（原地改名）"按钮加载，不能拖入文件——拖入的是 File 对象，没目录句柄写不回原位。ZIP 下载兜底：(1) Firefox / 旧浏览器；(2) 想保留原文件做对照；(3) 跨设备整理（在 PC 上准备，把 ZIP 拷到 NAS）。ZIP 模式会把所有文件读进内存再打包，建议总大小 ≤ 2GB、文件数 ≤ 5000；万张 RAW 别用 ZIP，老老实实用 Chrome 原地改名。

Q: "按 EXIF 排序" 和 "用 {exif-date} 命名" 是同一件事吗？

不是同一件事，但通常一起用。(1) 按 EXIF 排序 —— 决定文件出现的顺序，影响 {n} 序号怎么编。(2) {exif-date} 命名 —— 决定文件名内容。实战配方：模板填 {exif-date}_{n3}{ext}，排序选"按拍摄时间 (EXIF) 升序"——这样同一天拍的多张图会按时间顺序得到 20240315_001.jpg、20240315_002.jpg……只命名不排序会出现什么问题？文件名带日期了，但 {n} 仍按"导入顺序 / 文件名字母序"编——拍摄顺序乱了。只排序不命名会出现什么问题？文件名仍是 IMG_4321 这种相机原名，光看名字看不出顺序，必须按时间列才有意义。最佳实践：拍摄时间排序 + {exif-date}_{exif-time}{ext} 模板，文件名自己就携带时间信息，丢到任何系统按字母序排都正确。

Q: 改名前怎么校验规则正确？万一改坏了能撤销吗？

批量改名不进回收站，操作系统层面不可撤销——所以"预览"才是核心。本工具的预览特性：(1) 逐行显示旧 → 新映射，鼠标悬停看完整路径；(2) 重名标红——若多个文件最终落到同一个新名，红色高亮且执行按钮自动禁用；(3) 非法字符标红——出现 \\/:*?\"<>| 这些 Windows 不允许的字符，同样禁用执行。安全工作流：(1) 先在测试目录试——把 10 张图拷到 test/ 文件夹跑一遍规则，预览满意再回到原目录；(2) 重要文件先备份——婚礼/旅行/合同扫描件这种不可重拍的素材，操作前压缩备份一份到云盘；(3) 保留可逆性——模板留 {name} 部分（如 {exif-date}_{name}{ext}），改完仍能看出原始相机命名，万一某张错了能溯源到相机的 IMG_4321。别犯的错：兴致冲冲清空所有原名 + 不加唯一性占位符 → 全部撞名 → 系统提示重名跳过 → 半数文件保留原名 + 半数变新名混乱一锅粥。

2026-05-21 · 约 6 分钟 🔠 文件批量重命名

整理硬盘里几年前的照片是越来越多人的隐痛——iPhone 导出的 IMG_4321.HEIC、单反的 DSC_0987.NEF、无人机的 DJI_0042.JPG、网盘下载回来又被 QQ 改成 mmexport1709891234567.jpg——文件名彻底失去时间线意义。

EXIF 里其实藏着每张图准确到秒的拍摄时间，把它批量提到文件名就行。这篇按”先看 EXIF → 选执行方式 → 拼命名模板 → 兜底无 EXIF → 时区与跨机型问题”五段讲清楚。

EXIF 拍摄时间到底是什么

打开任意一张相机/手机直出的图片，里面有一个标准字段 DateTimeOriginal（也叫”原始拍摄时间”），格式是字符串 2024:03:15 14:23:07（注意年月日之间是冒号不是横杠，这是 EXIF 规范）。

字段	来源	内容
`DateTimeOriginal`	相机/手机按下快门时写	拍摄那一刻
`DateTimeDigitized`	数字化时间	通常等于上面，但扫描胶片时不同
`DateTime`	修改时间	后期处理时会被更新
`mtime`（文件系统）	OS 维护	任何拷贝、转码都可能改

90% 场景认准 DateTimeOriginal。本工具的 {exif-date} / {exif-time} 占位符读的就是它。

文件修改时间为什么不可靠

不少人凭直觉以为”文件创建时间 = 拍摄时间”，几乎不成立。

操作	对 mtime 的影响
相机/手机内拷贝到 SD 卡	通常保留
iCloud / Google Photos 下载	重置为下载时间
微信 / QQ 接收	重置为接收时间
拷到 NAS 再拷回来	视协议而定（SMB 多半重置）
AirDrop	iOS 通常保留、跨 macOS 不一定
双击图片用 Preview 打开	可能更新为打开时间
第三方相册 App 同步	不可预料

实测：一张 2018 年拍的旧照片，从 iCloud 下载到电脑，mtime 显示 2024 年。这就是为什么必须读 EXIF。

主流格式的 EXIF 兼容性

本工具底层用 exifr 库，覆盖如下：

格式	拓展名	EXIF 支持	备注
JPEG	`.jpg` `.jpeg`	✅ 完整	最稳
HEIC / HEIF	`.heic` `.heif`	✅ 完整	iPhone 默认格式
TIFF	`.tif` `.tiff`	✅ 完整	扫描件常见
Nikon RAW	`.nef`	✅ 完整
Canon RAW	`.cr2` `.cr3`	✅ 完整
Sony RAW	`.arw`	✅ 完整
Fuji RAW	`.raf`	✅ 完整
Panasonic RAW	`.rw2`	✅ 完整
DJI DNG	`.dng`	✅ 完整	无人机、Adobe DNG
PNG	`.png`	⚠️ 极少	标准不含 EXIF
WebP	`.webp`	⚠️ 看导出	Google Photos 写、浏览器另存不写
截图	任意	❌ 无	系统截图工具不写 EXIF

没 EXIF 的图怎么办？{exif-date} 输出空字符串——模板写成 {exif-date}{name}{ext} 兜底，无 EXIF 时至少保留原名。

模板	产物	适合
`{exif-date}{ext}`	`20240315.jpg`	一天只拍一张（少见）
`{exif-date}_{exif-time}{ext}`	`20240315_142307.jpg`	日常推荐，到秒级唯一
`{exif-date}_{exif-time}_{n3}{ext}`	`20240315_142307_001.jpg`	连拍场景最稳，绝不重名
`{exif-date}_{n3}{ext}`	`20240315_001.jpg`	不在意秒数、只想看日期 + 顺序
`{exif-date}_{name}{ext}`	`20240315_IMG_4321.jpg`	保留相机原名做溯源
`IMG_{exif-date}_{n4}{ext}`	`IMG_20240315_0001.jpg`	模仿 Google Photos 命名风格

“按 EXIF 排序”必须打开

模板带 {n} 序号时，序号的编号顺序由”排序”决定：

排序	1.jpg → 100.jpg 的编号依据
按文件名	原相机文件名字母序（IMG_4321 < IMG_4322）
按修改时间	文件系统 mtime，不一定是拍摄顺序
按拍摄时间 (EXIF)	DateTimeOriginal，真正的拍摄顺序
按导入顺序	你拖入文件的顺序，不稳定

拍摄时间整理图库一律选”按拍摄时间 (EXIF)“。否则模板带日期但序号乱跳，看起来很奇怪。

原地改名 vs ZIP 下载

维度	原地改名	ZIP 下载
浏览器	Chrome / Edge / 新版 Safari	全部浏览器
加载方式	左下”选择文件夹”按钮（必须）	拖入 / 选文件均可
是否产生副本	否，直接改原文件	是，原文件不动 + ZIP
内存占用	低（不全量加载）	高（全部读进内存打包）
文件规模上限	几万张 RAW 也行	总大小 ≤ 2GB、≤ 5000 文件
撤销	不可撤销——但可用工具反向跑	原文件还在，可用作”回退”

整理本地图库直接用原地改名。分享给朋友 / 跨设备走 ZIP。

关键限制：原地改名只处理目录的直接子文件，不递归子目录——这是浏览器安全限制，避免误改深层结构。需要递归整理时，每个子目录单独跑一次。

时区与跨机型时间偏移

EXIF 的 DateTimeOriginal 是本地时间字符串，不带时区信息——同一张图在不同时区的人读到都是同一行字。

常见错位场景：

场景	表现	怎么修
出国旅游胶片机没改时区	全部图差固定小时数	用 ExifTool `AllDates+=8` 批量修，再回工具改名
iPhone GPS 时区识别错	个别图差 6-12 小时	重命名后手动修这几张
多机协同（婚礼摄影）	不同机器时间不一致	拍前对齐所有机器系统时间，事后 ExifTool 修
跨年/跨日临界	凌晨 00:00 前后的图错乱	通常是手机时区切换瞬间，影响小

实战建议：

出国旅行前——相机系统时间调到目的地时区
拍重要场合前——所有协同机器对齐到同一时钟（手机看准官方授时再调）
整理时先抽样验证——抽一张已知拍摄时间的图，看 EXIF 是否吻合，再批量改名

没 EXIF 的图怎么兜底

截图、网图、被微信压缩过的图—— {exif-date} 会输出空字符串。三种兜底策略：

策略 1：保留原名

模板：{exif-date}{name}{ext}
有 EXIF：20240315IMG_4321.jpg
无 EXIF：IMG_4321.jpg（fallback 到原名）

策略 2：用修改时间兜底

模板：{exif-date}{mtime}{ext}
有 EXIF：20240315.jpg（exif 已经填了，mtime 也填但拼一起）
无 EXIF：20231220.jpg（仅 mtime）

不太推荐——同一张图可能两个日期都填上变成 20240315_20231220.jpg，反而乱。

策略 3：两次跑工具

先用 {exif-date}_{exif-time}{ext} 改一遍（带 EXIF 的图变成新名、无 EXIF 的图变成纯 .jpg 标红跳过），把没改成的单独挑出来再用 {mtime}_{name}{ext} 跑第二遍。

最稳的是策略 1 —— 一次跑完，无 EXIF 的图保留可识别的原名，事后人工挑出来手动处理。

完整示例：婚礼摄影师整理 5000 张

场景：单反 + 副机两台机器拍，总共 5000+ 张 NEF + JPG，按相机的 IMG_ 序号排没意义（两台机器都从 0 开始），按拍摄时间整理才能还原完整流程。

步骤：

把两台机器的卡都倒到同一文件夹 wedding-2024-03-15/
Chrome 打开工具，点”选择文件夹（原地改名）“加载
排序选”按拍摄时间 (EXIF) 升序”
模板填 {exif-date}_{exif-time}_{n4}{ext}
预览检查重名行（连拍可能撞秒）—— {n4} 兜底已经保证唯一
检查”无 EXIF”标记（手机抓拍的旁拍图可能在）—— 模板可改 {exif-date}_{exif-time}_{n4}_{name}{ext} 保留原名兜底
执行 → 5000 张文件名变成 20240315_092301_0001.NEF、20240315_092301_0002.JPG（两机器同秒都拍到）
抽 20 张验证——确认仪式、敬酒、合影各段时间合理

产物：丢进 Lightroom 直接按文件名排序就是真实拍摄顺序，比按时间排更稳（断电、卡导出顺序错乱都不影响）。

一句话总结

{exif-date}_{exif-time}_{n3}{ext} 模板 + “按拍摄时间 (EXIF)” 排序 + Chrome 原地改名 —— 这套组合解决了 95% 的照片整理场景。事前抽样验证 EXIF、事后抽 10 张校验时区——剩下 5% 的奇葩问题在这两步就能拦截。

整理完图库后，下一步是清除 EXIF 隐私（GPS、相机序列号）再分享——用 [[exif-clean]]；统一格式压缩——用 [[image-compress]]；做成长图分享——用 [[long-image]]。

❓ 常见问题

{exif-date} 和 {mtime} 看着都是日期，到底差在哪？该用哪个？

两者根本不同。(1) {exif-date} 读的是图片文件内部 EXIF 的 DateTimeOriginal 字段——相机/手机在按下快门那一刻写进去的，反映真实拍摄时间。(2) {mtime} 读的是文件系统的最后修改时间——经过任何拷贝、剪辑、转码、AirDrop、QQ/微信传输都可能被更新成"今天"。90% 场景应该用 {exif-date}：原图（包括 RAW、HEIC、JPG）从相机/手机直接导出、没经过编辑——拍摄时间稳定可靠。{mtime} 兜底：视频文件（EXIF 不支持视频）、被压缩处理过的图片、截图——视频建议用 {mtime}，但要确认中间没经过微信/QQ 二次转发（那会改 mtime）。实战推荐：模板填 {exif-date}_{exif-time}{ext}，没 EXIF 的图自动留空——再用兜底模板 {exif-date}{name}{ext} 保证至少不丢原名。

为什么导出的照片时间和我拍照时差几小时？

多半是时区问题。EXIF 的 DateTimeOriginal 本身不带时区，只是个本地时间字符串"2024:03:15 14:23:07"。常见错位场景：(1) 相机没设时区——出国旅行用的胶片相机/单反，设的还是国内时间，但你想要拍摄当地的时间；(2) 手机自动同步出错——iPhone/Android 偶尔会因 GPS 时区识别错误把照片打上"上午 2 点"的标；(3) 跨时区导入后又换电脑——同一张图在不同电脑读到的 mtime 不同，EXIF 反而稳定。处理思路：(1) 拖入工具前先用 [[photo-info]] 看一张样本图的 EXIF，确认时间和你预期是否吻合；(2) 偏差固定（如全集差 12 小时）——这工具不支持批量加减时间，可以先用 [[exif-clean]] 或 ExifTool 命令行修正再回来重命名；(3) 偏差是个别图——重命名后手动改文件名解决。关键认知：EXIF 时间是相机记的"本地时间"，不是 UTC——出国旅行前先把相机时间调成目的地时区。

iPhone HEIC、Android JPG、单反 RAW、无人机 DNG 都能读 EXIF 吗？

主流格式全支持，靠 exifr 库覆盖。(1) JPG / JPEG —— 通用 EXIF，所有相机/手机/导出工具都写。(2) HEIC / HEIF —— iPhone 默认格式（iOS 11+），EXIF 完整。(3) TIFF —— EXIF 原生，扫描件 / 部分相机直出。(4) RAW 家族：Nikon NEF、Canon CR2/CR3、Sony ARW、Fuji RAF、Panasonic RW2、Pentax PEF、Olympus ORF、DJI DNG、Adobe DNG——全部能读 DateTimeOriginal。(5) WebP —— 部分写 EXIF 部分不写（Google Photos 导出的通常有，浏览器另存的没有）。不支持的：(1) PNG —— PNG 标准不含 EXIF，但 macOS / iPhone 导出的 PNG 里有时藏在私有 chunk，exifr 读不到，当无 EXIF 处理；(2) 截图 —— 几乎都没 EXIF（系统截图工具不写）；(3) 网络下载图 —— 多数 CDN 处理后 EXIF 被剥光保护用户隐私。无 EXIF 时 {exif-date} 输出空字符串，记得加 {name} 兜底避免空文件名冲突。

"原地改名"和"ZIP 下载"该选哪个？原地改名是什么原理？

原地改名直接改原文件，没副本——浏览器调用 File System Access API 请求该目录的写权限，然后逐个 move() 重命名，不需要把文件读进内存。优点：(1) 万级文件也不卡——文件不全量加载；(2) 不占下载带宽，不产生临时 ZIP 占硬盘；(3) 修改时间通常保留（rename 不动 mtime）。前提：Chrome / Edge / Opera 等 Chromium 系列 + 新版 Safari 支持；Firefox 不支持。必须用左下"选择文件夹（原地改名）"按钮加载，不能拖入文件——拖入的是 File 对象，没目录句柄写不回原位。ZIP 下载兜底：(1) Firefox / 旧浏览器；(2) 想保留原文件做对照；(3) 跨设备整理（在 PC 上准备，把 ZIP 拷到 NAS）。ZIP 模式会把所有文件读进内存再打包，建议总大小 ≤ 2GB、文件数 ≤ 5000；万张 RAW 别用 ZIP，老老实实用 Chrome 原地改名。

"按 EXIF 排序" 和 "用 {exif-date} 命名" 是同一件事吗？

不是同一件事，但通常一起用。(1) 按 EXIF 排序 —— 决定文件出现的顺序，影响 {n} 序号怎么编。(2) {exif-date} 命名 —— 决定文件名内容。实战配方：模板填 {exif-date}_{n3}{ext}，排序选"按拍摄时间 (EXIF) 升序"——这样同一天拍的多张图会按时间顺序得到 20240315_001.jpg、20240315_002.jpg……只命名不排序会出现什么问题？文件名带日期了，但 {n} 仍按"导入顺序 / 文件名字母序"编——拍摄顺序乱了。只排序不命名会出现什么问题？文件名仍是 IMG_4321 这种相机原名，光看名字看不出顺序，必须按时间列才有意义。最佳实践：拍摄时间排序 + {exif-date}_{exif-time}{ext} 模板，文件名自己就携带时间信息，丢到任何系统按字母序排都正确。

改名前怎么校验规则正确？万一改坏了能撤销吗？

批量改名不进回收站，操作系统层面不可撤销——所以"预览"才是核心。本工具的预览特性：(1) 逐行显示旧 → 新映射，鼠标悬停看完整路径；(2) 重名标红——若多个文件最终落到同一个新名，红色高亮且执行按钮自动禁用；(3) 非法字符标红——出现 \\/:*?\"<>| 这些 Windows 不允许的字符，同样禁用执行。安全工作流：(1) 先在测试目录试——把 10 张图拷到 test/ 文件夹跑一遍规则，预览满意再回到原目录；(2) 重要文件先备份——婚礼/旅行/合同扫描件这种不可重拍的素材，操作前压缩备份一份到云盘；(3) 保留可逆性——模板留 {name} 部分（如 {exif-date}_{name}{ext}），改完仍能看出原始相机命名，万一某张错了能溯源到相机的 IMG_4321。别犯的错：兴致冲冲清空所有原名 + 不加唯一性占位符 → 全部撞名 → 系统提示重名跳过 → 半数文件保留原名 + 半数变新名混乱一锅粥。