正则表达式的几种引擎

正则引擎主要可以分为基本不同的两大类：一种是DFA(确定性有穷自动机，学过计算理论的应该都知道），另一种是NFA（非确定性有穷自动机），DFA和NFA都有很长的历史，NFA的历史更长一些，两者在二十多年的发展中产生了许多不必要的变体。而POSIX标准的出台是为了规范这种现象。POSIX标准不但清楚地规定了引擎应该支持的元字符和特性，还明确规定了使用者期望由表达式获得的准确结果。DFA已经符合新的标准，而NFA则需要修改才能符标准。这样一来，正则引擎可以粗略地分为3类：DFA、传统型NFA、POSIX NFA，表格 1是从书中摘出来的，基本涵盖了现在主流的大部分程序。

表格 1

引擎类型	程序
DFA	awk (大多数版本)、egrep(大多数版本)、flex、lex、MySQL、Procmail
传统型NFA	GNU Emacs、Java、grep(大多数版本)、less、more、.NET语言、PCRE library、Perl、PHP(所有三套正则库)、Python、Ruby、sed(大多数版本)、vi
POSIX NFA	mawk、Mortice Kern Systems’ utilities、GNU Emacs (明确指定时使用)
DFA/NFA 混合	GNU awk、GNU grep/egrep、Tcl

DFA和NFA反映了将正则表达式在应用算法上的根本差异。NFA可以称为表达式主导的引擎，DFA则可以称为文本主导。所谓表达式主导是指在每一个匹配过程中，每一个子表达式都是独立的，或者可以认为一条由多个子表达式组成的正则表达式在表达式主导的引擎中等效于基本等效于多条表达式串行执行（当然公共部分是不会被重复执行的）。而在文本主导的引擎中，多条子表达式会在扫描文本时同时进行匹配。

在书上举了个例子，基本说明了这两种方式的不同：用to(nite|knight|night)匹配文本’tonight’，当表达式主导引擎来匹配时，在匹配完to后会依次匹配nite、knight、night直到匹配成功为止（即匹配night时）。而文本主导的引擎匹配时，会记录当前有效的所有匹配可能，所以当匹配完to时，由于knight的k不能匹配，所以被淘汰出局，这时剩下的是两个有效的可能匹配（nite和night），当扫描到g时就只剩下一个可能匹配了，当h和t完成匹配时，引擎发现匹配完成，报告成功。

以上的匹配过程其实引出了几个概念，同时我们也可以从这个例子中看出两种引擎的不同。在NFA中由于表达式主导的串行匹配方式，所以用到了回溯（backtracking），按照书中的说法，这个是NFA最重要的部分，每一次某个分支的匹配失败都会导致一次回溯，因此如何正确的选择表达式，减少回溯次数就成为了提高NFA引擎下正则表达式工作效率的关键。具体内容可以参考相关资料。另外还有两个DFA中没有的概念：“匹配优先量词”和“忽略优先量词”。（在DFA中只有匹配优先，这个也很好理解，一方面是DFA没有也不需要回溯，另外一个原因是DFA的最左最长原则，在下文会提到）这里也不展开了，网上有不少资料讲这两个概念，以及如何灵活选择两种量词来提高效率的范例。

总的来说DFA和NFA的明显区别之一在于效率，正如上面说到的，由于DFA没有回溯，因此看起来在某些情况下会比NFA来得更快，但是在真正使用中，DFA需要进行预编译才能获得更好效果，因为DFA的匹配方式需要更多的内存和时间，在第一次遇到正则表达式时需要比NFA详细得多的方法来分析这个表达式，不过可以预先把对不同正则表达式的分析结果建好，DFA就可以获得比NFA更优的速度。虽然NFA速度更慢，并且实现复杂，但是它又有着比DFA强大的多的功能，比如支持环视，支持反向引用（虽然这个是非正则的）等。除此之外，最大的区别就在于最左最长规则（longest of the leftmost）这是在POSIX标准中规定的一条原则，即如果在字符串的某个位置存在多个可能的匹配，则返回的是最长的匹配，又由于匹配时总是从左边开始的，所以叫最左最长规则。DFA天然地支持这一条规则，而NFA由于使用了回溯，并且会在匹配时立刻返回结果，再加上忽略优先量词的存在，使得它天然地不支持这条规则……，当然如果对NFA进行一些修改，要求其在首次匹配时不是停下来而是穷尽所有结果，最后返回最长的结果，则NFA就被改造成了POSIX NFA。

正则表达式的终极境界是兼具DFA的速度和NFA的功能，比如GNU grep采取了一种简单有效的策略，在平时尽可能多地使用DFA，在需要用到反向引用的时候，才切换到NFA，可以得到很不错的结果。