浏览器中的 正则表达式陷阱
js 内置对象 RegExp 我们用的很习惯 也很舒服 但是里面却有 严重的隐患 或者陷阱...原因在于 有些浏览器 对正则表达式直接量的优化.
在本章开始前 我要引入一个例子 来说明这种不彻底的 变态的优化 到底合理还是不合理...
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+ opear10+ safari3+, chrome7+都返回false
firefox3.6- chrome6- opear9.6- maxthon3 beta版 使用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 无论浏览器是否存在变态的优化. 执行结果都将是正确的...唯一的区别 只在于 做了优化的浏览器 不需要反复产生一个 正则对象然后再垃圾回收 再产生一个正则对象....如此反复而已...
那么我们发现 遵守上面几个原则的话 这种问题 也都避免了...
纠正一个说法:
所谓优化的说法是不对的.最近通过对ECMA262 Edition3 和Edition5的翻译. 发现了很多以前没太仔细阅读的角落. 而这些角落却有一些很重要的信息.比如这里所谓浏览器对正则表达式直接量的优化, 本质就是对ECMA262 Edition3标准的严格遵守. 因为Edition3明确指出.在一个ECMA程序中,在词法分析期,扫描到一个正则表达式直接量时,产生一个正则对象(RegExp object). 而在运行时,对该直接量的执行,仅仅会产生一个对原始object的引用.而不会创建一个新的RegExp object. 这就说明了本质问题了.
而ECMA262 Edition5则.做出了改变. 即,在每次执行到一个直接量时,都产生一个RegExp object.
那么,最终并不是变态优化的问题,而是新老标准的PK,当然老道之所以在此处做出修改,正是基于Edition3的不合理.
