• 正则表达式总结


    一、元字符

    . 匹配除换行符以外的任意字符

    w 匹配单词(字母、数字、下划线、汉字)

    s 匹配任意空白符(空格、制表符tab、换行符、中文全角空格)

    d 匹配数字

     匹配单词的开始或结束,只是一个位置

    ^ 匹配字符串的开始

    $ 匹配字符串的结束

    :单词分界符,匹配一个位置(单词开头或结尾),位置处单词结束空格、标点符等。其实匹配位置为:其前一个字符和后一个字符不全是w。

    eg. hi.*Lucy匹配hi后不远跟一个Lucy。

    *:指定前面的字符可以重复n次匹配。则.*表示任意长连起的字符(不含换行符)。

    eg. (1) 0dd-dddddddd改为0d{2}-d{8},前面的d必须重复匹配2次或8次。

       (2)  aw*:以a开头的单词

       (3)  d+:匹配1个或多个连续数字

       (4)  w{6}:正好6个字符的单词

       (5)  ^d{5,12}$:填写QQ号为5~12位数字

    二、重复

    *  0~n次

    + 1~n次

    ?  0或1次

    {n} 重复n次

    {n,}  n+次

    {n,m} n~m次

    三、字符类

    [0-9]、[A-Z]……

    eg. (1)  [aeiou] 匹配任何一个英文元音字母

       (2)  [A,K,L] 匹配字母A或K或L

       (3)  .(?0d{2}[)-]?d{8} 匹配(0..)-……..例如(010)-12345678

    四、分支条件

    就是“或”的意思,用|分开。正则表达式里的分枝条件指的是有几种规则,如果满足其中任意一种规则都应该当成匹配,具体方法是用|把不同的规则分隔开。

    eg. (1) 0d{2}-d{8}|0d{3}-d{7}能匹配2种:3位区号010-12345678和4位区号0376-2233445.

    (2)  d{5}-d{4}|d{5} 匹配美国的邮政编码。美国邮编的规则是5位数字,或者用连字号间隔的9位数字。之所以要给出这个例子是因为它能说明一个问题:使用分枝条件时,要注意各个条件的顺序。如果你把它改成d{5}|d{5}-d{4}的话,那么就只会匹配5位的邮编(以及9位邮编的前5位)。原因是匹配分枝条件时,将会从左到右地测试每个条件,如果满足了某个分枝的话,就不会去再管其它的条件了。

    五、分组

    重复单个字符就算了,直接加{n},但要重复一串组字母办?用小括号括起来即可。

    eg. (d{1,3}.){3}  d{1,3}匹配1到3位的数字,(d{1,3}.){3}匹配三位数字加上一个英文句号(这个整体也就是这个分组)重复3次,最后再加上一个一到三位的数字(d{1,3})。变成255.124.223.126的IP地址。

    六、反义

    W 匹配任意非单词(非字母、下划线、汉字)

    S 任意非空字符

    D 任意非数字

    B 任意不是单词开头结尾处

    [^x] 除x以外的任意字符

    [^aeiou] 除aeiou以外的任意字符

    eg. (1) S+ 不包含空白符的字符串

       (2)<a[^>]+> 匹配用尖括号括起来以a开头的字符串

    七、后向引用

    匹配这个子表达式文本:从左向右,以分组的左括号为标志,第1个出现为组1(用数字加转移字符写:1),第2个出现为组2(写成2,表示第2组)

    eg. (1) (w+)s+1匹配重复单词,像go go、kitty kitty,匹配单词(w+)之后会被捕获到编号为1的分组中,然后是1个或几个空白符S+,最后是分组1中捕获的内容(即前面匹配那单词)(1)。

       (2)  (?<word>w+)s+k<word>,可以自定义组名(?<word>w+)(?’word’w+)之后后向引用此分组捕获内容,捕获则用k<word>

    于是上述例子亦可写作(?<word>w+)s+k<word>。

    八、零宽断言

    分组

    捕获

    (exp)

    匹配exp并捕获文本到自动命名的组里

    (?<name>exp)

    匹配exp并捕获文本到名称为name的组里

    (?:exp)

    匹配exp但不捕获匹配的文本也不给此分组分配组号

    零宽断言

    (?=exp)

    匹配exp前面的位置

    (?<=exp)

    匹配exp后面的位置

    (?!exp)

    匹配后面跟的不是exp的位置

    (?<!exp)

    匹配前面不是exp的位置

    注释

    (?#commend)

    添加注释用……

    (1) 零宽度正预测先行断言(?=exp)  断言自身出现位置后面能匹配表达式exp

          eg. w+(?=ing)匹配以ing结尾的单词,但除ing以外,比如I’m sing and you’re dancing,匹配为sing和danc。

    (2) 零宽度正回顾后发断言(?<=exp)  断言自身出现位置前面能匹配表达式exp

         eg. (?<=re)w+匹配以re开头的单词的后半部,比如reading a book匹配ading。

    九、负向零宽断言

    确保某个字符是否出现,但是不想去匹配它。

    ……

    十、注释

    (?#command):凡是在注释#内的,包括回车、换行写的都不看。

    断言用来声明一个为真的事实,只有当断言为真时才会继续匹配。

    十一、贪婪与懒惰

    (1) 贪婪:当正则中能包含重复字符时,匹配尽可能多的字符。

    eg.  a.*b匹配最长以a开头,以b结尾的字符串

    (2) 懒惰:匹配尽可能少的字符,在后面加上?,

    eg.  .*?匹配任意数量的重复,但使用最少的重复。

    -------------------------------------------------------------

    *?  重复任意次,但尽可能少

    +?  重复1~n次,但尽可能少

    ??  重复0或1次,但尽可能少

    {n,m}? 重复n~m次,但尽可能少

    {n,}? 重复n+次,但尽可能少

    ------------------------------------------------------------

    举个例子,对于字符串aabab:

    贪婪匹配:a.*b,则匹配为aabab;(这里认为“以b结尾”是以最后一个b结尾)

    懒惰匹配:a.*?b,则匹配为aab和ab;(这里认为“以b结尾”是以第一个碰到的b结尾,在中间就截断了)

    注意优先级   贪婪匹配>懒惰匹配

    十二、如何写出高效率的正则表达式

    如果纯粹是为了挑战自己的正则水平,用来实现一些特效(例如使用正则表达式计算质数、解线性方程),效率不是问题;如果所写的正则表达式只是为了满足一两次、几十次的运行,优化与否区别也不太大。但是,如果所写的正则表达式会百万次、千万次地运行,效率就是很大的问题了。这里总结几条提升正则表达式运行效率的经验。

    先定义两个概念:

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

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

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

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

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

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

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

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

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

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

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


  • 相关阅读:
    (C#基础) byte[] 之初始化, 赋值,转换。
    System.IO.IOException: The handle is invalid.
    .NET 自动内存管理(垃圾收集GC)
    Inconsistent accessibility
    有用的网址
    dw添加emmet
    行内标签,怎么取消两个标签中间的距离
    2016.6.2近日学习计划
    HTML5 input placeholder 颜色修改示例
    加入收藏和设为首页
  • 原文地址:https://www.cnblogs.com/DianaCody/p/5425666.html
Copyright © 2020-2023  润新知