IE6、IE7环视应用中的一个bug

http://topic.csdn.net/u/20110111/00/5bc889c6-14b0-4297-bd6a-383c719ba1b2.html

问题的起源是上面的帖子，昨天晚上看到帖子的时候已经超过12：40了。没有时间去思考，给了个答案就匆匆睡了。初步诊断了IE7下的环视出现了BUG

早上起来就开始折腾这玩意，废话不多说，看看BUG到底出在什么地方吧

首先我把正则简化了问题，因为错误的不确定性，我试图删除各个地方以达到尽量展示错误的来源。最后得到的正则如下

/^(?=.*/d).{8,20}$/

这个时候测试依然错误。也可以检测出和环视有关系

给每个部分加上分组测试

/^(?=(.*)(/d))(.{8,20})$/

这个正则依然不具有任何意义，因为他找不到匹配，逐步调整

var s = "abc123123";

var reg = /^(?=(.*)(/d))(.+)$/;

alert(reg.exec(s));

测试结果完全正确，看不出和其他浏览器及正则原理有任何不同。由此可见环视中.*确实是贪婪匹配，/d也正常匹配的数字。

再做一次调整。

var s = "abc123123";

var reg = /^(?=(.*)(/d))(.{6,20})$/;

alert(reg.exec(s));

问题出现了

.*竟然匹配abc而非abc123123。难道说.*不是贪婪匹配么？不对啊，刚才的测试证明他确实是贪婪匹配啊。只能猜测.*影响了后面的匹配。

var s = "abc123123";

var reg = /^(?=(.*)(/d))(.{2,20})$/;

alert(reg.exec(s));

这次匹配的结果是.*匹配abc1231

/d匹配的是2

根据两次的测试，初步得出的结论是.*是贪婪匹配，但是环视中的匹配位置出现了错误。

.{6,20}的匹配证明了/d是没有问题的，因为/d虽然匹配了1，但是没有占有任何字符和位置，把字符1交还给了.{6,20}

由此可见。.*最大只能匹配到总长度减去.{2,20}的最小长度

引用下好奇的说法：

ie的预查和量词是有bug的。。。

实际上这里的

{6,18}

量词

它是从预查里的lastIndex开始计算的。

就是

a这个位置前面的那个位置，所以显然是false。

下面是我的解释：

它是从预查里的lastIndex开始计算的。 这里有点更正 是从预查的.*的lastIndex开始计算

比如.*/d 这个时候他不是从/d后面的position开始计算 而是.*的position开始计算

当后面的量词最小值为N的时候 .*被迫回溯到后面匹配所需的n个元素的position