Regular expression trap description in browser


Before the beginning of this chapter, I will introduce an example to illustrate whether this kind of incomplete abnormal optimization is reasonable or unreasonable

C # in the string of direct optimization is very thorough… This optimization we should be welcome

 string str=”franky”;

string str2=”franky”;

There is only one string object in memory, and STR and STR2 have the same reference

string n = “franky”,  n2 = “franky”;

In some special cases, some browsers have done similar optimization for regular expression direct quantity

Alert (/ – D / = / – D /); / / all browsers are false, which is reasonable because the direct quantity of regular expression is the same as the direct quantity of [] array {} object, which is a reference type

Let’s see which browsers are optimized in which cases

    function f2() {
        return /\d/;

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

//The result here is different

IE6 7 8? Opear10 safari4 all return false (safari3 in my virtual machine is broken. If anyone can help me test the result, please tell me. Thank you. I estimate safari3 will return true. The reason is that the engine used by maxthon3 seems to be safari3’s)


Firebox 2.0 3.0 + 3.5 3.6 chrome 4.5 opar9 maxthon3 demo returns true when using WebKit engine

What’s interesting is that opera9 did the optimization and opera10 canceled it. It seems that at least the opera team thinks that the optimization is inappropriate


You may wonder if it’s a bug rather than an optimization? Maybe something is wrong with the closure object or some bugs in the function object?

Let’s look at the following example:

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

The difference of output results of different browsers is fully consistent with the above classification

That is to say, all browsers that have not been optimized return true, while those that have been optimized are alternate results of true false and true false

We are just a loop here. The loop in JS has no independent scope and no closure object. So we can be sure that the root cause of this strange problem is the smart optimization of some browsers

Maybe you don’t quite understand where the difference of test results comes from… The answer is that test is the same as exec if there is / G after the direct quantity. If the global global search parameter is set, then the same test object will record the index position of the last matching character. The next matching will start from this position. If not, the matching index will be < 0 It still starts with the 0 position character

So it’s OK to use exec in the above test

So how to avoid browser differences here? The simple way is to remove / g

In order to avoid the trap, we must remember a convention. Please try not to use a regular direct quantity in the function body or loop. If so, please use new regexp (‘\ d’, g); this

For exec, try to use string.match Instead. Because match forces you to rely on whether or not there is / g for global search.. no ambiguity

For test, if it is in loop, you can also consider var reg = / – D /;//Please don’t forget

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

In fact, this is the most reasonable way. The reason is that we only generate a regular object and use it repeatedly. Essentially, it is also for optimization. But we avoid the different results caused by the browser’s own optimization differences

Finally, we find that the so-called trap is mainly caused by improper use of / g. This is true for both exec and test. If / G is used reasonably, the execution result will be correct no matter whether the browser has abnormal optimization or not… The only difference is that the optimized browser does not need to generate a regular object and then garbage collection Generate a regular object again… So repeatedly

Then we find that if we abide by the above principles, this kind of problem can also be avoided