正则表达式速查表，免费

模式语言简史

正则表达式起源于理论计算机科学。Stephen Kleene 在 1956 年关于神经网络的论文中定义了「正则集」;Ken Thompson 于 1968 年用 grep 把它们带进 Unix。Henry Spencer 的开源 regex 库(1980 年代中期)成为后来许多实现的基础。Larry Wall 在 Perl 中大幅扩展了语法,他的「Perl-compatible regular expressions」(PCRE)成为大多数现代语言追随的事实标准。如今存在几种紧密相关但又微妙不同的 regex 风味,在一个引擎里能跑的模式,在另一个引擎里不一定一模一样地跑。

你的模式所栖身的引擎

同一段语法在不同引擎里可能表示不同的意思。主要家族:

• POSIX BRE(Basic Regular Expressions),被 grep 默认模式、sed 使用。许多元字符需要反斜杠转义:(、)、{、}、+、?、| 不转义则被当作字面量。
• POSIX ERE(Extended Regular Expressions),被 egrep、awk 使用。上述元字符无需转义就能用。
• PCRE(Perl-Compatible Regular Expressions),在 ERE 之上扩展了 lookarounds、atomic groups、命名捕获和反向引用。被 PHP 和大多数现代语言使用。Perl 派生的简写类 \d / \w / \s 是 PCRE、JavaScript、.NET、Java 和 Python 的共同点。
• JavaScript RegExp,接近 PCRE 但有显著差异。ES2018 加入了 lookbehinds、命名捕获组、s dotall 标志和通过 u 标志启用的 Unicode property escapes。用于集合记法的 v 标志在 ES2024 到来。
• Python re 与 Python regex,re 在标准库里;第三方 regex 模块加入了 Unicode 感知功能、可变宽度 lookbehinds 和其它 PCRE 风格的增强。
• RE2(Google 的库,用在 Go 里),保证线性时间但不支持反向引用或 lookarounds。权衡:可预测的性能,功能更少。

这份小抄的交互测试器在 JavaScript 中运行,所以模式由浏览器的 JS 引擎评估。在这里能跑的模式,在 Python 或 PHP 中可能表现不同。大多数差异在于高级功能(lookbehinds、Unicode property escapes、反向引用),而不是基本语法。

核心构件

几乎每一个 regex 模式都由这些元素构成:

• 字面量,匹配它们自己。cat 匹配子串「cat」。
• 锚点,^(字符串/行的开头)、$(结尾)、\b(词边界)、\B(非词边界)。
• 字符类,[abc] 匹配 a、b 或 c。[^abc] 取反。[a-z] 是范围。简写:\d(数字)、\w(词字符:字母、数字、下划线)、\s(空白),以及取反的大写版本(\D、\W、\S)。
• 量词,?(0 或 1)、*(0 或更多)、+(1 或更多)、{n}、{n,}、{n,m}。默认贪婪(尽可能多匹配);加 ? 变懒惰:*?、+?、??。
• 组,(...) 捕获、(?:...) 非捕获、(?<name>...) 命名(PCRE / JS / Python)。
• 分支,cat|dog 匹配两者之一。
• Lookarounds,(?=...) 正向 lookahead、(?!...) 负向 lookahead、(?<=...) 正向 lookbehind、(?<!...) 负向 lookbehind。匹配但不消耗。
• 反向引用,\1、\2(编号)、\k<name>(命名)。匹配相应捕获所匹配的同一段文本。
• 标志,g(全局)、i(不区分大小写)、m(多行:^ 和 $ 匹配行边界)、s(dotall:. 也匹配换行)、u(Unicode)、y(JS 的 sticky)。

值得记下来的模式

有一小撮模式出现得太频繁,值得放在脑子里:

关于邮箱 regex 的说明:完整的 RFC 5322 邮箱验证需要一段 6 000 字符的怪兽 regex。上面那条简单形式接受 99% 的真实邮箱,且不会拒掉任何合法邮箱;在生产环境中,与其想完美校验语法,不如发一封确认邮件。

贪婪 vs 懒惰:常见的意外

默认情况下,量词是贪婪的:它们会尽可能多匹配,同时仍让整体模式能够匹配。所以 <.+> 对 <a>text</a> 会匹配整段,而不仅仅是 <a>,因为 .+ 会抓尽可能多。要匹配最短可能的字符串,在量词后加 ?:<.+?> 会先匹配 <a>,再单独匹配 </a>。贪婪/懒惰的选择是「为什么我的 regex 没匹配到我期望的东西」这类 bug 的最常见来源之一。

灾难性回溯与 ReDoS

有些 regex 模式在某些输入上需要指数时间才会失败,这是一类被称为 ReDoS(Regular Expression Denial of Service)的拒绝服务漏洞。典型元凶是嵌套量词,比如 (a+)+ 或 (a|aa)+,作用在一长串 a 后面跟一个不匹配字符的输入上。引擎会在放弃之前尝试每一种切分字符串的方法,而方法数量是指数级的。

现实事故:Cloudflare 2019 年的故障由部署在 WAF 规则里的一段 regex 在某些输入上灾难性回溯触发。Stack Overflow 在 2016 年 7 月也遇到过类似事件:一段 post-trim regex(^[\s‌]+|[\s‌]+$)在一条包含约 20 000 个连续空白字符的评论上撞上了指数回溯,把站点击垮 34 分钟。防御性习惯:避免嵌套量词,在支持的地方优先使用 atomic groups((?>...)),并考虑对不可信输入使用 RE2 / 线性时间引擎。

值得知道的各语言怪癖

• JavaScript:反斜杠在字符串字面量里需要双重转义("\\d"),但在 regex 字面量里不需要(/\d/)。能用 regex 字面量就用 regex 字面量。
• Python:使用原始字符串(r"\d+")以避免反斜杠问题。re 模块在标准库里;PyPI 上的 regex 添加了额外功能。
• Java:反斜杠需要四重转义("\\\\d" 表示 \d),因为 Java 字符串字面量用 \ 作为转义,然后 regex 编译器才看到 \\d。
• Bash:[[ string =~ pattern ]] 中的 regex 匹配使用 POSIX ERE。引号规则很微妙;请查阅 man bash。
• Go:使用 RE2,所以反向引用和 lookarounds 不可用。权衡:线性时间保证。

什么时候不要用 regex

Jamie Zawinski 1997 年的著名一句:「Some people, when confronted with a problem, think 'I know, I'll use regular expressions.' Now they have two problems.」

• 不要用 regex 解析 HTML / XML。用真正的解析器(浏览器中的 DOMParser、Python 的 BeautifulSoup、Java 的 jsoup 等)。HTML 的嵌套结构从根本上超出了 regex 能干净地表达的范围。
• 不要用 regex 解析 JSON。用 JSON.parse / 标准库的 JSON 解析器。
• 不要用 regex 严格验证邮箱。发一封确认邮件;那才是唯一可靠的测试。
• 不要把 CSV 解析器写成 regex。带嵌入逗号的引号字段、转义引号和多行值,很快就超出 regex 能干净处理的范围。
• 不要试图匹配平衡的括号。标准 regex 不行(那是上下文无关语言);某些 PCRE 引擎有递归功能可以耍赖,但真正的解析器更干净。

常见错误

1. 忘了转义特殊字符。.、*、?、+、(、)、[、]、{、}、\、^、$、|、/ 都有特殊含义。要按字面量匹配,前面加反斜杠。
2. 贪婪量词吃太多。当你想要尽可能短的匹配时,加 ? 切换到懒惰匹配。
3. 忘了全局标志,然后疑惑为什么只显示第一个匹配。没有 g 标志,JavaScript 的 String.prototype.match() 只返回第一个匹配。
4. 长输入上的灾难性回溯。嵌套量词如 (a+)+ 在某些输入上会卡住。用边界用例测试。
5. 假设同一个 regex 在每种语言里都行为相同。Lookbehinds、Unicode 转义、字符类简写都各有不同。
6. 试图过严验证邮箱。技术上正确的 RFC 5322 regex 无法维护;简单 regex 加上注册时确认邮件,才是真正能跑的模式。
7. 对 HTML、JSON 或 CSV 使用 regex。用一个合适的解析器;前期省下的时间会在 bug 上加倍还回来。

更多常见问题

为什么我的模式在这里能跑但在我的代码里失败?

最常见的原因是引擎差异。JavaScript 的 RegExp 不支持 PCRE 支持的某些功能(反之亦然)。常见坑:lookbehinds 很晚才加入 JS(ES2018),命名组语法略有不同,Unicode property escapes 需要 u 标志,POSIX 字符类如 [[:alpha:]] 在 JS 中基本缺席。在你将要部署的引擎中测试。

有「全局」跨多行匹配的方法吗?

两个标志一起用。m(多行)标志让 ^ 和 $ 匹配每一行的开头和结尾,而不是整段字符串的开头和结尾。s(dotall)标志让 . 也匹配换行字符。再配合全局 g,你可以写跨行模式来找出每一个匹配:/^foo.+$/gms。

我的模式和测试文本会被发送到任何地方吗?

不会。模式匹配使用浏览器内置的 JavaScript RegExp 引擎;没有任何东西被上传到服务器。这在你针对真实生产日志数据、内部 API 响应或敏感内容测试模式时很重要。

我应该学 lookbehinds 吗?

有用但非必要。Lookbehinds 让你匹配前面有某物的文本,而不把那个「某物」包含进匹配里。例子:(?<=\$)\d+ 匹配美元符号后面的数字而不消耗那个美元符号。它们在 PCRE、现代 JavaScript(ES2018+)和 Python 的 regex 模块中受支持。如果你写的是可移植的模式,先检查目标引擎。

为什么用 (?:...) 而不是 (...)?

非捕获组((?:...))略快,不在捕获数组里占位置,让你的匹配结果保持干净。当你只需要分组用于分支或量化但不需要提取匹配文本时就用它。(http|https):// 创建一个你可能不需要的捕获;(?:http|https):// 不会。

匹配 Unicode 字符的正确方式是什么?

在 JavaScript 中,加上 u 标志并使用 Unicode property escapes:/\p{Letter}+/gu 匹配任意书写系统的字母序列。没有 u 标志,\w 只匹配 ASCII 词字符。Python 的 re 模块在 Python 3 中默认是 Unicode 感知的。Java 需要 Pattern.UNICODE_CHARACTER_CLASS。大多数引擎都有某种方式来支持 Unicode;查你那个引擎的文档。