[linux]shell中的正则表达式

 一个正则表达式就是由普通字符（例如字符 a 到 z）以及特殊字符（称为元字符）组成的文字模式。该模式描述在查找文字主体时待匹配的一个或多个字符串。正则表达式作为一个模板，将某个字符模式与所搜索的字符串进行匹配。

　　/
　　将下一个字符标记为一个特殊字符、或一个原义字符、或一个后向引用、或一个八进制转义符。例如，'n' 匹配字符 "n"。'/n' 匹配一个换行符。序列 '//' 匹配 "/" 而 "/(" 则匹配 "("。有时需要查找一些字符或字符串，而它们包含了系统指定为特殊字符的一个字符。如果要在正则表达式中匹配以*.pas结尾的所有文件，可做如下操作：/*/.pas

　　^
　　匹配输入字符串的开始位置。^只允许在一行的开始匹配字符或单词。如在行首第4个字符为1，匹配操作表示为：^...1

　　$
　　匹配输入字符串的结束位置。可以说$与^正相反，它在行尾匹配字符串或字符，$符号放在匹配单词后。如果在行尾匹配单词jet01，操作如下：jet01$。如果只返回包含一个字符的行，操作如下：^.$

　　*
　　匹配前面的子表达式零次或多次。例如，zo* 能匹配 "z" 以及 "zoo"。 *等价于{0,}。

　　+
　　匹配前面的子表达式一次或多次。例如，'zo+' 能匹配 "zo" 以及 "zoo"，但不能匹配 "z"。+等价于 {1,}。

　　?
　　匹配前面的子表达式零次或一次。例如，"do(es)?" 可以匹配 "do" 或 "does" 中的"do" 。?等价于 {0,1}。

　　{n}
　　n 是一个非负整数。匹配确定的 n 次。例如，'o{2}' 不能匹配 "Bob" 中的 'o'，但是能匹配 "food" 中的两个 o。

　　{n,}
　　n 是一个非负整数。至少匹配n 次。例如，'o{2,}' 不能匹配 "Bob" 中的 'o'，但能匹配 "foooood" 中的所有 o。'o{1,}' 等价于 'o+'。'o{0,}' 则等价于 'o*'。

　　{n,m}
　　m 和 n 均为非负整数，其中n <= m。最少匹配 n 次且最多匹配 m 次。 "o{1,3}" 将匹配 "fooooood" 中的前三个 o。'o{0,1}' 等价于 'o?'。请注意在逗号和两个数之间不能有空格。

　　?
　　当该字符紧跟在任何一个其他限制符 (*, +, ?, {n}, {n,}, {n,m}) 后面时，匹配模式是非贪婪的。非贪婪模式尽可能少的匹配所搜索的字符串，而默认的贪婪模式则尽可能多的匹配所搜索的字符串。例如，对于字符串 "oooo"，'o+?' 将匹配单个 "o"，而 'o+' 将匹配所有 'o'。

　　.
　　匹配除 "/n" 之外的任何单个字符。要匹配包括 '/n' 在内的任何字符，请使用象 '[./n]' 的模式。

　　(pattern)
　　匹配pattern 并获取这一匹配。所获取的匹配可以从产生的 Matches 集合得到，在VBScript 中使用 SubMatches 集合，在Visual Basic Scripting Edition 中则使用 $0…$9 属性。要匹配圆括号字符，请使用 '/(' 或 '/)'。

　　(?:pattern)
　　匹配 pattern 但不获取匹配结果，也就是说这是一个非获取匹配，不进行存储供以后使用。这在使用 "或" 字符 (　) 来组合一个模式的各个部分是很有用。例如， 'industr(?:y　ies) 就是一个比 'industry　industries' 更简略的表达式。

　　(?=pattern)
　　正向预查，在任何匹配 pattern 的字符串开始处匹配查找字符串。这是一个非获取匹配，也就是说，该匹配不需要获取供以后使用。例如， 'Windows (?=95　98　NT　2000)' 能匹配 "Windows 2000" 中的 "Windows" ，但不能匹配 "Windows 3.1" 中的 "Windows"。预查不消耗字符，也就是说，在一个匹配发生后，在最后一次匹配之后立即开始下一次匹配的搜索，而不是从包含预查的字符之后开始。

　　(?!pattern)
　　负向预查，在任何不匹配Negative lookahead matches the search string at any point where a string not matching pattern 的字符串开始处匹配查找字符串。这是一个非获取匹配，也就是说，该匹配不需要获取供以后使用。例如'Windows (?!95　98　NT　2000)' 能匹配 "Windows 3.1" 中的 "Windows"，但不能匹配 "Windows 2000" 中的 "Windows"。预查不消耗字符，也就是说，在一个匹配发生后，在最后一次匹配之后立即开始下一次匹配的搜索，而不是从包含预查的字符之后开始。

　　x　y
　　匹配 x 或 y。例如，'z　food' 能匹配 "z" 或 "food"。'(z　f)ood' 则匹配 "zood" 或 "food"。

　　[xyz]
　　字符集合。匹配所包含的任意一个字符。例如， '[abc]' 可以匹配 "plain" 中的 'a'。

　　[^xyz]
　　负值字符集合。匹配未包含的任意字符。例如， '[^abc]' 可以匹配 "plain" 中的'p'。

　　[a-z]
　　字符范围。匹配指定范围内的任意字符。例如，'[a-z]' 可以匹配 'a' 到 'z' 范围内的任意小写字母字符。

　　[^a-z]
　　负值字符范围。匹配任何不在指定范围内的任意字符。例如，'[^a-z]' 可以匹配任何不在 'a' 到 'z' 范围内的任意字符。

　　/b
　　匹配一个单词边界，也就是指单词和空格间的位置。例如， 'er/b' 可以匹配"never" 中的 'er'，但不能匹配 "verb" 中的 'er'。

　　/B
　　匹配非单词边界。'er/B' 能匹配 "verb" 中的 'er'，但不能匹配 "never" 中的 'er'。

　　/cx
　　匹配由x指明的控制字符。例如， /cM 匹配一个 Control-M 或回车符。 x 的值必须为 A-Z 或 a-z 之一。否则，将 c 视为一个原义的 'c' 字符。

　　/d
　　匹配一个数字字符。等价于 [0-9]。

　　/D
　　匹配一个非数字字符。等价于 [^0-9]。

　　/f
　　匹配一个换页符。等价于 /x0c 和 /cL。

　　/n
　　匹配一个换行符。等价于 /x0a 和 /cJ。

　　/r
　　匹配一个回车符。等价于 /x0d 和 /cM。

　　/s
　　匹配任何空白字符，包括空格、制表符、换页符等等。等价于 [ /f/n/r/t/v]。

　　/S
　　匹配任何非空白字符。等价于 [^ /f/n/r/t/v]。

　　/t
　　匹配一个制表符。等价于 /x09 和 /cI。

　　/v
　　匹配一个垂直制表符。等价于 /x0b 和 /cK。

　　/w
　　匹配包括下划线的任何单词字符。等价于'[A-Za-z0-9_]'。

　　/W
　　匹配任何非单词字符。等价于 '[^A-Za-z0-9_]'。

　　/xn
　　匹配 n，其中 n 为十六进制转义值。十六进制转义值必须为确定的两个数字长。例如， '/x41' 匹配 "A"。'/x041' 则等价于 '/x04' & "1"。正则表达式中可以使用 ASCII 编码。.

　　/num
　　匹配 num，其中 num 是一个正整数。对所获取的匹配的引用。例如，'(.)/1' 匹配两个连续的相同字符。

　　/n
　　标识一个八进制转义值或一个后向引用。如果 /n 之前至少 n 个获取的子表达式，则 n 为后向引用。否则，如果 n 为八进制数字 (0-7)，则 n 为一个八进制转义值。

　　/nm
　　标识一个八进制转义值或一个后向引用。如果 /nm 之前至少有is preceded by at least nm 个获取得子表达式，则 nm 为后向引用。如果 /nm 之前至少有 n 个获取，则 n 为一个后跟文字 m 的后向引用。如果前面的条件都不满足，若 n 和 m 均为八进制数字 (0-7)，则 /nm 将匹配八进制转义值 nm。

　　/nml
　　如果 n 为八进制数字 (0-3)，且 m 和 l 均为八进制数字 (0-7)，则匹配八进制转义值 nml。

　　/un
　　匹配 n，其中 n 是一个用四个十六进制数字表示的 Unicode 字符。例如， /u00A9 匹配版权符号 (?)。

1. 表达式的递归匹配

有时候，我们需要用正则表达式来分析一个计算式中的括号配对情况。比如，使用表达式 "/( [^)]* /)" 或者 "/( .*? /)" 可以匹配一对小括号。但是如果括号 内还嵌有一层括号的话 ，如 "( ( ) )"，则这种写法将不能够匹配正确，得到的结果是 "( ( )" 。类似情况的还有 HTML 中支持嵌套的标签如 "<font> </font>" 等。本节将要讨论的是，想办法把有嵌套的的成对括号或者成对标签匹配出来。

匹配未知层次的嵌套：

有的正则表达式引擎，专门针对这种嵌套提供了支持。并且在栈空间允许的情况下，能够支持任意未知层次的嵌套：比如 Perl，PHP，GRETA 等。在 PHP 和 GRETA 中，表达式中使用 "(?R)" 来表示嵌套部分。

匹配嵌套了未知层次的 "小括号对" 的表达式写法如下："/(  ([^()]  |  (?R))*  /)"。

    [Perl 和 PHP 的示例代码]

匹配有限层次的嵌套：

对于不支持嵌套的正则表达式引擎，只能通过一定的办法来匹配有限层次的嵌套。思路如下：

第一步，写一个不能支持嵌套的表达式："/( [^()]* /)"，"<font>((?!</?font>).)*</font>"。 这两个表达式在匹配有嵌套的文本时，只匹配最内层。

第二步，写一个可匹配嵌套一层的表达式："/( ([^()] | /( [^()]* /))* /)"。这个表达式在匹配嵌套层数大于一时，只能匹配最里面的两层，同时，这个表达式也能匹配没有嵌套的文本或者嵌套的最里层。

匹配嵌套一层的 "<font>" 标签，表达式为："<font>((?!</?font>).|(<font>((?!</?font>).)*</font>))*</font>"。这个表达式在匹配 "<font>" 嵌套层数大于一的文本时，只匹配最里面的两层。

第三步，找到匹配嵌套(n)层的表达式 与 嵌套(n-1)层的表达式之间的关系。比如，能够匹配嵌套(n)层的表达式为：

    [标记头]  ( [匹配 [标记头] 和 [标记尾] 之外的表达式] | [匹配 n-1 层的表达式] )*  [标记尾]

    回头来看前面编写的“可匹配嵌套一层”的表达式：

	/(	(	[^()]	|	/(([^()])*/)	)*	/)
	<font>	(	(?!</?font>).	|	(<font>((?!</?font>).)*</font>)	)*	</font>
	PHP 和 GRETA 的简便之处在于，匹配嵌套(n-1)层的表达式用 (?R) 表示：
	/(	(	[^()]	|	(?R)	)*	/)

    第四步，依此类推，可以编写出匹配有限(n)层的表达式。这种方式写出来的表达式，虽然看上去很长，但是这种表达式经过编译后，匹配效率仍然是很高的。

2. 非贪婪匹配的效率

    可能有不少的人和我一样，有过这样的经历：当我们要匹配类似 "<td>内容</td>" 或者 "[b]加粗[/b]" 这样的文本时，我们根据正向预搜索功能写出这样的表达式："<td>([^<]|<(?!/td>))*</td>" 或者 "<td>((?!</td>).)*</td>"。

    当发现非贪婪匹配之时，恍然大悟，同样功能的表达式可以写得如此简单："<td>.*?</td>"。 顿时间如获至宝，凡是按边界匹配的地方，尽量使用简捷的非贪婪匹配 ".*?"。特别是对于复杂的表达式来说，采用非贪婪匹配 ".*?" 写出来的表达式的确是简练了许多。

    然而，当一个表达式中，有多个非贪婪匹配时，或者多个未知匹配次数的表达式时，这个表达式将可能存在效率上的陷阱。有时候，匹配速度慢得莫名奇妙，甚至开始怀疑正则表达式是否实用。

效率陷阱的产生：

    在本站基础文章里，对非贪婪匹配的描述中说到：“如果少匹配就会导致整个表达式匹配失败的时候，与贪婪模式类似，非贪婪模式会最小限度的再匹配一些，以使整个表达式匹配成功。”

    具体的匹配过程是这样的：

1. "非贪婪部分" 先匹配最少次数，然后尝试匹配 "右侧的表达式"。
2. 如果右侧的表达式匹配成功，则整个表达式匹配结束。如果右侧表达式匹配失败，则 "非贪婪部分" 将增加匹配一次，然后再尝试匹配 "右侧的表达式"。
3. 如果右侧的表达式又匹配失败，则 "非贪婪部分" 将再增加匹配一次。再尝试匹配 "右侧的表达式"。
4. 依此类推，最后得到的结果是 "非贪婪部分" 以尽可能少的匹配次数，使整个表达式匹配成功。或者最终仍然匹配失败。

    当一个表达式中有多个非贪婪匹配，以表达式 "d(/w+?)d(/w+?)z" 为例，对于第一个括号中的 "/w+?" 来说，右边的 "d(/w+?)z" 属于它的 "右侧的表达式"，对于第二个括号中的 "/w+?" 来说，右边的 "z" 属于它的 "右侧的表达式"。

    当 "z" 匹配失败时，第二个 "/w+?" 会 "增加匹配一次"，再尝试匹配 "z"。如果第二个 "/w+?" 无论怎样 "增加匹配次数"，直至整篇文本结束，"z" 都不能匹配，那么表示 "d(/w+?)z" 匹配失败，也就是说第一个 "/w+?" 的 "右侧" 匹配失败。此时，第一个 "/w+?" 会增加匹配一次，然后再进行 "d(/w+?)z" 的匹配。循环前面所讲的过程，直至第一个 "/w+?" 无论怎么 "增加匹配次数"，后边的 "d(/w+?)z" 都不能匹配时，整个表达式才宣告匹配失败。

    其实，为了使整个表达式匹配成功，贪婪匹配也会适当的“让出”已经匹配的字符。因此贪婪匹配也有类似的情况。当一个表达式中有较多的未知匹配次数的表达式时，为了让整个表达式匹配成功，各个贪婪或非贪婪的表达式都要进行尝试减少或增加匹配次数，由此容易形成一个大循环的尝试，造成了很长的匹配时间。本文之所以称之为“陷阱”，因为这种效率问题往往不易察觉。

    举例："d(/w+?)d(/w+?)d(/w+?)z" 匹配 "ddddddddddd..." 时，将花费较长一段时间才能判断出匹配失败 。

效率陷阱的避免：

    避免效率陷阱的原则是：避免“多重循环”的“尝试匹配”。并不是说非贪婪匹配就是不好的，只是在运用非贪婪匹配的时候，需要注意避免过多“循环尝试”的问题。

    情况一：对于只有一个非贪婪或者贪婪匹配的表达式来说，不存在效率陷阱。也就是说，要匹配类似 "<td> 内容 </td>" 这样的文本，表达式 "<td>([^<]|<(?!/td>))*</td>" 和 "<td>((?!</td>).)*</td>" 和 "<td>.*?</td>" 的效率是完全相同的。

    情况二：如果一个表达式中有多个未知匹配次数的表达式，应防止进行不必要的尝试匹配。

    比如，对表达式 "<script language='(.*?)'>(.*?)</script>" 来说， 如果前面部分表达式在遇到 "<script language='vbscript'>" 时匹配成功后，而后边的 "(.*?)</script>" 却匹配失败，将导致第一个 ".*?" 增加匹配次数再尝试。而对于表达式真正目的，让第一个 ".*?" 增加匹配成“vbscript'>”是不对的，因此这种尝试是不必要的尝试。

    因此，对依靠边界来识别的表达式，不要让未知匹配次数的部分跨过它的边界。前面的表达式中，第一个 ".*?" 应该改写成 "[^']*"。后边那个 ".*?" 的右边再没有未知匹配次数的表达式，因此这个非贪婪匹配没有效率陷阱。于是，这个匹配脚本块的表达式，应该写成："<script language='([^']*)'>(.*?)</script>" 更好。