var a = parseInt("09"), b = Number(" 09");
Many people will think that the values of a and b are both the number 9, but in fact they are not.
The main function of parseInt is to convert a string into an integer, or convert a decimal into an integer. Normally, we only use its first parameter. But in fact, it has two parameters:
parseInt(string, radix)
parseInt will be converted according to the base specified by radix, such as:
alert(parseInt("10", 2)); // outputs '2'
When radix is not specified or radix is 0, parseInt will be converted to decimal. However, this is a bit special in some cases:
* If the string value starts with "0x", parseInt will convert in hexadecimal;
* If the string value starts with "0" At the beginning, parseInt will convert to octal.
Going back to the beginning of the code, since "09" starts with "0", parseInt will be converted according to octal, but "9" is not a legal octal value (octal only has eight digits 0-7) , so the conversion result is 0.
To avoid this trap, you can force specify radix:
alert(parseInt("09", 10)); // outputs '9'
Additional comments from other netizens:
Look at the code:
alert(parseInt(0.000001));
alert(parseInt(0.0000001));
The first statement outputs 0, the second statement outputs 1, embarrassing.
Continue to look at the code:
alert( parseInt('0.000001'));
alert(parseInt('0.0000001'));
all output 0, which is in line with expectations.
Looking at the ECMA-262 specification, parseInt will first call the toString method. The problem has gradually become clear:
alert(0.000001);
alert(0.0000001);
The first statement is output as it is, and the second statement is output 1e-7.
Continue to check ECMA-262 9.8.1 ToString Applied to the Number Type 1 Festival, suddenly realized:
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 the V8 engine number-tostring. A good interpretation of the ECMA specifications.
Summary: For values less than 1e-6, ToString will automatically convert to scientific notation. Therefore, when the parameter type is uncertain, it is best to encapsulate the parseInt method:
function parseInt2(a) {
if(typeof a === 'number') {
return Math.floor(a);
}
return parseInt(a);
}
The article above blueidea:
A thing I made in November last year suddenly went wrong in August or September this year
After debugging for 1x minutes, I finally found that it was a problem with parseInt
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.
Use parseInt on the date, such as 2005-10-08. Use regular expressions to solve the year Month and day strings, and then use parseInt to decode the numbers for other uses.
]
If you need to introduce external Js, you need to refresh to execute
]
The above is different. What?
The "08" string is recognized as octal, and parseInt("08") returns 0, because there is no 8 in octal.Generally, parseInt will not be used to write the following radix. The default is decimal Now it seems that everyone should be more diligent and write more 10 to be safe.