正则表达式测试与替换器

不一样，而这正是这个页面的重点。它用的是 JavaScript 自己的引擎（ECMA-262），也就是浏览器和 Node 运行的那一个。Python 的 `re`、Java 的 `Pattern`、.NET、PCRE、Perl、Ruby 和 PHP 各自实现自己的语法，Go 的 RE2 和 Rust 的 regex crate 实现的是一套刻意更小的语法。有些构造只在其中一种里存在——原子组 `(?>...)`、占有量词 `a++`、`\K`、`[[:alpha:]]`、自由间距的 `x` 标志——有些构造含义不同，比如结尾换行前的 `$`、带重音字母的 `\w`、替换串里的 `$0`。面板会点名你的模式触及的差异，这比一张兼容性表有用。

通常是四件事之一。`\w`、`\d` 和 `\b` 在 JavaScript 里是 ASCII，在 Python 3 里是 Unicode 感知的，所以为中文或带重音文本写的模式在两个语言里表现不同。`$` 在 Python 里匹配结尾换行之前，在 JavaScript 里只匹配最末尾。命名组在 Python 里写作 `(?P<name>...)`，这里是 `(?<name>...)`。还有 Python 的 `re.match` 从开头锚定，JavaScript 的 `test` 在任意位置搜索，所以同一个模式在一种语言里找到匹配，在另一种里找不到。每一条都在页面上写明，而不是留给你自己发现。

当模式给引擎一个可以用指数级方式展开的选择时，就会发生。`(a+)+$` 遇上很长的一串 `a` 是经典例子：内层的 `+` 和外层的 `+` 可以把这一串切成两段、三段或四段，每一种切法都会在放弃之前试过。`(a|aa)+` 一样糟糕，看起来却人畜无害。解法是让每一次重复都消耗掉无法退回的内容：把连续段匹配一次再检查后续，能用字符类的地方就别用通配符，并记住*失败*的输入才昂贵——模式在匹配成功的文本上很快。RE2、Go 和 Rust 的正则引擎通过放弃反向引用和先行、后行断言彻底避开这个问题；浏览器做不到，所以只能识别形状。

默认情况下 `.` 匹配除行终止符以外的任意字符，JavaScript、Python、Java、.NET 和 PCRE 都是如此——所以在一行里写的 `.*` 放到文件里一个都找不到，人们的第一反应往往是怪文本。`s` 标志（dotAll）会改变这一点，`[\s\S]` 则是不需要标志、在所有 flavor 里都能用的写法。当模式用了 `.` 而文本不止一行时，页面会把这条解释放在“没有匹配”旁边，因为这几乎总是答案。

因为 `\w` 在 JavaScript 里就是 `[A-Za-z0-9_]`，任何标志组合都一样——加上 `u` 也不会改变它，而这恰恰是很多人以为能修好的地方。对 `\w+` 来说，`café` 只是 `caf`；`\bcafé\b` 什么都匹配不到，因为引擎不把 é 当作单词字符，它旁边也就没有单词边界。Unicode 感知的写法是带 `u` 标志的 `\p{Letter}`，数字用 `\p{Number}`。Python 3 默认就是 Unicode 感知的，所以同一个模式在两种语言之间搬运时，含义会悄悄改变。

因为模式没有 `g` 标志。用正则调用 `String.prototype.replace` 只替换第一处，而同一个方法用*字符串*作为查找值时替换全部——同一个方法的两半行为不一致，混淆就是从这里来的。解决办法是加 `g` 标志，或者用 `replaceAll`，后者对非全局模式会直接拒绝，而不是做出意外行为。这里的替换模式严格按照你写的标志执行，把差异展示出来，而不是替你抹平。

`d`（indices）会加上 `match.indices`：整个匹配和每个组的起止位置，这是知道一个组在哪里匹配的唯一方法——报告会把它打印成一张范围表。在替换串里，`$&` 是整个匹配，`$1` 和 `$<name>` 是捕获组，`$$` 是字面的美元符号，`` $` `` 是匹配之前的所有内容，`$'` 是匹配之后的所有内容。人们常写的两种东西根本不是引用：`$0`，.NET 用它表示整个匹配，JavaScript 把它当文本；以及 `\1`，sed、grep 和 Perl 用它，JavaScript 把它当两个字符。

安全，这也正是在浏览器里运行、而不是放到服务器上的理由。所有内容都在这个标签页里由 JavaScript 编译和匹配：页面背后没有能接收模式、文本或替换串的接口，没有日志，输入时也不发请求。你最初加载的静态 HTML 里就已经包含真实结果，如果匹配发生在别处，这不可能做到。文本最多搜索 100,000 个字符，最多列出 500 个匹配，触及任一上限时面板会说明。