为什么 Number(''） 返回 0 而 parseInt(''） 返回 NaN

Why does Number('') returns 0 whereas parseInt('') returns NaN

本文关键字：返回 parseInt NaN Number 为什么      更新时间：2023-09-26

我在StackOverflow上经历了类似的问题和答案，发现这个：

parseInt("123hui")
returns 123
Number("123hui")
returns NaN

因为，parseInt()解析到第一个非数字并返回它解析的任何内容，Number()尝试将整个字符串转换为数字，为什么在parseInt('')和Number('')的情况下不太可能的行为。

我觉得理想情况下parseInt应该像Number("123hui")一样返回NaN

现在我的下一个问题：

当0 == ''返回true我相信它解释得像0 == Number('')这是真的。那么编译器真的像对待0 == Number('')而不是0 == parseInt('')一样对待它，还是我错过了一些要点？

差异部分是由于Number()使用额外的逻辑进行类型强制。它遵循的规则包括：

  • 空的或仅包含空格的字符串数字文本将转换为 +0。

而parseInt()被定义为根据给定或检测到的radix简单地查找和评估输入中的数字字符。并且，它被定义为至少需要一个有效字符。

13(如果S包含的代码单元不是基数R数字，则让Z是S的子字符串，由第一个这样的代码单元之前的所有代码单元组成;否则，设 Z 为 S。

14( 如果 Z 为空，则返回 NaN。

注意：">S"是删除任何前导空格后的输入字符串。

随着0==''回归true我相信它的解释就像0==Number('') [...]

==使用的规则被定义为抽象相等。

而且，您对所使用的胁迫/转换是正确的。相关步骤是#6：

如果 Type(x( 是 Number 且 Type(y( 是 String，
返回比较结果 x == ToNumber(y(。

要回答您关于返回 true 0==''的问题：

下面是数字和字符串的比较：

等于运算符 (==( 

Type (x) Type(y)              Result
-------------------------------------------
x and y are the same type      Strict Equality (===) Algorithm
Number  String                 x == toNumber(y)

和 toNumber 对字符串参数执行以下操作：

toNumber:
Argument type    Result
------------------------
String          In effect evaluates Number(string)
                 “abc” -> NaN
                 “123” -> 123

Number('')返回0 .因此，这为您提供了使用严格相等(===(算法进行评估0==0

严格等于运算符 (===(

Type            values                        Result
----------------------------------------------------------
Number       x same value as y                true
             (but not NaN)

你可以找到完整的列表@javascriptweblog.wordpress.com - truth-equality-and-javascript。

parseInt("")之所以NaN，是因为即使+""是0，标准也是这样说的(也仅仅是因为标准是这样说的，例如暗示"" == 0(。

不要在这里寻找逻辑，

因为没有深刻的逻辑，只有历史。

在我看来，你犯了一个大错误...你越早纠正它，对你用Javascript编程生活就越好。错误在于，你假设编程语言中的每一个选择以及关于它们的每一个技术细节都是合乎逻辑的。这根本不是真的。

特别是对于Javascript。

请记住，Javascript是在匆忙中"设计"的，只是因为命运，它在一夜之间变得非常流行。这迫使社区在认真考虑细节之前对其进行标准化，因此在现场进行任何认真测试之前，它基本上被"冻结"在目前的悲伤状态中。

有些部分太糟糕了，甚至不好笑(例如 with语句或==相等运算符是如此破碎，以至于严肃的 js IDE 警告使用它的任何使用：即使只使用正常值，也没有任何"特殊"值，如 null、undefined、NaN 或空字符串，你会得到像 A==B、B==C 和 A!=C 这样的东西""而不是因为精度问题(。

废话的特殊情况在Javascript中无处不在，不幸的是，试图将它们放在逻辑框架中是浪费精力。只需通过大量阅读来了解它的奇怪之处，并享受它提供的梦幻般的运行时环境(这是 Javascript 真正闪耀的地方......浏览器及其JIT是一项真正令人印象深刻的技术：您可以编写几行代码，并在大量不同的计算设备上运行真正有用的软件(。

列举所有怪事的官方标准很难阅读，因为旨在非常准确，不幸的是，它必须指定的规则非常复杂。

此外，随着语言获得更多功能，规则将变得越来越复杂：例如，ES5 只是另一种奇怪的"特殊"情况(例如 ToPrimitive Date对象的操作行为(在 ES6 中成为"正常"情况(可以自定义ToPrimitive(。

不确定这种"正常化"是否值得高兴......真正的问题是冻结的起点，现在没有简单的解决方案(如果你不想扔掉所有现有的JavaScript代码，那就是(。

一门语言的正常路径是干净、漂亮、对称、小。然后，当面对现实世界的问题时，语言会获得(被(一些丑陋的部分(因为世界是丑陋和不对称的(。

Javascript就是这样。除了它开始的时候并不漂亮干净，而且在把它扔进游戏之前没有时间打磨它。

相关文章：