关于正则表达式:正则表达式技巧与注意事项

原创：打码日记（微信公众号 ID：codelogs），欢送分享，转载请保留出处。

简介

现如今，正则表达式简直是程序员的必备技能了，它动手的确很容易，但如果你不认真推敲学习，会长期停留在正则最根本的用法层面上。
因而，本篇文章，我会介绍一些能用正则解决的场景，但这些场景如果全本人推敲实现的话，须要花一些工夫能力实现，或者就齐全想不进去，另外也会介绍一些正则表达式的性能问题。

匹配多个单词

比方我想匹配 zhangsan、lisi、wangwu 这三个人名，这是一个很常见的场景，其实在正则外面也算基本功，但鉴于自己初入门时还是在网上搜寻失去的答案，还是值得提一下的！
实现如下：

zhangsan|lisi|wangwu

其中 | 示意或的含意，就是匹配 zhangsan 或 lisi 或 wangwu 了。

匹配反复数字

匹配如 1111、2222、3333 这样的 4 位长度的反复数字，突一想，这不必 \d{4} 就解决了嚒，其实不然，因为 \d{4} 能够匹配 1111，但也能够匹配 1234 啊。
写法如下：

(\d)\1{3}

\d 匹配第一个数字，前面的 \1 匹配后面 \d 匹配的内容，反复 3 次，这样就能够匹配 1111 或 2222 这样的 4 位数字串了。

匹配各种空白

在应用正则时，罕用 \s 来匹配空白，但遗憾的是，还是有一些 Unicode 的空白字符，\s无奈匹配，这时能够尝试 POSIX 字符类\p{Space}，我在 Java 中验证通过，能够匹配 ascii 空白字符与 Unicode 空白字符，如果是其它语言的话，可能正则语法会稍有区别。

地位匹配

正则表达式中 \G 与环视是比拟难了解的，因为这两个货色很多书上只是介绍了匹配的规定，没有说出本质，导致死记的规定过一段时间就忘，也不明确这两货色有啥用。
咱们转换一下思维，其实在正则表达式中，匹配指标只有两个，一是匹配字符串中的字符，二是匹配字符串中的地位，如下图：

上边的 hello，有 5 个字符能够匹配，另外还有 6 个地位能够匹配，而 ^hello 中^就是代表匹配结尾的地位，所以如果是 _hello 就无奈被 ^hello 匹配，因为 _ 与h之间的地位并不是结尾，不能与 ^ 匹配！

常见地位匹配规定

^ 与 \A
^ 匹配文本开始地位，但在多行匹配模式下，^ 匹配每一行的开始地位。
\A 仅仅只能匹配开始地位，不论什么匹配模式下

$ 与 \Z

$ 匹配文本开端地位，但在多行匹配模式下，$ 匹配每一行的开端地位。
\Z 仅仅只能匹配开端地位，不论什么匹配模式下

\b 与 \B
\b 匹配单词边界，在 Java 中，单词边界即是字母与非字母之间的地位，中文不认为是单词，另外文本结尾与文本结尾也是单词边界
\B 匹配非单词边界

\G
匹配上次匹配的完结地位或以后匹配的开始地位，第一次匹配时，匹配文本开始地位，如下：
从 1234a5678 中找单个数字，如果用 \d 去找，能够找到 8 个，但应用 \G\d 去找，却只能找到 4 个
查找过程：
第 1 次查找，\G 匹配文本开始地位，1 与 \d 匹配，找到第 1 个匹配，即 1
第 2 次查找，\G 匹配 1 前面 2 后面之间的地位，2 与 \d 匹配，找到第 2 个匹配，即 2
第 3 次查找，\G 匹配 2 前面 3 后面之间的地位，3 与 \d 匹配，找到第 3 个匹配，即 3
第 4 次查找，\G 匹配 3 前面 4 后面之间的地位，4 与 \d 匹配，找到第 4 个匹配，即 4
第 5 次查问，\G 匹配 4 前面 5 后面之间的地位，但 a 与 \d 不匹配，匹配完结，总共找到 4 个匹配。

环视
(?=a) 与 (?!a)
正向必定 (否定) 环视，用来检测以后地位前面字符是否是 a，或不是 a
(?<=a) 与 (?<!a)
逆向必定 (否定) 环视，用来查看以后地位后面字符是否是 a，或不是 a
如下，查找被 () 包裹的单词，应用环视限定单词右边是(，左边是)

地位可被屡次匹配
文本中的一个地位，能够同时匹配多个规定，且与规定在正则表达式中的先后顺序无关，例如上面 3 个正则表达式是等价的：

^abc
^^^^^^abc
^(?=a)\b^^^abc

上面举两个理论例子领会一下地位匹配！

例 1：明码强度校验
前端校验明码强度时，常常有这样的要求，长度 8 到 10 位，且必须蕴含数字、字母、标点符号，可通过一个正则表达式校验进去，如下：

^(?=.*[0-9])(?=.*[a-zA-Z])(?=.*\p{P}).{8,10}$

其中，(?=.*[0-9])示意结尾地位的前面肯定要有数字，(?=.*[a-zA-Z])示意结尾地位前面肯定要有字母，(?=.*\p{P})示意结尾地位的前面肯定要有标点符号，.{8,10}示意匹配 8 到 10 位字符，这几个正则合在一起，就实现了校验明码强度的要求。

例 2：千分位数字
有时咱们须要将 123456789 变成 123,456,789 这样的千分位数字，这个应用正则就能够实现，如下，将此正则匹配到的地位，替换为,：

(?!^)(?=(\d{3})+$)

其中，(?=(\d{3})+$)示意匹配地位，这个地位前面必须要有一组或多组 3 个数字，满足这样条件的地位有 3 个，结尾与 1 之间的地位，3 和 4 之间的地位，6 和 7 之间的地位，而后 (?!^) 又限度了同样的这些地位，不能是结尾，就只能 3 和 4，6 和 7 之间的地位满足要求了，所以替换之后，就变成了123,456,789。

匹配带引号字符串

匹配诸如 "hello,world" 这样的带引号的字符串，很容易想到，用 "[^"]+" 即可，然而如果引号字符串外面容许用 \ 来本义 " 呢，如 "hello \"bob\"!"，如果用"[^"]+" 来匹配的话，就只会匹配到 "hello \" 了，显然不对，能够先自行想想如何用正则实现。
…
…
…
想不进去？咱们能够换一个视角，蕴含带 \ 结尾转义字符的字符串，其实能够拆解为",hello ,\"bob,\"!,"，而后再泛化为正则模式，",[^\\"]*,\\.[^\\"]*,\\.[^\\"]*,"，组合在一起如下：

"[^\\"]*(?:\\.[^\\"]*)*"

表达式中多了个 (?:)，这示意非捕捉分组，能够用来进步正则匹配性能，而因为字符串中有可能没有\ 结尾的转义字符，故 (?:\\.[^\\"]*) 前面是 *，间接由[^\\"]* 匹配完引号内所有内容。

别搞炸了 CPU

正则表达式如果写得很简单，就须要审慎评估了，因为有可能平时运行得好好的，但遇到一些非凡状况，会导致 CPU 间接 100%，比方还是下面那个匹配带引号字符串的场景，有同学可能会给出这样的正则：

"([^\\"]+|\\.)*"

乍一看，这个正则很完满，[^\\"]+匹配非转义字符的局部，\\.匹配 \"，\n 之类的。这个正则在遇到满足条件的字符串时齐全没有问题 (如"hello \"bob\"!")，而遇到不满足条件的字符串时，正则匹配复杂度会随着字符串长度呈指数式回升，导致 CPU 100%，如"hello \"bob\"!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!，其中" 没有闭合。

public static void main(String[] args) {long begin = System.currentTimeMillis();
    boolean isMatch = "\"hello \\\"bob\\\"!!!!!!!!!!!!!!!!!!".matches("\"([^\\\\\"]+|\\\\.)*\"");
    System.out.println(String.format("%s ms, isMatch: %s", System.currentTimeMillis() - begin, isMatch));
}

这段 java 代码，在我机器上跑完要 2s 的样子，但如果字符串中再加 4 个!，运行工夫立马回升到 17s，性能降落十分恐怖！

起因
如果晓得一些正则匹配原理，应该晓得正则在匹配时，如果匹配不上，会将曾经匹配的字符吐出来，再看看是否可能匹配，这叫回溯，比方 ".*" 匹配 "hello"，先正则中的" 匹配上了字符串中的 "，而后.* 顺次匹配了 h,e,l,l,o,"，最初正则中的" 匹配字符串结尾地位，匹配不上，这时正则引擎会让后面的 .* 吐出它匹配的 "，而后吐出来的这个"，刚好能够和正则中的" 匹配，这样就匹配胜利了。

那如果是 "hello 这样没有闭合的字符串，.*会始终吐字符，始终到它没有字符可吐，发现还是匹配不上，这样整个匹配才认定为匹配失败。

是的，正则中蕴含匹配量词 ?,*,+ 时，你就能够想像为它们始终在吃字符，当前面的规定匹配不上时，会强制它又吐出来，而如果是懈怠匹配量词??,*?,+?，你就能够想像它先不吃，当前面的规定匹配不上时，会强制它去吃。

咱们再来剖析下 "([^\\"]+|\\.)*" 匹配 "!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 为啥会如此低效！
注：为了剖析不便，我简化了待匹配字符串，但成果是一样的

1. 首先 [^\\"]+ 吃掉了!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!。
2. 而后发现正则中 " 与字符串结尾地位不匹配，开始回溯。
3. 而后 [^\\"]+ 吐出一个 !，留神这里，因为外层还有一个* 贪心量词，吐出来的 ! 又被 [^\\"]+|\\. 中的 [^\\"]+ 吃掉了，它吃掉后，到了字符串结尾，发现结尾又与正则中的 " 不匹配，又要求 [^\\"]+|\\. 中的 [^\\"]+ 吐出刚吃掉的!，后果吐出后又不匹配。
4. 而后又逼着最后面的那个 [^\\"]+ 吐出倒数第二个 !，留神，再次吐出! 后，以后匹配地位前面有两个 !，可恶的是，这两个! 又被前面 [^\\"]+|\\. 中的 [^\\"]+ 吃掉了，而后悲剧重演，它又要吐出来，如此周而复始，计算量指数级回升。

解决办法
其实能够看进去，造成这个问题是因为正则表达式中有两个量词，内层有一个 +，外层有一个*，不信的话，你能够尝试用^(a+)*$ 去匹配 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0，同样的会十分慢。
而要解决这个问题，有两个方法。

1. 让 [^\\"]+ 吐出来的字符，无奈被外层正则中另一个贪心的本人吃掉，比方后面介绍的 "[^\\"]*(?:\\.[^\\"]*)*"，[^\\"]* 吐出来的字符，是无奈被 \\.[^\\"]* 吃掉的，因为吐出来的肯定不是 \，而\\.[^\\"]* 要先吃一个\。
2. 明晓得本人吐出来的字符后，前面的规定也无奈匹配，那就让量词吃掉字符后不吐，比方将正则批改为 "([^\\"]++|\\.)*" 这样，+变成了 ++，像这种量词前面再加+ 号的，比方?+,*+,++，这示意占有量词，吃完字符后就不会吐了。

注：占有量词不要乱用，有时吐出来字符能够让整个正则匹配，而你强制让它不吐出来，反而让它匹配不了了，如 ^.+b$ 能够匹配 ab，但如果你用 ^.++b$ 就无奈匹配 ab 了，因为 . 吃掉了 ab，吐出一个 b 刚好能够使前面的b 匹配。而 ^[^b]++b$ 这种用法就是对的，因为 ^b 吐出来的字符必定不能和前面的 b 匹配，就没必要再吐了。

总结

正则表达式很弱小，用好它事倍功半，但也须要理解它的执行过程，防止指数级回溯陷阱。

往期内容

好用的 parallel 命令
还在胡乱设置连贯闲暇工夫？
罕用网络命令总结
应用 socat 批量操作多台机器