正则测试

Q: 命名分组在输出里是什么样的？

它们在分组那一列以对象形式出现，替换时可以用 $ 引用。像 (? \d{4}) 这样的表达式会让年份以这个名字而不是编号来使用。

正则表达式试一遍比想清楚更快，而且在与代码同一个引擎里试很关键——本页用的就是你浏览器自带的 JavaScript 正则引擎，所以在这里匹配的，在你的脚本里也匹配。每一处匹配都会在文本中高亮，并连同它的位置和捕获的分组一起列出；你还可以先预览带 $1 这类引用的替换结果，再决定是否采用。用来测试的往往是真实数据，所以值得再说一次：粘贴的内容不会离开这个页面。

如何测试正则表达式

输入表达式。照你写在斜杠里面的样子写就行——斜杠和标志由工具补上。
按需要开关标志：i 忽略大小写，m 让 ^ 和 $ 按行工作，s 让点号也匹配换行，u 启用 Unicode 模式。
在下面粘贴要检索的文本。匹配会随你输入高亮，表格会列出每一处的起始位置和捕获内容。
打开「显示替换」来试替换。用 $1、$2 引用编号分组，用
lt;名称> 引用命名分组。

关于测试正则表达式的常见问题

这是哪一种正则方言？

JavaScript 的，因为跑这条表达式的正是你浏览器自己的引擎。日常使用上它接近 PCRE，但后行断言、命名分组和 Unicode 属性转义各有自己的支持历程，而 PCRE 允许的递归、占有量词在这里根本不存在。

我用来测试的文本会被上传吗？

不会。表达式在页面内运行，针对的文本也从不离开页面。当你拿一段日志摘录或一条客户记录来测试时，这一点值得知道。

为什么文本长度有上限？

因为某些表达式会灾难性回溯——嵌套量词碰上不合适的输入会花费指数级的时间——而浏览器无法在正则开始后中断它。给输入设上限，能让糟糕的表达式向你暴露问题，而不是冻住整个标签页。

为什么在 1,000 处就停下？

因为渲染几万处高亮会让页面无法使用，却不会多告诉你什么。达到上限时会在结果上方说明，你就知道这份列表并不完整。

命名分组在输出里是什么样的？

它们在分组那一列以对象形式出现，替换时可以用

lt;名称> 引用。像 (?<year>\d{4}) 这样的表达式会让年份以这个名字而不是编号来使用。