Зачем кому-то эта функция ведет себя как это (возвращают целое число, даже если оно не является точным представление переданной строки)?
Поскольку большую часть времени (на сегодняшний день) вы работаете с базовыми 10 номеров, и в этом случае JS может просто отливать - не разобрать - строку в число. (edit: По-видимому, не только base-10, см. обновление ниже.)
Поскольку JS динамически типизирован, некоторые строки работают отлично, как цифры без какой-либо работы с вашей стороны. Например:
"21"/3; // => 7
"12.4"/4; // => 3.1
Нет необходимости parseInt там, потому что "21" и "12.4" существу номера уже. Если, однако, строка была "12.4xyz", тогда вы действительно получили бы NaN при делении, так как это явно не число и не может быть неявно брошено или принуждено к одному.
Вы также можете явно «отличить» строку до номера с помощью Number(someString).
Хотя он также поддерживает только базу 10,
, он действительно вернет NaN для недопустимых строк.
Так как JS уже имеет неявный и явный тип casting/conversion/coercion, то роль parseInt не должна быть еще одной функцией кастинга другого типа.
parseInt роль будет, а, парсинг функция. Функция, которая изо всех сил пытается понять ее вклад, возвращая все, что может. Для вас, когда у вас есть строка, вы не можете просто бросить, потому что это не совсем отлично. (И, как основной синтаксис JS, он напоминает C, так как ответ apsillers объясняется красиво.)
И поскольку это синтаксический анализатор, а не функция кастинга, у него есть дополнительная функция, позволяющая обрабатывать другие базы, чем 10 .
Теперь, вы можете спросить, почему не строгая
литья функции, которая не основание 10 числа, и будете жаловаться, как вы хотите, но ... эй, там просто нет. Дизайнеры JS просто решили, что
parseInt хватит, потому что, опять же, 0x63 процента времени, вы имеете дело с базой 10.
Ближайший вы можете получить на «кастинг», вероятно, что-то ужасно Hacky как:
var hexString = "dsff66";
var number = eval("0x" + hexString); // attempt to interpret as a hexadecimal literal
which'll бросить
SyntaxError, потому что
0xdsff66 не является допустимым шестигранной буквальным.
Update: Как Lekensteyn указывает в комментариях, появляется JS правильно отливать 0x -prefixed строки шестнадцатеричных тоже. Я не знал этого, но на самом деле это, кажется, работает:
1 * "0xd0ff66"; // => 13696870
1 * "0xdsff66"; // => NaN
, что делает его самым простым способом бросить шестигранную строку в число - и получите NaN, если он не может быть должным образом представлены.
Такое же поведение относится к Number(), например Number("0xd0ff66") возвращает целое число, а Number("0xdsff66") возвращает NaN.
(/обновление)
В качестве альтернативы, вы можете проверить строку заранее и вернуться NaN при необходимости:
function hexToNumber(string) {
if(!/^(0x)?[0-9a-f]+$/i.test(string)) return Number.NaN;
return parseInt(string, 16);
}
Обратите внимание, что если вы делаете что-то вроде 'ParseInt ("2foo", 10) 'вы получаете' 2'. Это так, как ожидалось. Он анализирует до первого нечислового символа –
* На мой взгляд, он должен вернуть NaN. Может кто-нибудь объяснить мне, почему это не так? * Потому что спецификация говорит, что это не должно. И, к сожалению, мое мнение или ваше не имеет значения для спецификации. –
'Если parseInt встречает символ, который не является цифрой в указанном радиусе, он игнорирует его и все последующие символы и возвращает целочисленное значение, обработанное до этой точки. Источник: https://developer.mozilla.org/en- US/docs/Web/JavaScript/Reference/Global_Objects/parseInt –