日期规范化实战:把五花八门的写法统一成标准 ISO 日期

我接手过一张供应商交付表,同一列里挤着 2026/1/5、2026-01-05、2026.1.5、5/1/2026 四种写法。表面上它们指的可能是同一天,可一旦交给脚本或数据库,排序就乱套,去重也对不上。这就是日期规范化要解决的问题:把所有写法收敛成一种,机器才认得。

为什么 2026/1/5 和 2026-01-05 必须统一

人眼能看出 2026/1/5 和 2026-01-05 是同一天,程序不能。字符串比较是逐字符进行的,2026/1/5 和 2026-01-05 在字节层面完全不同,系统会把它们当成两条记录:去重时留下两份,统计时分别计数。

更隐蔽的是排序。按字符串排,2026/10/1 会排在 2026/2/1 前面,因为字符 1 小于字符 2,月份没补零时,十月就被排到了二月之前。只有把月、日都补成两位,变成 2026-10-01 和 2026-02-01,字符串排序才和时间顺序一致。这是排序前必须先规范化的根本原因。

ISO 8601 选择 YYYY-MM-DD 不是随意定的:年在前、月居中、日在后,加上固定补零,字符串的字典序天然等于时间的先后序。这一个性质,省掉了后续无数判断。

规范化到底做了哪几件事

把一条日期归一成标准 ISO 日期,实际拆成几个动作:

• 统一分隔符:把 /、.、空格都换成连字符 -。
• 月日补零:1 月补成 01,5 日补成 05,统一成两位。
• 统一顺序:识别出年、月、日各自的位置,统一排成年月日。
• 剔除多余空白:复制来的文本常带不可见的首尾空格和制表符,一并清掉。

这四步做完,2026/1/5 就稳定地变成 2026-01-05,无论它原来长什么样。

一个真实的输入输出例子

下面是我从一份导出 CSV 里抠出来的原始片段,直接贴进工具:

2026/1/5
2026-01-05
2026.3.9
2026/12/1

规范化后的输出:

2026-01-05
2026-01-05
2026-03-09
2026-12-01

注意前两行:2026/1/5 和 2026-01-05 归一后完全相同,这时再开启去重,就只剩一条 2026-01-05。如果不先规范化直接去重,这两行会被当成两个不同的值,白白多出一条。可以用 日期去重工具 把统一后的列表压成唯一值。

数据清洗:排序和去重前先归一

我自己的习惯是,任何要排序或去重的日期列,先过一遍规范化再说。顺序很重要:规范化在前,去重在后。先把写法统一,相同的日期才会真正相等;否则去重器看到的是一堆"看起来一样、字节不一样"的字符串,一条都合并不掉。

排序同理。补完零、统一了分隔符的列表,直接按字符串升序排,结果就是正确的时间顺序,不需要再解析成日期对象。这在写 SQL 的 ORDER BY、生成测试 fixture、对账时都省事。规范化好的列表还能直接导成 CSV、JSON 或 SQL IN 片段,接着喂给下游脚本。

在浏览器本地处理,不上传

ISO 日期规范化工具 的解析、补零、去重、导出全部在你的浏览器标签页里完成。粘贴的文本也好,上传的本地文件也好,都通过浏览器的 File API 在本地读取,不会发到任何服务器。

这一点对真实工作场景很关键。供应商交付记录、客服工单导出、内部日志,这些数据往往带着客户信息或内部标识符,本来就不该传到外部服务。本地处理意味着你可以放心把整段日志贴进去,而不用先手动脱敏。处理完直接复制或下载结果即可。

如果你的原始数据里日期和其它字段混在大段文本里,可以先用 日期提取工具 把日期单独抓出来,再交给规范化这一步。两个工具配合,从一锅乱炖的日志到一份干净有序的 ISO 日期列表,中间不需要离开浏览器。

小结

日期规范化的价值,在于让机器能正确地比较、排序、去重你的日期数据。2026/1/5 和 2026-01-05 在你眼里是一天,在程序眼里要先归一成 2026-01-05 才是一天。月日补零、统一分隔符、清掉空白,这三件小事做扎实,后面所有的排序和去重才站得住脚。全程本地处理,数据不出浏览器,清洗就这么简单。

---

Made by Toolora · Updated 2026-06-13