正则解析文件名时如何在捕获组中排除月、日的前导0

场景说明 #

处理固定命名格式的备份文件时，常见文件名结构为：

• d31_20210315-19232.sql.tar.gz
• d31_20201215-19232.sql.tar.gz
  其中年份的匹配逻辑已经可以通过正则轻松实现，对应表达式为：
  (?<=_)(?P<year>\d{4})

遇到的卡点 #

需要匹配月份、日期字段时，希望捕获组直接去掉数值前导0，不需要后续额外写代码做字符串截断：

• 月份的期望效果：对应01-09这类带前导0的月份时，捕获值直接取1-9；对应10-12这类非零开头的月份时，捕获值直接取10-12，不保留前导0。
• 之前尝试写的正则(0(?P<month>[1-9]))|((?P<month>[1][1-9]))跑不通：一方面是分支范围不对，漏了10月，还会错误匹配13-19这类无效月份；另一方面分支结构不严谨，部分正则引擎会出现解析兼容问题。
• 日期的捕获需求和月份完全一致：捕获组直接返回去掉前导0的1-31范围值，不需要后续代码做字符串处理。
  本来打算绕开正则的捕获能力，额外写代码截断前导0，但一直卡正则的实现思路。

实现思路 #

之前卡壳的本质是写正则时惯性把整个带前导0的字段裹进捕获组，导致捕获结果里带0。只要反过来把前导0挪到捕获组的边界外面，再用互斥分支共用同一个命名捕获组，就能直接拿到不带前导0的捕获值，根本不需要事后写代码处理。
具体拆分逻辑：

1. 把带前导0的1-9范围、不带前导0的双位数范围拆成两个完全不会重叠的互斥分支。
2. 对带前导0的分支，把0写在捕获组的外部边界上，让正则引擎不会把0存入捕获结果。
3. 因为两个分支永远不会同时命中，所以同一个命名捕获组在不同分支下赋值完全合法，不会出现冲突。

可直接使用的完整正则 #

(?<=_)(?P<year>\d{4})(?:0(?P<month>[1-9])|(?P<month>1[0-2]))(?:0(?P<day>[1-9])|(?P<day>[12]\d|3[01]))

匹配效果验证 #

拿常见的文件名时间段测试，结果完全符合预期：

这个正则在PCRE、Python re、Java Regex、JS 正则等主流引擎里都能正常运行，不需要额外写代码处理前导0。 #

内容的提问来源于stack exchange，提问作者James