把乱七八糟的日期写法统一成 ISO 日期

做数据相关的活，迟早会撞上同一面墙：一列日期，十种写法。有人写 2026/1/5，有人写 Jan 5 2026，有人随手敲了个 2026.01.05，CSV 导出里又混进来 06/12/2026 这种到底是 6 月 12 日还是 12 月 6 日都说不清的格式。这堆东西塞进数据库、丢进排序逻辑，结果就是排序乱掉、查询对不上、报表数字全错。

解决办法很朴素：先把它们全部统一成一种写法，也就是 ISO 8601 的 YYYY-MM-DD。这篇讲清楚为什么是这个格式，以及怎么批量做完这件事。

为什么偏偏是 ISO 8601

ISO 8601 把日期写成「年-月-日」，年四位、月两位、日两位，比如 2026-01-05。它有两个别的写法给不了的好处。

第一是无歧义。06/12/2026 在美式习惯里是 6 月 12 日，在欧式习惯里是 12 月 6 日，同一串字符两种读法。2026-06-12 没有这个问题，年在最前，谁来读都是一个意思。

第二是能正确排序。这是最容易被低估的一点。YYYY-MM-DD 这种从大单位到小单位、且每段都补零的写法，按字符串字典序排出来的顺序，恰好就是时间先后顺序。换句话说，数据库、Excel、脚本里任何一个普通的文本排序，都能把它排对，根本不需要先解析成日期对象。2026-01-05 排在 2026-01-12 前面，2026-02-01 又排在它们后面，纯按字符比就成立。换成 1/5/2026 这种，字典序会把 1/12/2026 排到 1/5/2026 前面，因为 1 后面的 2 比 5 小，时间顺序直接错乱。

一个真实的输入输出例子

举个我自己常遇到的场景。手头有几行从不同表里抄来的日期：

2026/1/5
Jan 5 2026
2026.1.5

它们其实指的是同一天，但形态各异。统一之后，全部变成：

2026-01-05

月和日都补成两位，分隔符统一成连字符，年份摆到最前面。这一行现在可以放心地去和别的日期比大小、做排序、当主键的一部分，不会再有人读错。

数据清洗、导入数据库、排序

把格式统一只是第一步，真正交付前还有三件事要做。

去重。多份导出拼在一起，重复日期一抓一大把，先按规范化后的结果去重，剩下的才是干净的唯一值。

保留无效项复核。手工维护的列表总会飘：打错的 2026-06-32、美式非 ISO 的 06/12/2026、空着的单元格。与其默默丢掉，不如把这些无效行单独带出来，这样你能精确看到导入时数据库的日期列会拒掉哪几条，提前在本地处理掉，而不是等导入报错才回头找。

排序后导出。统一并去重之后再按规范化结果排序，导出成 CSV、JSON 或者直接生成 SQL IN 子句，交给 CRM、工单系统或脚本，省掉手工加引号、补逗号这些容易漏的活。

为什么强调本地处理

日期看着无害，但它常常贴着客户记录、订单号、内部标识符一起来。把整列数据传到某个在线服务去转格式，等于把这些上下文也一起送出去了。ISO 日期列表转换器的解析、校验、去重、导出全部在你自己的浏览器标签页里完成，上传的文本文件也是用浏览器的 File API 在本地读，不进任何服务器。对要守数据权限的场景，这一点不是加分项，是底线。

顺带提醒一句：格式校验只管形态对不对，不代表这个日期对应的业务事实真的存在。2026-02-30 这种会被挡下，但 2026-02-28 格式没毛病，至于那天到底有没有发生过你要的事，工具不负责，得靠你自己核。

配套的几个小工具

整条清洗链路里，每一步都能拆出来单独用。只想把混乱写法规整成标准形态、不做别的，可以用 ISO 日期规范化工具，它专做这一件事。需要从一大段日志或网页复制内容里先把日期抓出来，再走统一流程，思路也是一样的：先提取、再规范化、最后去重导出，每一段都在本地跑完。

一句话收尾

日期统一不是什么高深活，但它决定了后面排序对不对、导入顺不顺。记住一条：能字典序正确排序又无歧义的，只有 YYYY-MM-DD。把所有写法都收敛到它，剩下的就都顺了。

Made by Toolora · Updated 2026-06-13