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

104次阅读

共计 4646 个字符,预计需要花费 12 分钟才能阅读完成。

原创:打码日记(微信公众号 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 匹配开始地位
$ \z \Z 匹配完结地位
\b \B 匹配单词与非单词边界地位
\G 匹配以后匹配的开始地位
(?=a) (?!a) 正向环视,看看以后地位前面是否是 a,或不是 a
(?<=a) (?<!a) 逆向环视,看看以后地位后面是否是 a,或不是 a

^ 与 \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 批量操作多台机器

正文完
 0