Summary of js parseInt trap Analysis

Copy codeThe Code is as follows: var a = parseInt ("09"), B = Number ("09 ");

Many people think that the values of a and B are numbers 9, but they are not.

ParseInt is mainly used to convert a string to an integer, or to convert a decimal point to an integer. Generally, we only use its first parameter. But in fact, it has two parameters:
ParseInt (string, radix)

ParseInt is converted according to the hexadecimal format specified by radix. For example:Copy codeThe Code is as follows: alert (parseInt ("10", 2); // outputs '2'

If radix or radix is not specified as 0, parseInt is converted in decimal format. However, this is somewhat special in some cases:

* If the string value starts with "0x", parseInt is converted in hexadecimal format;
* If the string value starts with "0", parseInt is converted to octal values.

Because "09" starts with "0", parseInt will be converted in octal format, but "9" is not a valid octal value (the octal value is only 0-7 digits), so the conversion result is 0.

To avoid this trap, you can forcibly specify radix:Copy codeCode: alert (parseInt ("09", 10); // outputs '9'

Supplemented by other netizens:
Check the Code:Copy codeThe Code is as follows: alert (parseInt (0.000001 ));
Alert (parseInt (0.0000001 ));

The first statement outputs 0, and the second statement outputs 1 and 3.

Continue to read the code:Copy codeCode: alert (parseInt ('0. 000001 '));
Alert (parseInt ('0. 0000001 '));

All outputs 0, which meets expectations.

View the ECMA-262 specification, parseInt first calls the toString method. The problem has been gradually clarified:Copy codeThe Code is as follows: alert (0.000001 );
Alert (0.0000001 );

The first statement is output as is, and the second statement is output as 1e-7.
Continued to review ECMA-262 9.8.1 ToString Applied to the Number Type section, suddenly realized:Copy codeThe Code is as follows: assertEquals ("0.00001", (0.00001). toString ());
AssertEquals ("0.000001", (0.000001). toString ());
AssertEquals ("1e-7", (0.0000001). toString ());
AssertEquals ("1.2e-7", (0.00000012). toString ());
AssertEquals ("1.23e-7", (0.000000123). toString ());
AssertEquals ("1e-8", (0.00000001). toString ());
AssertEquals ("1.2e-8", (0.000000012). toString ());

The above is the unit test script of V8 engine number-tostring, which is a good interpretation of ECMA specifications.

Conclusion: For values smaller than 1e-6, ToString is automatically converted to scientific notation. Therefore, when the parseInt method is not sure about the parameter type, it is best to encapsulate one layer:Copy codeThe Code is as follows: function parseInt2 (){
If (typeof a = 'number '){
Return Math. floor ();
}
Return parseInt ();
}

The above article on blueidea:
Something we did in has suddenly become faulty in.
After debugging for 1x minutes, we finally found the parseInt problem.

Description in MSDN
Description
Converts strings into integers.
Syntax
ParseInt (numstring, [radix])
The parseInt method syntax has these parts:
Part Description
[Numstring] Required. A string to convert into a number.
[Radix] Optional. A value between 2 and 36 indicating the base of the number contained in numstring. if not supplied, strings with a prefix of '0x 'are considered hexidecimal and strings with a prefix of '0' are considered octal. all other strings are considered decimal.

ParseInt is used on the date. For example, the year, month, and day strings are obtained using the regular expression at, and the numbers are obtained using the parseInt.
[Ctrl + A select all Note: If you need to introduce external Js, You need to refresh it to execute]

[Ctrl + A select all Note: If you need to introduce external Js, You need to refresh it to execute]

Are the differences shown above?
"08" string is identified as octal, and parseInt ("08") is 0, because there is no octal
Generally, parseInt is not used to write the following radix. The default value is decimal.
Now it seems that everyone is still hardworking, and it is only safe to write 10 more.