|
说明正则表达式通常用于两种任务验证搜索/替换用于验证时通常需要在前后分别加上^和$以匹配整个待验证字符串;搜索/替换时是否加上此限定则根据搜索的要求而定此外也有可能要在前后加上b而不是^和$此表所列的常用正则表达式除个别外均未在前后加上任何限定请根据需要自行处理 正则表达式(英文Regular Expression)在计算机科学中是指一个用来描述或者匹配一系列符合某个句法规则的字符串的单个字符串 | 说明 | 正则表达式 | 网址（URL） [azAz]+://[^s]* IP地址(IP Address) (([]d|[]|[]?dd?)){}([]d|[]|[]?dd?) 电子邮件(Email) w+([+]w+)*@w+([]w+)*w+([]w+)* QQ号码 []d{} HTML标记(包含内容或自闭合) <(*)(*)>*</>|<(*) /> 密码(由数字/大写字母/小写字母/标点符号组成四种都必有位以上) (?=^{}$)(?=*d)(?=*W+)(?=*[AZ])(?=*[az])(?!*n)*$ 日期(年月日) (d{}|d{})((?([]))|([|]))((?[])|([]([]))|([|])) 日期(月/日/年) ((?[]{})|([|]))/(?[]|([][])|([|]))/(d{}|d{}) 时间(小时:分钟 小时制) ((|?)[]|[]):([][]) 汉字(字符) [ueufa] 中文及全角标点符号(字符) [uueufeufeufeufeufeufebuffuffee] 中国大陆固定电话号码 (d{}|d{})?(d{}|d{}) 中国大陆手机号码 d{} 中国大陆邮政编码 []d{} 中国大陆身份证号(位或位) d{}(dd[xX])? 非负整数(正整数或零) d+ 正整数 []*[][]* 负整数 []*[][]* 整数 ?d+ 小数 (?d+)(d+)? 以上正则表达式均经过多次测试并不断增加因为不同程序或工具的正则表达式略有区别大家可以根据需要进行简单修改 常用正则表达式 正则表达式用于字符串处理表单验证等场合实用高效现将一些常用的表达式收集于此以备不时之需 用户名/^[az_]{}$/ 密码/^[az_]{}$/ 十六进制值/^#?([af]{}|[af]{})$/ 电子邮箱/^([az_]+)@([daz]+)([az]{})$/ URL/^(https?://)?([daz]+)([az]{})([/w ]*)*/?$/ IP 地址/^(?:(?:[]|[][]|[]?[][]?)){}(?:[]|[][]|[]?[][]?)$/ HTML 标签/^<([az]+)([^<]+)*(?:>(*)</>|s+/>)$/ Unicode编码中的汉字范围/^[ueufa]{}$/ 匹配中文字符的正则表达式 [ueufa] 评注匹配中文还真是个头疼的事有了这个表达式就好办了 匹配双字节字符(包括汉字在内)[^xxff] 评注可以用来计算字符串的长度(一个双字节字符长度计ASCII字符计) 匹配空白行的正则表达式ns*r 评注可以用来删除空白行 匹配HTML标记的正则表达式<(S*?)[^>]*>*?|<*? /> 评注网上流传的版本太糟糕上面这个也仅仅能匹配部分对于复杂的嵌套标记依旧无能为力 匹配首尾空白字符的正则表达式^s*|s*$ 评注可以用来删除行首行尾的空白字符(包括空格制表符换页符等等)非常有用的表达式 匹配Email地址的正则表达式w+([+]w+)*@w+([]w+)*w+([]w+)* 评注表单验证时很实用 匹配网址URL的正则表达式[azAz]+://[^s]* 评注网上流传的版本功能很有限上面这个基本可以满足需求 匹配帐号是否合法(字母开头允许字节允许字母数字下划线)^[azAZ][azAZ_]{}$ 评注表单验证时很实用 匹配国内电话号码d{}d{}|d{}d{} 评注匹配形式如 或 匹配腾讯QQ号[][]{} 评注腾讯QQ号从开始 匹配中国大陆邮政编码[]d{}(?!d) 评注中国大陆邮政编码为位数字 匹配身份证d{}|d{} 评注中国大陆的身份证为位或位 匹配ip地址d+d+d+d+ 评注提取ip地址时有用 匹配特定数字 ^[]d*$ //匹配正整数 ^[]d*$ //匹配负整数 ^?[]d*$ //匹配整数 ^[]d*|$ //匹配非负整数(正整数 + ) ^[]d*|$ //匹配非正整数(负整数 + ) ^[]d*d*|d*[]d*$ //匹配正浮点数 ^([]d*d*|d*[]d*)$ //匹配负浮点数 ^?([]d*d*|d*[]d*|?+|)$ //匹配浮点数 ^[]d*d*|d*[]d*|?+|$ //匹配非负浮点数(正浮点数 + ) ^(([]d*d*|d*[]d*))|?+|$//匹配非正浮点数(负浮点数 + ) 评注处理大量数据时有用具体应用时注意修正 匹配特定字符串 ^[AZaz]+$//匹配由个英文字母组成的字符串 ^[AZ]+$//匹配由个英文字母的大写组成的字符串 ^[az]+$//匹配由个英文字母的小写组成的字符串 ^[AZaz]+$//匹配由数字和个英文字母组成的字符串 ^w+$//匹配由数字个英文字母或者下划线组成的字符串 表达式全集 正则表达式有多种不同的风格下表是在PCRE中元字符及其在正则表达式上下文中的行为的一个完整列表 | 字符 | 描述 | | 将下一个字符标记为一个特殊字符或一个原义字符或一个向后引用或一个八进制转义符例如“n”匹配字符“n”“n”匹配一个换行符序列“”匹配“”而“(”则匹配“(” ^ | 匹配输入字符串的开始位置如果设置了RegExp对象的Multiline属性^也匹配“n”或“r”之后的位置 $ | 匹配输入字符串的结束位置如果设置了RegExp对象的Multiline属性$也匹配“n”或“r”之前的位置 * | 匹配前面的子表达式零次或多次例如zo*能匹配“z”以及“zoo”*等价于{} + | 匹配前面的子表达式一次或多次例如“zo+”能匹配“zo”以及“zoo”但不能匹配“z”+等价于{} ? | 匹配前面的子表达式零次或一次例如“do(es)?”可以匹配“do”或“does”中的“do”?等价于{} {n} | n是一个非负整数匹配确定的n次例如“o{}”不能匹配“Bob”中的“o”但是能匹配“food”中的两个o {n} | n是一个非负整数至少匹配n次例如“o{}”不能匹配“Bob”中的“o”但能匹配“foooood”中的所有o“o{}”等价于“o+”“o{}”则等价于“o*” {nm} | m和n均为非负整数其中n<=m最少匹配n次且最多匹配m次例如“o{}”将匹配“fooooood”中的前三个o“o{}”等价于“o?”请注意在逗号和两个数之间不能有空格 ? | 当该字符紧跟在任何一个其他限制符（*+?{n}{n}{nm}）后面时匹配模式是非贪婪的非贪婪模式尽可能少的匹配所搜索的字符串而默认的贪婪模式则尽可能多的匹配所搜索的字符串例如对于字符串“oooo”“o+?”将匹配单个“o”而“o+”将匹配所有“o” | 匹配除“n”之外的任何单个字符要匹配包括“n”在内的任何字符请使用像“[n]”的模式 (pattern) | 匹配pattern并获取这一匹配所获取的匹配可以从产生的Matches集合得到在VBScript中使用SubMatches集合在JScript中则使用$…$属性要匹配圆括号字符请使用“(”或“)” (?:pattern) | 匹配pattern但不获取匹配结果也就是说这是一个非获取匹配不进行存储供以后使用这在使用或字符“(|)”来组合一个模式的各个部分是很有用例如“industr(?:y|ies)”就是一个比“industry|industries”更简略的表达式 (?=pattern) | 正向预查在任何匹配pattern的字符串开始处匹配查找字符串这是一个非获取匹配也就是说该匹配不需要获取供以后使用例如“Windows(?=||NT|)”能匹配“Windows”中的“Windows”但不能匹配“Windows”中的“Windows”预查不消耗字符也就是说在一个匹配发生后在最后一次匹配之后立即开始下一次匹配的搜索而不是从包含预查的字符之后开始 (?!pattern) | 负向预查在任何不匹配pattern的字符串开始处匹配查找字符串这是一个非获取匹配也就是说该匹配不需要获取供以后使用例如“Windows(?!||NT|)”能匹配“Windows”中的“Windows”但不能匹配“Windows”中的“Windows”预查不消耗字符也就是说在一个匹配发生后在最后一次匹配之后立即开始下一次匹配的搜索而不是从包含预查的字符之后开始 x|y | 匹配x或y例如“z|food”能匹配“z”或“food”“(z|f)ood”则匹配“zood”或“food” [xyz] | 字符集合匹配所包含的任意一个字符例如“[abc]”可以匹配“plain”中的“a” [^xyz] | 负值字符集合匹配未包含的任意字符例如“[^abc]”可以匹配“plain”中的“p” [az] | 字符范围匹配指定范围内的任意字符例如“[az]”可以匹配“a”到“z”范围内的任意小写字母字符 [^az] | 负值字符范围匹配任何不在指定范围内的任意字符例如“[^az]”可以匹配任何不在“a”到“z”范围内的任意字符 b | 匹配一个单词边界也就是指单词和空格间的位置例如“erb”可以匹配“never”中的“er”但不能匹配“verb”中的“er” B | 匹配非单词边界“erB”能匹配“verb”中的“er”但不能匹配“never”中的“er” cx | 匹配由x指明的控制字符例如cM匹配一个ControlM或回车符x的值必须为AZ或az之一否则将c视为一个原义的“c”字符 d | 匹配一个数字字符等价于[] D | 匹配一个非数字字符等价于[^] f | 匹配一个换页符等价于xc和cL n | 匹配一个换行符等价于xa和cJ r | 匹配一个回车符等价于xd和cM s | 匹配任何空白字符包括空格制表符换页符等等等价于[fnrtv] S | 匹配任何非空白字符等价于[^fnrtv] t | 匹配一个制表符等价于x和cI v | 匹配一个垂直制表符等价于xb和cK w | 匹配包括下划线的任何单词字符等价于“[AZaz_]” W | 匹配任何非单词字符等价于“[^AZaz_]” xn | 匹配n其中n为十六进制转义值十六进制转义值必须为确定的两个数字长例如“x”匹配“A”“x”则等价于“x&”正则表达式中可以使用ASCII编码 num | 匹配num其中num是一个正整数对所获取的匹配的引用例如“()”匹配两个连续的相同字符 n | 标识一个八进制转义值或一个向后引用如果n之前至少n个获取的子表达式则n为向后引用否则如果n为八进制数字（）则n为一个八进制转义值 nm | 标识一个八进制转义值或一个向后引用如果nm之前至少有nm个获得子表达式则nm为向后引用如果nm之前至少有n个获取则n为一个后跟文字m的向后引用如果前面的条件都不满足若n和m均为八进制数字（）则nm将匹配八进制转义值nm nml | 如果n为八进制数字（）且m和l均为八进制数字（）则匹配八进制转义值nml un | 匹配n其中n是一个用四个十六进制数字表示的Unicode字符例如uA匹配版权符号（?） 以下是以PHP的语法所写的示例
验证字符串是否只含数字与英文字符串长度并在~个字符之间
$str = 'a1234';
if (preg_match("^[a-zA-Z0-9]{4,16}$", $str)) {
echo "验证成功";
} else {
echo "验证失败";
}
?>
简易的台湾身份证字号验证
$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";
如何写出高效率的正则表达式
如果纯粹是为了挑战自己的正则水平，用来实现一些特效(例如使用正则表达式计算质数、解线性方程)，效率不是问题;如果所写的正则表达式只是为了满足一两次、几十次的运行，优化与否区别也不太大。TW.WinGwiT.Com但是，如果所写的正则表达式会百万次、千万次地运行，效率就是很大的问题了。我这里总结了几条提升正则表达式运行效率的经验(工作中学到的，看书学来的，自己的体会)，贴在这里。如果您有其它的经验而这里没有提及，欢迎赐教。
为行文方便，先定义两个概念。
误匹配：指正则表达式所匹配的内容范围超出了所需要范围，有些文本明明不符合要求，但是被所写的正则式“击中了”。例如，如果使用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正文部分结构是…且正文中无尖括号，那么[^<]{1,480}这种写法的思路要好于.*，原因有二：一是使用[^<]，它保证了文本的范围不会超出下一个小于号所在的位置;二是明确长度范围，{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等等定位锚点，能有效提升找到成功匹配、淘汰不成功匹配的效率。
