入门\b是正则表达式规定的一个特殊代码(好吧,某些人叫它元字符,metacharacter),代表着单词的开头或结尾,也就是单词的分界处。虽然通常英文的单词是由空格,标点符号或者换行来分隔的,但是\b并不匹配这些单词分隔字符中的任何一个,它只匹配一个位置。 如果需要更精确的说法,\b匹配这样的位置:它的前一个字符和后一个字符不全是(一个是,一个不是或不存在)\w。 假如你要找的是hi后面不远处跟着一个Lucy,你应该用\bhi\b.*\bLucy\b。若要匹配"A B",则使用A\sB或者A\b\s\bB等。表达式 ".\b." 在匹配 "@@@abc" 时,匹配结果是:成功;匹配到的内容是:"@a";匹配到的位置是:开始于2,结束于4。表达式"\bend\b" 在匹配 "weekend,endfor,end" 时,匹配结果是:成功;匹配到的内容是:"end";匹配到的位置是:开始于15,结束于18。 这里,.是另一个元字符,匹配除了换行符以外的任意字符。*同样是元字符,不过它代表的不是字符,也不是位置,而是数量——它指定*前边的内容可以连续重复使用任意次以使整个表达式得到匹配。因此,.*连在一起就意味着任意数量的不包含换行的字符。?匹配重复零次或一次。 元字符\s匹配任意的空白符,包括空格,制表符(Tab),换行符,中文全角空格等。\w匹配字母或数字或下划线或汉字等。 对中文/汉字的特殊处理是由.Net提供的正则表达式引擎支持的,其它环境下的具体情况请查看相关文档。 和忽略大小写的选项类似,有些正则表达式处理工具还有一个处理多行的选项。如果选中了这个选项,^和$的意义就变成了匹配行的开始处和结束处。 分枝条件
\(?0\d{2}[) -]?\d{8}。 “(”和“)”也是元字符,后面的分组节里会提到,所以在这里需要使用转义。 这个表达式可以匹配几种格式的电话号码,像(010)88886666,或022-22334455,或02912345678等。
不幸的是,刚才那个表达式也能匹配010)12345678或(022-87654321这样的“不正确”的格式。要解决这个问题,我们需要用到分枝条件。正则表达式里的分枝条件指的是有几种规则,如果满足其中任意一种规则都应该当成匹配,具体方法是用|把不同的规则分隔开。听不明白?没关系,看例子: 0\d{2}-\d{8}|0\d{3}-\d{7}这个表达式能匹配两种以连字号分隔的电话号码:一种是三位区号,8位本地号(如010-12345678),一种是4位区号,7位本地号(0376-2233445)。 \(?0\d{2}\)?[- ]?\d{8}|0\d{2}[- ]?\d{8}这个表达式匹配3位区号的电话号码,其中区号可以用小括号括起来,也可以不用,区号与本地号间可以用连字号或空格间隔,也可以没有间隔。你可以试试用分枝条件把这个表达式扩展成也支持4位区号的。 \d{5}-\d{4}|\d{5}这个表达式用于匹配美国的邮政编码。美国邮编的规则是5位数字,或者用连字号间隔的9位数字。之所以要给出这个例子是因为它能说明一个问题:使用分枝条件时,要注意各个条件的顺序。如果你把它改成\d{5}|\d{5}-\d{4}的话,那么就只会匹配5位的邮编(以及9位邮编的前5位)。原因是匹配分枝条件时,将会从左到右地测试每个条件,如果满足了某个分枝的话,就不会去再管其它的条件了。 反义
例:<a[^>]+>匹配用尖括号括起来的以a开头的字符串。 分组与后向引用可以用小括号来指定子表达式(也叫做分组),然后你就可以指定这个子表达式的重复次数了。例如:描述一个正确的IP地址:((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)。 使用小括号指定一个子表达式后,匹配这个子表达式的文本(也就是此分组捕获的内容)可以在表达式或其它程序中作进一步的处理。默认情况下,每个分组会自动拥有一个组号,分组0对应整个正则表达式。后向引用用于重复搜索前面某个分组匹配的文本。例如,\1代表分组1匹配的文本。\b(\w+)\b\s+\1\b可以用来匹配重复的单词,像go go, 或者kitty kitty。 实际上组号分配过程是要从左向右扫描两遍的:第一遍只给未命名组分配,第二遍只给命名组分配--因此所有命名组的组号都大于未命名的组号,你可以使用(?:exp)这样的语法来剥夺一个分组对组号分配的参与权。 你也可以自己指定子表达式的组名。(?<Word>\w+)(或者把尖括号换成'也行:(?'Word'\w+)),这样就把\w+的组名指定为Word了。要反向引用这个分组捕获的内容,你可以使用\k<Word>,所以上一个例子也可以写成这样:\b(?<Word>\w+)\b\s+\k<Word>\b。 使用小括号的时候,还有很多特定用途的语法。下面列出了最常用的一些:
零宽断言断言用来声明一个应该为真的事实。正则表达式中只有当断言为真时才会继续进行匹配。接下来的四个用于查找在某些内容(但并不包括这些内容)之前或之后的东西,也就是说它们像\b,^,$那样用于指定一个位置,这个位置应该满足一定的条件(即断言),因此它们也被称为零宽断言。 (?=exp)也叫零宽度正预测先行断言,它断言自身出现的位置的后面能匹配表达式exp。比如\b\w+(?=ing\b),匹配以ing结尾的单词的前面部分(除了ing以外的部分),如查找I'm singing while you're dancing.时,它会匹配sing和danc。\b(?=\w{7}\b)\w*clip\w*\b,匹配包含clip的七个字符的单词。 (?<=exp)也叫零宽度正回顾后发断言,它断言自身出现的位置的前面能匹配表达式exp。比如(?<=\bre)\w+\b会匹配以re开头的单词的后半部分(除了re以外的部分),例如在查找reading a book时,它匹配ading。 假如你想要给一个很长的数字中每三位间加一个逗号(当然是从右边加起了),你可以这样查找需要在前面和里面添加逗号的部分:((?<=\d)\d{3})+\b,用它对1234567890进行查找时结果是234567890。 下面的例子同时使用了这两种断言:(?<=\s)\d+(?=\s)匹配以空白符间隔的数字(再次强调,不包括这些空白符)。 ^(?![0-9]+$)(?![a-zA-Z]+$)[0-9A-Za-z]$ 匹配 由数字和字母组成的字符串,不能全是字母或数字。 负向零宽断言前面我们提到过怎么查找不是某个字符或不在某个字符类里的字符的方法(反义)。但是如果我们只是想要确保某个字符没有出现,但并不想去匹配它时怎么办?例如,如果我们想查找这样的单词--它里面出现了字母q,但是q后面跟的不是字母u,我们可以尝试这样: \b\w*q[^u]\w*\b匹配包含后面不是字母u的字母q的单词。但是如果多做测试(或者你思维足够敏锐,直接就观察出来了),你会发现,如果q出现在单词的结尾的话,像Iraq,Benq,这个表达式就会出错。这是因为[^u]总要匹配一个字符,所以如果q是单词的最后一个字符的话,后面的[^u]将会匹配q后面的单词分隔符(可能是空格,或者是句号或其它的什么),后面的\w*\b将会匹配下一个单词,于是\b\w*q[^u]\w*\b就能匹配整个Iraq fighting。负向零宽断言能解决这样的问题,因为它只匹配一个位置,并不消费任何字符。现在,我们可以这样来解决这个问题:\b\w*q(?!u)\w*\b。 零宽度负预测先行断言(?!exp),断言此位置的后面不能匹配表达式exp。例如:\d{3}(?!\d)匹配三位数字,而且这三位数字的后面不能是数字;\b((?!abc)\w)+\b匹配不包含连续字符串abc的单词。 同理,我们可以用(?<!exp),零宽度负回顾后发断言来断言此位置的前面不能匹配表达式exp:(?<![a-z])\d{7}匹配前面不是小写字母的七位数字。 请详细分析表达式(?<=<(\w+)>).*(?=<\/\1>),这个表达式最能表现零宽断言的真正用途。 一个更复杂的例子:(?<=<(\w+)>).*(?=<\/\1>)匹配不包含属性的简单HTML标签内里的内容。(?<=<(\w+)>)指定了这样的前缀:被尖括号括起来的单词(比如可能是<b>),然后是.*(任意的字符串),最后是一个后缀(?=<\/\1>)。注意后缀里的\/,它用到了前面提过的字符转义;\1则是一个反向引用,引用的正是捕获的第一组,前面的(\w+)匹配的内容,这样如果前缀实际上是<b>的话,后缀就是</b>了。整个表达式匹配的是<b>和</b>之间的内容(再次提醒,不包括前缀和后缀本身)。 贪婪与懒惰当正则表达式中包含能接受重复的限定符时,通常的行为是(在使整个表达式能得到匹配的前提下)匹配尽可能多的字符。以这个表达式为例:a.*b,它将会匹配最长的以a开始,以b结束的字符串。如果用它来搜索aabab的话,它会匹配整个字符串aabab。这被称为贪婪匹配。 有时,我们更需要懒惰匹配,也就是匹配尽可能少的字符。前面给出的限定符都可以被转化为懒惰匹配模式,只要在它后面加上一个问号?。这样.*?就意味着匹配任意数量的重复,但是在能使整个匹配成功的前提下使用最少的重复。现在看看懒惰版的例子吧: a.*?b匹配最短的,以a开始,以b结束的字符串。如果把它应用于aabab的话,它会匹配aab(第一到第三个字符)和ab(第四到第五个字符)。 为什么第一个匹配是aab(第一到第三个字符)而不是ab(第二到第三个字符)?简单地说,因为正则表达式有另一条规则,比懒惰/贪婪规则的优先级更高:最先开始的匹配拥有最高的优先权——The match that begins earliest wins。
处理选项在C#中,你可以使用Regex(String, RegexOptions)构造函数来设置正则表达式的处理选项。如:Regex regex = new Regex(@"\ba\w{6}\b", RegexOptions.IgnoreCase); 上面介绍了几个选项如忽略大小写,处理多行等,这些选项能用来改变处理正则表达式的方式。下面是.Net中常用的正则表达式选项:
一个经常被问到的问题是:是不是只能同时使用多行模式和单行模式中的一种?答案是:不是。这两个选项之间没有任何关系,除了它们的名字比较相似(以至于让人感到疑惑)以外。 其它语法
实战--牛刀小试
早就传说项目会在本月17号验收,结果客户突然抛出了132个bug,今天下午“光荣”的分到了59个,悲催啊。其中一个是关于统一系统中的提示框(alert)的风格的。ctrl+H,用正则表达式 \balert\b 小搜了一下,项目里面有494处alert,其中近半数使用的是javascript标准的alert()函数,其他的是Ext提供的Ext.MessageBox.alert()或者Ext.Msg.alert()函数。我打算全部统一成Ext.Msg.alert()函数。
看着前人留下来的千奇百怪的代码,我的蛋都碎了。比如大部分alert语句的形式是这样的:
Ext.Msg
.alert( '提示', '请在下拉列表中选择一条消息!');
好吧,我就当这只是Eclipse失败的代码格式化功能造成的吧!
废话不多说了,为了应对各种各样令人蛋碎的情况,鼓捣了很久,才写出了相应的一些正则表达式,并使用Eclipse自带的全局Search功能,进行了相应的替换(为保险起见,先进行preview确认一下)。表达式如下:
1、 (?<!\.|//\s{0,20})\balert\b\( 替换成 Ext.Msg.alert("提示",
这样就把所有javascript自带的,并且没有用“//”注释掉的alert都替换成了Ext.Msg.alert()形式。这里的关键是,alert前面可以有任意空白或分隔符,也可以是一般的字符,但就是不能是点号".",匹配的时候,只匹配"alert本身",前面空格神马的都不要。我这里用到了所谓的零宽度正回顾后发断言。
2、 Ext\.M(s|g|e|a|\R|\s)*\.alert\((\R|\W)*('|").*\3, 替换成Ext.Msg.alert("提示",
这样就把包括上面那种变态格式的代码在内的Ext.Msg.alert和Ext.MessageBox.alert全部替换成前者,并且第一个参数统一为双引号的"提示”。
OK,搞定!这是我第一次写正则表达式,肯定还是可以再优化的;暂时先这样了~
注意上面的正则表达中,有些特性是依赖于Eclipse的,比如不依赖环境的元字符\R,表示一个换行符。另外不要误把Ext本身的代码,以及系统中用到的别的第三方库的代码改错咯~
New:字符串替换实例(Java)
给定一个逗号分割的数字组成的字符串,(形如"11,1,22"),现需要删除其中的一个数字(match),并保持原字符串的格式
下面代码使用正则表达式,进行了两次替换;第一次是删除匹配到的数字,第二次是删除掉多余的逗号
|