常用的正则表达式全面总结
PS:正则表达式用于字符串处理、表单验证等场合,实用高效。以下表达式本人收集于网络,做了简单整理,以备不时之需。没有全部验证,可能会存在部分错误,读者请自己调试鉴别更正。 匹配中文字符的正则表达式: [u4e00-u9fa5] 匹配双字节字符(包括汉字在内):[^x00-xff] 匹配空白行的正则表达式:ns*r 匹配HTML标记的正则表达式:<(S*?)[^>]*>.*?</1>|<.*? /> 匹配首尾空白字符的正则表达式:^s*|s*$ 匹配Email地址的正则表达式:w+([-+.]w+)*@w+([-.]w+)*.w+([-.]w+)* 匹配网址URL的正则表达式:[a-zA-z]+://[^s]* 匹配帐号是否合法(字母开头,允许5-16字节,允许字母数字下划线):^[a-zA-Z][a-zA-Z0-9_]{4,15}$ 匹配国内电话号码:d{3}-d{8}|d{4}-d{7} 匹配腾讯QQ号:[1-9][0-9]{4,} 匹配中国邮政编码:[1-9]d{5}(?!d) 匹配身份证:d{15}|d{18} 匹配ip地址:d+.d+.d+.d+ 匹配特定数字: 匹配特定字符串: 评注:上面是最基本也是最常用的一些表达式 在使用RegularExpressionValidator验证控件时的验证功能及其验证表达式介绍如下: 只能输入数字:“^[0-9]*$” 只能包含字符、数字和下划线。 正确格式为:“XXXX-XXXXXXX”,“XXXX-XXXXXXXX”,“XXX-XXXXXXX”, “XXX-XXXXXXXX”,“XXXXXXX”,“XXXXXXXX”。 正确格式为:“01”“09”和“1”“31”。 表达式全集正则表达式有多种不同的风格。下表是在PCRE中元字符及其在正则表达式上下文中的行为的一个完整列表(以下少了符号'',详情参考http://my.oschina.net/wizardpisces/blog/118671): 以下是以PHP的语法所写的示例 验证字符串是否只含数字与英文,字符串长度并在4~16个字符之间 <?php$str='a1234';if(preg_match("^[a-zA-Z0-9]{4,16}$",$str)){echo"成功";}else{echo"失敗";}?> 简易的台湾身份证字号验证 <?php$str='a1234';if(preg_match("/^w[12]d{8}$/",$str)){echo"成功";}else{echo"失敗";}?> 以下示例是用 Perl 语言写的,与上面的示例功能相同 print$str="a1234"=~m:^[a-zA-Z0-9]{4,16}$:?"COMFIRM":"FAILED"; print$str="a1234"=~m"^w[12]d{8}$"?"COMFIRM":"INVAILD"; 如何写出高效率的正则表达式如果纯粹是为了挑战自己的正则水平,用来实现一些特效(例如使用正则表达式计算质数、解线性方程),效率不是问题;如果所写的正则表达式只是为了满足一两次、几十次的运行,优化与否区别也不太大。但是,如果所写的正则表达式会百万次、千万次地运行,效率就是很大的问题了。我这里总结了几条提升正则表达式运行效率的经验(工作中学到的,看书学来的,自己的体会),贴在这里。如果您有其它的经验而这里没有提及,欢迎赐教。 为行文方便,先定义两个概念。 误匹配:指正则表达式所匹配的内容范围超出了所需要范围,有些文本明明不符合要求,但是被所写的正则式“击中了”。例如,如果使用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这个长度是否正确还可推敲,但是这种思路是值得借鉴的。说得狠一点,“滥用点号、星号和加号是不环保、不负责任的做法”。 (编辑:安卓应用网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |