正则表达式的环视深度剖析

顺序环视相当于在当前位置右侧附加一个条件，所以它的匹配尝试是从当前位置开始的，然后向右尝试匹配，直到某一位置使得匹配成功或失败为止。而逆序环视的特殊处在于，它相当于在当前位置左侧附加一个条件，所以它不是在当前位置开始尝试匹配的，而是从当前位置左侧某一位置开始，匹配到当前位置为止，报告匹配成功或失败。

顺序环视尝试匹配的起点是确定的，就是当前位置，而匹配的终点是不确定的。逆序环视匹配的起点是不确定的，是当前位置左侧某一位置，而匹配的终点是确定的，就是当前位置。

所以顺序环视相对是简单的，而逆序环视相对是复杂的。这也就是为什么大多数语言和工具都提供了对顺序环视的支持，而只有少数语言提供了对逆序环视支持的原因。

JavaScript 中只支持顺序环视，不支持逆序环视。

Java 中虽然顺序环视和逆序环视都支持，但是逆序环视只支持长度确定的表达式，逆序环视中量词只支持“?”，不支持其它长度不定的量词。长度确定时，引擎可以向左查找固定长度的位置作为起点开始尝试匹配，而如果长度不确定时，就要从当前位置向左逐个位置开始尝试匹配，不成功则回溯，再向左侧位置进行尝试匹配，然后重复以上过程，直到匹配成功，或是尝试到位置0处以后，报告匹配失败，处理的复杂度是显而易见的。

目前只有.NET中支持不确定长度的逆序环视。

源字符串：

正则表达式：(?（1）匹配起始位置不确定，匹配结束位置确定

当前位置是匹配终点，匹配起点在当前位置的左侧，最终的匹配起点是不确定的，初始的匹配起点可以根据逆序表达式的长度来查找。

注：我认为这样的匹配逻辑是错误的，不认可

首先由“(?)”的子表达式“”取得控制权，由位置 0 开始尝匹配，由于“”的长度固定为 3，所以会从当前位置向左查找 3个字符，但是由于此时位于位置 0 处，前面没有任何字符，所以直接匹配失败，“”匹配失败，那么整个逆序否定环视表达式“(?)”则匹配成功，所以位置 0 满足逆序否定环视表达式“(?)”，那么控制权就传给了“B”，由“B”从位置 0 开始向右匹配字符，于是“B”就去匹配字符串中的“a”，结果匹配失败，那么第 1 次迭代匹配失败。

正则引擎传动装置向右传动，你可以理解为有个指针的东西向右移动，此时指针来到位置 1 处，由位置 1 处向左查找 3 个字符，但是前面只有 1 个字符 a，所以同样和“”匹配失败，则整个逆序否定环视表达式“(?)”匹配成功，控制权传给“B”，由“B”从位置 1 开始向右匹配字符，于是“B”就去匹配字符串中的“d”，结果匹配失败，那么第 2 次迭代匹配失败。

直到位置 3 处，向左查找到 3 个字符串“abc”，字符数满足条件，此时“(?)”中的子表达式“”获得控制权。“”取得控制权后，由位置 0 处开始向右逐个字符匹配字符串“abc”，既然是逐字符进行匹配的，所以这时会把控制权交给“”中的“B”，由“B”从位置 3 开始向右匹配字符，于是“B”就去匹配字符串中的“”，由“B”从位置 4 开始向右匹配字符，于是“B”就去匹配位置 4 后面的“B”，结果匹配成功。

重复上述的过程直到正则引擎的指针移到字符串结尾才结束迭代匹配。

最后匹配到的“B”，如下所示（高亮部分）：

当前位置是匹配起点，逆序环视是从当前位置向左开始匹配的，匹配终点在当前位置的左侧。不少人认为应该是这样的匹配规则，因为更符合逆序的概念。我也支持这个匹配逻辑。

注：需要明确的一点，无论是什么样的正则表达式，都是要从字符串的位置 0 处开始尝试匹配的，这点没有变。

逆序否定环视表达式“(?)B”中的“”先获得控制权，因为匹配从右到左，所以子表达式“”中的“>”会先获得控制权，去匹配字符串当前位置左边的第 1 个字符，不过当前位置是 0，所以左侧没有字符，固然匹配失败，既然“”匹配失败，那么整个逆序否定环视表达式“(?)B”就匹配成功，也就是说位置 0 是匹配成功的，位置 0 是满足逆序否定环视表达式的，于是控制权交给“B”，由“B”从字符串位置 0 开始向右匹配字符，显然“B”匹配“a”是失败的，因此整个正则表达式的第 1 次迭代匹配失败。

重复上述的过程，直到位置 4，“”从位置 4 开始向左逐个字符匹配，首先由“>”匹配位置 4 左边的第 1 个字符“”匹配成功，也就是说位置 4 匹配成功，控制权交个了“B”，由“B”从位置 4 开始向右匹配字符，显示“B”与字符“B”匹配成功。

重复上述过程，直到正则引擎的指针移到位置 6 时，“”逐个字符匹配位置 6 左侧的字符，首先“”中的“>”先去匹配位置 6 左边的第 1 个字符“>”，匹配成功；接着“”中的“B”去匹配位置 6 左边的第 2 个字符“B”，也匹配成功；接着“”中的“