这里有新鲜出炉的 Javascript 教程,程序狗速度看过来!
Javascript 是一种由 Netscape 的 LiveScript 发展而来的原型化继承的基于对象的动态类型的区分大小写的客户端脚本语言,主要目的是为了解决服务器端语言,比如 Perl,遗留的速度问题,为客户提供更流畅的浏览效果。
这篇文章主要介绍了正则中的回溯定义与用法, 结合实例形式分析了回溯的概念、功能并提供了 JS 与 java 实现方法, 需要的朋友可以参考下
本文实例分析了正则中的回溯定义与用法。分享给大家供大家参考,具体如下:
关于 "回溯" 我也是第一次接触,对它也不算很了解。下面就把我所了解的做为一个心德记录下来,以备查看。
我们所使用的正则表达式的匹配基础大概分为:优先选择最左端(最靠开头)的匹配结果和标准的匹配量词(*、+、?和 {m, n})是匹配优先的。
"优先选择最左端的匹配" 顾名思义就是从字符串的起始位置开始匹配直到匹配结束这是基础;"标准匹配量词" 又分为 "非确定型有穷自动机(NFA)" 也可以叫做 "表达式主导";另外一种是 "确定型有穷自动机(DFA)" 也可以叫做 "文本主导"。我们目前在 JavaScript 中所使用的正则表达式为 "表达式主导"。表达式主导和文本主导解释起来有些麻烦,先看来一个例子可能会清楚些。
- // 使用正则表达式匹配文本
- var reg = /to(nite|knight|night)/;
- var str = 'doing tonight';
- reg.test(str);
在上面的这个例子中,第一个元素 [t],它将会重复尝试,直到目标字符串中找到't'为止。之后,就检查紧随其后的字符是否能由[o] 匹配,如果能,就检查下面的元素(nite|knight|night)。它的真正含义是 "nite" 或者 "knight" 或者 "night"。引擎会依次尝试这 3 种可能。尝试 [nite] 的过程是先尝试[n],然后[i],然后[t],最后是[e]。如果这种尝试失败,引擎会尝试另一种可能,如此继续下去,直到匹配成功或是报告失败。表达式中的控制权在不同的元素之间转换,所以称为 "表达式主导"。
同样是上面的例子 "文本主导" 在扫描字符串时,会记录当前有效的所有匹配可。当引擎移动到 t 时,它会在当前处理的匹配可能中添加一个潜在的可能:
字符串中的位置 | 正则表达中的位置 |
……doing tonight | 可能的匹配位置:/t↑o(nite|knight|nigth)/ |
接下来扫描的每个字符,都会更新当前的可能匹配序列。继续扫描两个字符以后的情况是:
字符串中的位置 | 正则表达中的位置 |
……doing tonight | 可能的匹配位置:/to(ni↑te|knight|ni↑gth)/ |
有效的可能匹配变为两个(knight 被淘汰出局)。扫描到 g 时,就只剩下一个可能匹配了。当 h 和 t 匹配完成后,引擎发现匹配已经完成,报告成功。"文本主导" 是因为它扫描的字符串中的每个字符都对引擎进行了控制。
如果想要弄明白 "表达式主导" 是如何工作的,那就要看一下我们今天的主题 "回溯(backtracking)"。回溯就像是在走岔路口,当遇到岔路的时候就先在每个路口做一个标记。如果走了死路,就可以照原路返回,直到遇见之前所做过的标记,标记着还未尝试过的道路。如果那条路也走不能,可以继续返回,找到下一个标记,如此重复,直到找到出路,或者直到完成所有没有尝试过的路。
在许多情况下,正则引擎必须在两个(或更多)选项中做出选择。当遇到 /……x?……/ 时,引擎必须是否尝试匹配 X。对于 /……X+……/ 的情况,毫无疑问,X 至少尝试匹配一次——因为加号要求必须匹配至少一次。第一个 X 匹配之后,此要求已经满足,需要决定是否尝试下一个 X。如果决定进行,还要决定是否匹配第三个 X,第四个 X,如此继续。每次选择,其实就是做一个标记,用于提示此处还有另一个可能的选择,保留起来以备用。在回溯的过程中要考虑两个要点:哪个分支应当首先选择?回溯的时候使用的是哪个(或者是哪些个)之前保存的分支?
第一个问题是按下面这条重要原则来选择的:
如果需要在 "进行尝试" 和 "路过尝试" 之间选择,对于匹配优先量词,引擎会优先选择 "进行尝试",而对于忽略优先量词,会选择 "路过尝试"。
第二个问题是按以下这条原则:
距离当前最近储存的选项就是当本地失败强制回溯时返回的。使用的原则是 LIFO(last in first out,后进先出)。
我们先来看几个在道路中做标记的例子:
1、未进行回溯的匹配
用 [ab?c] 来匹配 "abc"。[a]匹配之后,匹配的当前状态如下:
"a↑bc" | a↑b?c |
现在轮到 [b?] 了,正则引擎需要决定:是需要尝试 [b] 呢,还是跳过?因为 [?] 是匹配优先的,它会尝试匹配。但是,为了确保在这个尝试最终失败之后能够恢复,引擎会把:
"a↑bc" | ab?↑c |
添加到备用状态序列中。也就是说,稍后引擎可能从下面的位置继续匹配:从正则表达式中的 [b?] 之后,字符串的 c 之前(也就是说当前的位置)匹配。这实际上就是跳过 [b] 的匹配,而问题容许这样做。引擎做好标记后,就会继续向前检查[b]。在示例中,它能够匹配,所以新的当前状态变为:
"ab↑c" | ab?↑c |
最终的 [c] 也能成功匹配,所以整个匹配完成。备用状态不再需要了,所以不再保存它们。
2、进行了回溯的匹配
下面要匹配的文本是 "ac",在尝试 [b] 之前,一切都与之前的过程相同。显然,这次 [b] 无法匹配。也就是说,对 [……?] 进行尝试的路走不通了。因为有一个备用状态,这个 "局部匹配失败" 产工会导致整体匹配失败。引擎会进行回溯,也就是说,把 "当前状态" 切换为最近保存的状态。
"a↑c" | ab?↑c |
在 [b] 尝试之前保存的尚未尝试的选项。这时候,[c]可以匹配 c,所以整个匹配宣告完成。
3、不成功的匹配
现在要匹配的文本是 "abx"。在尝试 [b] 以前,因为存在问号,保存了这个备用状态:
"a↑bx" | ab?↑c |
[b]能够匹配,但这条路往下却走不通了,因为 [c] 无法匹配 x。于是引擎会回溯到之前的状态,"交还"b 给 [c] 来匹配。显然,这次测试也失败了。如果还有其他保存的状态,回溯会继续进行,但是此时不存在其他状态,在字符串中当前位置开始的整个匹配也就宣告失败。
例子 1: 提取字符串 提取 da12bka3434bdca4343bdca234bm 提取包含在字符 a 和 b 之间的数字,但是这个 a 之前的字符不能是 c,b 后面的字符必须是 d 才能提取。
例如这里就只有 3434 这个数字满足要求。那么我们怎么提取呢?
首先我们写出提取这个字符串的表达式: (?<!c)a(/d+)bd 这里就只有一个捕获组 (/d+)
Java 代码片段如下:
- Pattern p = Pattern.compile( "(?<!c)a(//d+)bd " );
- Matcher m = p.matcher( "da12bka3434bdca4343bdca234bm" );
- while (m.find()){
- System.out.println(m.group( 1 )); //我们只要捕获组1的数字即可。结果 3434
- System.out.println(m.group(0)); // 0组是整个表达式,看这里,并没有提炼出(?<!c)的字符 。结果 a3434bd
- }
例子 2: 将一些多位的小数截短到三位小数:\d+\.\d\d[1-9]?\d+
在这种条件下 6.625 能进行匹配,这样做没有必要,因为它本身就是三位小数。最后一个 "5" 本来是给 [1-9] 匹配的,但是后面还有一个 \d+ 所以,[1-9] 由于是 "?" 可以不匹配所以只能放弃当前的匹配,将这个 "5" 送给 \d+ 去匹配,如果改为:
- \d+\.\d\d[1-9]?+\d+
的侵占形式,在 "5" 匹配到 [1-9] 时,由于是侵占式的,所以不会进行回溯,后面的 \d+ 就匹配不到任东西了,所以导致 6.625 匹配失败。
这种情况,在替换时就有效了,比如把数字截短到小数点后三位,如果正好是三位小数的,就可以不用替换了,可以提高效率,侵占量词基本上就是用来提高匹配效率的。
把 \d+\.\d\d[1-9]?+\d+ 改为 \d+\.\d\d(?>[1-9]?)\d+ 这样是一样的。
希望本文所述对大家 JavaScript 程序设计有所帮助。
来源: http://www.phperz.com/article/17/0710/329100.html