Regular Expression traps in browsers

JS built-in object Regexp we use very comfortable and comfortable, but there are serious hidden dangers or traps... the reason is that some browsers directly optimize regular expressions.

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

The Optimization of the direct amount of strings in C # is very thorough... we should welcome this optimization...

String STR = "Franky ";

String str2 = "Franky ";

There is only one string object in the memory, and STR and str2 have the same reference. Obviously this is quite reasonable.

String n = "Franky", n2 = "Franky ";
Response. Write (object. referenceequals (n, N2). tostring (); // true.

In some special cases, Some browsers have made similar optimizations for the direct amount of regular expressions.

Alert (/\ D/==/\ D /); // all browsers are false. This is reasonable because the direct amount of regular expressions is the same as the direct amount of [] arrays {} objects.

Let's take a look at which browsers have been optimized.

Function F2 (){
Return/\ D /;
}

Alert (F2 () = F2 ());

// The results here are different.

IE6 + opear10 + safari3 + and chrome7 + both return false

Firefox3.6-chrome6-opear9.6-maxthon3 beta version returns true if WebKit engine is used.

The interesting thing is that opera10 canceled the optimization after opera9 was optimized. It seems that at least the opera team thought the optimization was inappropriate... (in disguise, it supported my opinion .)

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

Let's take a look at the following example:

For (VAR I = 0; I <10; I ++) document. writeln (/\ D/g. Test (''+ I ));

The differences in the output results of different browsers fully match the classification of the above optimization.

That is, if the browser is not optimized, true is returned. If the browser is optimized, true or false is returned.

Here we are just a loop. The loop in. js does not have an independent scope and will not generate closure objects. So the root cause of this weird problem is that some browsers perform smart optimization.

You may not understand the differences between the test results... the answer is that test is the same as exec. if the global search parameter is set, the same test object records the index position of the last matched character. the next matching will start from this position .. if not, the index is matched. <0 the next time the index is matched, the index starts from 0.

Therefore, the above test can also use exec.

So how can we avoid browser differences? Simply remove/g

Here we need to remember an agreement to avoid traps. try not to use a regular expression in the function body or in a loop. use new Regexp ('\ d', G.

Try to use string. Match instead of exec. Because match forces you to use/g for global search... it will not produce ambiguity.

If the test is in a loop, you can also consider var Reg =/\ D /;// Here./g. Do not forget it.

For (VAR I = 0; I <10; I ++) document. writeln (Reg. Test (''+ I ));

In fact, this is the most reasonable method. The reason is that we only generate a regular object and use it repeatedly. In essence, it is also for optimization. However, we avoided the different results caused by browser optimization differences.

Finally, we found that the so-called traps mainly occur due to improper use of/g. whether it is Exec or test, if you use/g properly, no matter whether the browser has abnormal optimization. the execution results will all be correct... the only difference is that the optimized browser does not need to repeatedly generate a regular object and then recycle it to generate a regular object .... this is repeated...

So we found that this problem was also avoided if we followed the above principles...

Correct one statement:

The so-called optimization statement is incorrect. Recently, through the translation of ecma262 edition3 and edition5, we found many corners that were not carefully read before, but these corners have important information.For example, the browser's optimization of the direct amount of regular expressions is essentially strict compliance with the ecma262 edition3 standard, because edition3 explicitly states thatProgramIn the lexical analysis period, when a regular expression is directly scanned, A Regexp object is generated ). during running, the execution of this direct amount only produces a reference to the original object. instead of creating a new Regexp object. this illustrates the nature of the problem.

Ecma262 edition5 makes a change. That is, a Regexp object is generated every time a direct volume is executed.

In the end, it is not a problem of abnormal optimization, but a PK of the new and old standards. Of course, the old saying is that it is based on edition3.