浏览器中的正则表达式陷阱说明

前端  /  管理员 发布于 7年前   490

在本章开始前 我要引入一个例子 来说明这种不彻底的 变态的优化 到底合理还是不合理...

c# 中的 字符串直接量 做的优化 就非常彻底...这种优化我们应该是欢迎的...

 string str="franky";

string str2="franky";

在内存中 只有一份 字符串对象 而str和str2 具备相同的一份引用. 很明显 这非常合理.

string n = "franky",  n2 = "franky";
Response.Write((Object.ReferenceEquals(n,n2)).ToString());//True.

那么 一些特殊情况下  有些浏览器 为正则表达式直接量也做了类似的优化.

alert(/\d/==/\d/);//所有浏览器都是false 这很合理 因为正则表达式直接量 同 [] 数组直接量 {}对象直接量一样 都是引用类型 

我们再看看哪些情况下哪些浏览器做了优化

    function f2() {
        return /\d/;
    }

       alert(f2() == f2());

//这里的结果就有不同了

ie6 7 8  opear10 safari4 都返回false  (我虚拟机里safari3坏了没做测试.如果谁有 帮忙测下告诉我结果.谢谢 我估计safari3 会返回true.原因是 maxthon3用的引擎貌似就是safari3 的) 

但是

firefox 2.0 3.0+ 3.5 3.6  chrome 4 5 opear9  maxthon3 demo版  使用webkit引擎下 都返回true

有趣的地方在于 opera9 做了优化 而opera10 取消了这种优化. 看来至少opera团队认为这种优化时不恰当的...（变相支持了我的观点.）

 

看到这里 你也许会奇怪 是不是 bug而不是所谓优化啊？ 也许是闭包对象 出了什么问题或者 是 函数对象上的某些bug引起的？

那么我们看看下面的例子:

for (var i = 0; i < 10; i++) document.writeln(/\d/g.test('' + i));

不同浏览器 输出结果的 差异 完全符合上面 是否做优化的分类.

即没有 做优化的浏览器 一律返回true 而作了优化的浏览器 则是 true false true false 交替的结果.

我们这里只是一个 循环 ..js中的循环没有独立的作用域 更不会产生闭包对象 那么可以肯定 引起这个怪异问题的 根本原因就是某些浏览器自作聪明的优化.

可能大家不太理解 test的结果 差异来自哪里...  答案是 test 同 exec 一样 如果 直接量后面有/g  .设置了 global全局查找参数 的话 那么 同一个test对象 会记录上次 匹配字符的索引位置.下次再 匹配时 会从这个位置开始..如果没有 则 匹配索引<0 下次在此匹配时 就仍然从0位置字符开始.

所以上面这个测试 使用 exec 也是可以的.

那么 这里 如何避免浏览器差异呢？ 简单的办法 去掉/g即可

这里我们为了躲避陷阱 就要 记得一个约定.  请尽量不要使用 一个正则直接量 在函数体内 或 循环内. 如果一定要如此 请使用new RegExp('\d',g);这种.

对于exec 尽量用 string.match代替. 因为match 强制你依靠是否有 /g 来全局查找..不会产生歧义.

对于test 如果是循环内 也可以考虑  var reg=/\d/; //这里要吧/g去掉..请不要忘记哦

for (var i = 0; i < 10; i++) document.writeln(reg.test('' + i));

事实上这样用是最合理的办法 .原因是 这里我们只产生一个正则对象 并反复使用他.. 本质上也是为了优化。但是我们避开了 浏览器自己的优化差异 导致的不同结果.

最后我们发现 所谓陷阱 发生主要是 /g使用不当.无论是 exec 还是test都是如此  如果合理使用/g 无论浏览器是否存在变态的优化. 执行结果都将是正确的...唯一的区别 只在于 做了优化的浏览器 不需要反复产生一个 正则对象然后再垃圾回收 再产生一个正则对象....如此反复而已...

那么我们发现 遵守上面几个原则的话 这种问题 也都避免了...