[think]如何写出高效率的正则表达式


在逛“我爱正则表达式”时看到的一篇文章,写得真好,转载至此,做个备份、记录提醒自己。


如果纯粹是为了挑战自己的正则水平,用来实现一些特效(例如使用正则表达式计算质数、解线性方程),效率不是问题;如果所写的正则表达式只是为了满足一两次、几十次的运行,优化与否区别也不太大。但是,如果所写的正则表达式会百万次、千万次地运行,效率就是很大的问题了。我这里总结了几条提升正则表达式运行效率的经验(工作中学到的,看书学来的,自己的体会),贴在这里。如果您有其它的经验而这里没有提及,欢迎赐教。

为行文方便,先定义两个概念。

误匹配:指正则表达式所匹配的内容范围超出了所需要范围,有些文本明明不符合要求,但是被所写的正则式“击中了”。例如,如果使用\d{11}来匹配11位的手机号,\d{11}不单能匹配正确的手机号,它还会匹配98765432100这样的明显不是手机号的字符串。我们把这样的匹配称之为误匹配。

漏匹配:指正则表达式所匹配的内容所规定的范围太狭窄,有些文本确实是所需要的,但是所写的正则没有将这种情况囊括在内。例如,使用\d{18}来匹配18位的身份证号码,就会漏掉结尾是字母X的情况。

写出一条正则表达式,既可能只出现误匹配(条件写得极宽松,其范围大于目标文本),也可能只出现漏匹配(只描述了目标文本中多种情况种的一种),还可能既有误匹配又有漏匹配。例如,使用\w+\.com来匹配.com结尾的域名,既会误匹配abc_.com这样的字串(合法的域名中不含下划线,\w包含了下划线这种情况),又会漏掉ab-c.com这样的域名(合法域名中可以含中划线,但是\w不匹配中划线)。

精准的正则表达式意味着既无误匹配且无漏匹配。当然,现实中存在这样的情况:只能看到有限数量的文本,根据这些文本写规则,但是这些规则将会用到海量的文本中。这种情况下,尽可能地(如果不是完全地)消除误匹配以及漏匹配,并提升运行效率,就是我们的目标。本文所提出的经验,主要是针对这种情况。

掌握语法细节。正则表达式在各种语言中,其语法大致相同,细节各有千秋。明确所使用语言的正则的语法的细节,是写出正确、高效正则表达式的基础。例如,perl中与\w等效的匹配范围是[a-zA-Z0-9_];perl正则式不支持肯定逆序环视中使用可变的重复(variable repetition inside lookbehind,例如(?<=.*)abc),但是.Net语法是支持这一特性的;又如,JavaScript连逆序环视(Lookbehind,如(?<=ab)c)都不支持,而perl和python是支持的。《精通正则表达式》第3章《正则表达式的特性和流派概览》明确地列出了各大派系正则的异同,这篇文章也简要地列出了几种常用语言、工具中正则的比较。对于具体使用者而言,至少应该详细了解正在使用的那种工作语言里正则的语法细节。

先粗后精,先加后减。使用正则表达式语法对于目标文本进行描述和界定,可以像画素描一样,先大致勾勒出框架,再逐步在局步实现细节。仍举刚才的手机号的例子,先界定\d{11},总不会错;再细化为1[358]\d{9},就向前迈了一大步(至于第二位是不是3、5、8,这里无意深究,只举这样一个例子,说明逐步细化的过程)。这样做的目的是先消除漏匹配(刚开始先尽可能多地匹配,做加法),然后再一点一点地消除误匹配(做减法)。这样有先有后,在考虑时才不易出错,从而向“不误不漏”这个目标迈进。

留有余地。所能看到的文本sample是有限的,而待匹配检验的文本是海量的,暂时不可见的。对于这样的情况,在写正则表达式时要跳出所能见到的文本的圈子,开拓思路,作出“战略性前瞻”。例如,经常收到这样的垃圾短信:“发*票”、“发#漂”。如果要写规则屏蔽这样烦人的垃圾短信,不但要能写出可以匹配当前文本的正则表达式 发[*#](?:票|漂),还要能够想到 发.(?:票|漂|飘)之类可能出现的“变种”。这在具体的领域或许会有针对性的规则,不多言。这样做的目的是消除漏匹配,延长正则表达式的生命周期。

明确。具体说来,就是谨慎用点号这样的元字符,尽可能不用星号和加号这样的任意量词。只要能确定范围的,例如\w,就不要用点号;只要能够预测重复次数的,就不要用任意量词。例如,写析取twitter消息的脚本,假设一条消息的xml正文部分结构是<span class=”msg”>…</span>且正文中无尖括号,那么<span class=”msg”>[^<]{1,480}</span>这种写法的思路要好于<span class=”msg”>.*</span>,原因有二:一是使用[^<],它保证了文本的范围不会超出下一个小于号所在的位置;二是明确长度范围,{1,480},其依据是一条twitter消息大致能的字符长度范围。当然,480这个长度是否正确还可推敲,但是这种思路是值得借鉴的。说得狠一点,“滥用点号、星号和加号是不环保、不负责任的做法”。

不要让稻草压死骆驼。每使用一个普通括号()而不是非捕获型括号(?:…),就会保留一部分内存等着你再次访问。这样的正则表达式、无限次地运行次数,无异于一根根稻草的堆加,终于能将骆驼压死。养成合理使用(?:…)括号的习惯。

宁简勿繁。将一条复杂的正则表达式拆分为两条或多条简单的正则表达式,编程难度会降低,运行效率会提升。例如用来消除行首和行尾空白字符的正则表达式s/^\s+|\s+$//g;,其运行效率理论上要低于s/^\s+//g; s/\s+$//g; 。这个例子出自《精通正则表达式》第五章,书中对它的评论是“它几乎总是最快的,而且显然最容易理解”。既快又容易理解,何乐而不为?工作中我们还有其它的理由要将C==(A|B)这样的正则表达式拆为A和B两条表达式分别执行。例如,虽然A和B这两种情况只要有一种能够击中所需要的文本模式就会成功匹配,但是如果只要有一条子表达式(例如A)会产生误匹配,那么不论其它的子表达式(例如B)效率如何之高,范围如何精准,C的总体精准度也会因A而受到影响。

巧妙定位。有时候,我们需要匹配的the,是作为单词的the(两边有空格),而不是作为单词一部分的t-h-e的有序排列(例如together中的the)。在适当的时候用上^$\b等等定位锚点,能有效提升找到成功匹配、淘汰不成功匹配的效率。

==

原文链接:

笔记:如何写出高效率的正则表达式 | 我爱正则表达式

, ,

《 “[think]如何写出高效率的正则表达式” 》 有 9 条评论

  1. 浅谈正则表达式原理
    http://www.alloyteam.com/2019/07/13574/
    `
    正则表达式可能大部分人都用过,但是大家在使用的时候,有没有想过正则表达式背后的原理,又或者当我告诉你正则表达式可能存在性能问题导致线上挂掉,你会不会觉得特别吃惊?

    我们先来看看7月初,因为一个正则表达式,导致线上事故的例子:’Details of the Cloudflare outage on July 2, 2019′

    简单来说就是一个有性能问题的正则表达式,引起了灾难性回溯,导致cpu满载。

    引起性能问题的关键部分是 .*(?:.*=.*) ,这里我们先不管那个非捕获组,将性能问题的正则看做 .*.*=.* 。
    其中 . 表示匹配除了换行以外的任意字符(很多人把这里搞错,容易出bug), .* 表示贪婪匹配任意字符任意次。

    什么是回溯?
    在使用贪婪匹配或者惰性匹配或者或匹配进入到匹配路径选择的时候,遇到失败的匹配路径,尝试走另外一个匹配路径的这种行为,称作回溯。
    可以理解为走迷宫,一条路走到底,发现无路可走就回到上一个岔路口选择另外的路。

    如何减少或避免回溯?
    · 优化正则表达式:时刻注意回溯造成的性能影响。
    · 使用DFA正则引擎的正则表达式。

    现在回到问题的开头,我们再来看看为什么他的正则会有性能问题:
    · 首先他的正则使用的NFA的正则引擎(大部分语言的正则引擎都是NFA的,js也是,所以要注意性能问题产生的影响)
    他写出了有性能问题的正则表达式,容易造成灾难性回溯。
    · 如果要避免此类的问题,要么提高开发对正则的性能问题的意识,要么改用DFA的正则引擎(速度快,功能弱,没有捕获组断言等功能)。

    注意事项:
    在平常写正则的时候,少写模糊匹配,越精确越好,模糊匹配、贪婪匹配、惰性匹配都会带来回溯问题,选一个影响尽可能小的方式就好。写正则的时候有一个性能问题的概念在脑子里就行。
    `

  2. 正则表达式(Regular Expression)
    http://notes.tanchuanqi.com/tools/regex.html
    `
    正则表达式(Regular Expression)
    精通正则表达式
      第一章:正则表达式入门
      第二章:入门示例拓展
      第三章:正则表达式的特性和流派概览
      第四章:表达式的匹配原理
      第五章:正则表达式实用技巧
      第六章:打造高效的正则表达式
    Python 中的正则表达式
    C++ 中的正则表达式
      regex
      re2
    `

  3. 正则基础之——NFA引擎匹配原理
    https://blog.csdn.net/lxcnn/article/details/4304651

    正则表达式的实现和效率
    http://blog.zhengdong.me/2011/08/20/implementation-and-efficiency-of-regular-expression/

    正则表达式行为的详细信息
    https://docs.microsoft.com/zh-cn/dotnet/standard/base-types/details-of-regular-expression-behavior
    `
    .NET Framework 正则表达式引擎是回溯正则表达式匹配程序,其中包含传统的非确定性有限自动机 (NFA) 引擎(如 Perl、Python、Emacs 和 Tcl 所使用的引擎)。 这使它有别于速度更快、但是限制更多的纯正则表达式确定性有限自动机 (DFA) 引擎(如 awk、egrep 或 lex 中的引擎)。 这也使它有别于标准化、但速度较慢的 POSIX NFA。 下面的部分介绍了正则表达式引擎的三种类型,并解释了为何要在 .NET Framework 中使用传统 NFA 引擎实现正则表达式。
    `

  4. DFA vs NFA engines: What is the difference in their capabilities and limitations?
    https://stackoverflow.com/questions/3978438/dfa-vs-nfa-engines-what-is-the-difference-in-their-capabilities-and-limitations

    Brief intro to NFA, DFA and regexes
    https://shivankaul.com/blog/cstheory/compilers/2017/03/01/nfa-dfa-and-regexes.html

    正则表达式可以既简单又快速
    https://github.com/fooozhe/Regex-Learning/blob/master/regexp1.md

    Regular Expression Matching Can Be Simple And Fast (but is slow in Java, Perl, PHP, Python, Ruby, …)
    https://swtch.com/~rsc/regexp/regexp1.html

  5. 代码之美,正则之道
    https://mp.weixin.qq.com/s/jH6aimCs5LAL5GBe9bu8rg
    `
    导语 “如果罗列计算机软件领域的伟大发明,我相信绝对不会超过二十项,在这个名单当中,当然应该包括分组交换网络,Web,Lisp,哈希算法,UNIX,编译技术,关系模型,面向对象,XML这些大名鼎鼎的家伙,而正则表达式也绝对不应该被漏掉。”– Jeffrey Friedl《精通正则表达式》序言

    本文涉及 js、php、java、python、bash 等语言,共计 1.2w 字,适合前后端同学系统学习正则并熟练掌握正则!

    # 正则引擎
    目前正则引擎有两种, DFA 和 NFA, NFA又可以分为传统型NFA和POSIX NFA.
    DFA Deterministic finite automaton 确定型有穷自动机
    NFA Non-deterministic finite automaton 非确定型有穷自动机
      Traditional NFA
      POSIX NFA

    DFA引擎不支持回溯, 匹配快速, 并且不支持捕获组, 因此也就不支持反向引用. 上述awk, egrep命令均支持 DFA引擎.
    POSIX NFA主要指符合POSIX标准的NFA引擎, 像 javaScript, java, php, python, c#等语言均实现了NFA引擎.

    在学习正则的初级阶段, 重在理解
    ①贪婪与非贪婪模式
    ②分组
    ③捕获性与非捕获性分组
    ④命名分组
    ⑤固化分组, 体会设计的精妙之处.

    而高级阶段, 主要在于熟练运用
    ⑥零宽断言(或环视)解决问题, 并且熟悉正则匹配的原理.

    实际上, 正则在 javaScript 中的功能不算强大, js 仅仅支持了①贪婪与非贪婪模式, ②分组, ③捕获性与非捕获性分组 以及 ⑥零宽断言中的顺序环视. 如果再稍微熟悉些 js 中7种与正则有关的方法(compile, test, exec, match, search, replace, split), 那么处理文本或字符串将游刃有余。
    `

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注