Number.IsNaN()是否比isNaN()更坏？

Question

Soooooo isNaN显然在JavaScript中被打破了，比如：

isNaN('')
isNaN('   ')
isNaN(true)
isNaN(false)
isNaN([0])

当他们看起来都是..。不是数字..。

在ECMAScript 6中，草案包括了一个新的Number.isNaN，但看起来(海事组织)这也是坏的.

我希望

Number.isNaN('RAWRRR')

返回true，因为它是字符串，不能转换为数字.然而..。

​

​

看来我会考虑的事情..。不是一个数字，真的，不是一个数字.

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-isfinite-number

关于MDN的例子说：

Number.isNaN("blabla")；//例如，isNaN应该是这样的

我不明白为什么这是“原始的全局isNaN的更健壮的版本”。当我无法检查事物是否不是一个数字时。

这意味着我们仍然要做实际的类型检查以及检查isNaN.听起来很傻..。

http://people.mozilla.org/~jorendorff/es6-draft.html#sec-isnan-number

这里的ES3草案基本上说，一切都是错误的，除了它的Number.NaN

有没有其他人发现这是坏的，还是我只是不理解isNaN的意义？

Answer 1

isNaN()和Number.isNaN()都测试一个值是否是(或者，在isNaN()情况下，可以转换为一个表示NaN值的数字类型值)。换句话说，"NaN“并不仅仅意味着”这个值不是一个数字“，它的具体意思是”根据IEEE-754，这个值不是一个数字值“。

以上所有测试返回false的原因是，所有给定的值都可以转换为非NaN的数值。

Number('')    // 0
Number('   ') // 0
Number(true)  // 1
Number(false) // 0
Number([0])   // 0

isNaN()被“破坏”的原因是，表面上，在测试值时不应该发生类型转换。这就是Number.isNaN()设计要解决的问题。特别是，如果值是数字类型的值，Number.isNaN()只会尝试将该值与NaN进行比较。任何其他类型都将返回false，即使它们实际上是“非数字”，因为值NaN的类型是number。请参阅isNaN()和Number.isNaN()各自的MDN文档。

如果您只是想确定某个值是否属于数字类型，即使该值是NaN，也可以使用typeof：

typeof 'RAWRRR' === 'number' // false

Answer 2

不，原来的isNaN坏了。您不理解isNaN的意义。

这两个函数的目的是确定某物是否具有NaN值。这是因为something === NaN总是false，因此不能用来测试它。(附带说明：something !== something实际上是一个可靠的，尽管违背直觉的NaN测试)

isNaN中断的原因是，当一个值实际上不是NaN时，它可以返回NaN。这是因为它首先将值强制到一个数字。

所以

isNaN("hello")

是true，尽管"hello"不是NaN。

如果要检查某个值是否实际上是一个有限数，可以使用：

Number.isFinite(value)

如果要测试某个值是有限数还是字符串表示形式的值，可以使用：

Number.isFinite(value) || (Number.isFinite(Number(value)) && typeof value === 'string')

Answer 3

正如注释中提到的，isNaN()和Number.isNaN()都检查传入的值是否等于NaN值。这里的关键是NaN是一个实际值，而不是一个评估结果，例如"blabla"是一个String，值是"blabla"，这意味着它不是值"NaN"。

一个可行的解决办法是做如下事情：

Number.isNaN(Number("blabla")); //returns true.