ISO 日期校验:把一整列日期一次性查完,揪出不存在的那几行

做数据导入的人都遇到过这样的场景:手里一份 CSV,某一列全是日期,几百上千行。肉眼看着都长得差不多,可一旦灌进数据库或脚本,某几行就报错。问题往往出在两类地方:一是格式不对,二是日期根本不存在。后者最坑,因为它看上去格式完全正确。

ISO 8601 标准里,日期写成 YYYY-MM-DD,比如 2026-05-24。这个格式的好处是排序即时间序、跨时区无歧义、各种语言都能解析。但格式对,不代表日期真实存在。这就是批量校验要解决的核心问题。

格式对,不等于日期真实存在

先说清楚一个常被忽略的点:YYYY-MM-DD 只是模板,月和日还得落在真实范围内。月份必须是 01 到 12,日要看具体月份,1、3、5、7、8、10、12 月最多 31 天,4、6、9、11 月最多 30 天,2 月平年 28 天、闰年 29 天。

举个最容易混的例子。2026-02-28 是有效的,2026 不是闰年,2 月只有 28 天,这一行没问题。但 2026-02-30 就是无效的,2 月根本没有 30 号,这一行必须被揪出来。两行格式一模一样,差别只在那个日不存在。光靠正则匹配 \d{4}-\d{2}-\d{2} 是查不出来的,正则会把 2026-02-30 判为合格,真正灌库时才崩。

类似的坑还有 2026-13-40(月份越界、日也越界)、2026-04-31(4 月没有 31 号)、2026-00-15(没有 0 月)。这些都是格式过关、内容不存在的典型。

含时区的时间戳怎么校验

很多日期其实是带时间和时区的完整时间戳,比如 2026-05-24T09:30:00+08:00 或者结尾带 Z 的 UTC 形式 2026-05-24T09:30:00Z。ISO 8601 允许这些写法,但偏移量也有规矩:小时部分在 -12 到 +14 之间,分钟通常是 00、15、30、45。校验时除了查日期那一截,还要确认时间部分(时 0-23、分秒 0-59)和时区偏移是否合法。一份日志里混着裸日期和带时区时间戳很常见,工具会逐行判断,不会因为格式更复杂就漏掉错误。

一份真实的输入输出

我自己上次清一份运营导出的发布日期表,直接把整列粘进 ISO 日期列表校验器,它一行行给我标了出来。粘进去的是这样几行:

出来的报告大致是:2026-02-28 通过,2026-05-24 通过;2026-02-30 标红,原因是 2 月没有 30 日;24/05/2026 标红,原因是顺序写反、不符合 ISO 格式;2026-13-01 标红,原因是没有 13 月。每一行旁边都印着失败原因,报告直接变成一份待修清单,而不是一句笼统的"有错误"。

为什么要保留无效行

很多校验工具默认把错误行丢掉,只留对的。但做数据修复时,你需要的恰恰是那批错的。把无效行连同原因一起带出来,你才知道要回原始表改哪几行、怎么改。这个工具支持保留无效项、保留行号,这样能对回源文件的具体位置。需要审计线索时,建议下载带行号的 CSV 或 Markdown,而不是只复制最终列表。

本地处理,数据不出浏览器

日期列里常常夹着客户 ID、订单号这类信息。整个校验、去重、规范化、导出都在浏览器当前标签页完成,上传的文本文件通过 File API 本地读取,不会发到服务器。几 MB 的 CSV 或日志最顺手;真碰上几 GB 的大日志,先在本地切片再粘。

校验完之后

查出错误只是第一步。如果你要把这列日期统一改成标准写法,可以接着用 ISO 日期规范化工具把混乱格式拉齐成 YYYY-MM-DD。需要把日期从一大段日志或网页里先抠出来,再交给校验器,流程就更顺。

一句提醒:日期校验只证明格式和内容合法,不代表这条记录背后的业务事实成立。格式对、日期真实存在,是数据可用的底线,不是终点。

Made by Toolora · Updated 2026-06-13