正则表达式话题 【正则表达式--递归匹配与非贪婪匹配 】

[出处：http://www.regexlab.com/zh/regtopic.htm]

引言

    本文将逐步讨论一些正则表达式的使用话题。本文为本站基础篇以后的扩展，在阅读本文以前，建议先阅读正则表达式参考文档一文。

---

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>" 更好。