parseInt() 和 parseFloat()：第二个断言会失败吗？答案

【问题标题】：parseInt() and parseFloat(): Can this second assertion ever fail?parseInt() 和 parseFloat()：第二个断言会失败吗？
【发布时间】：2014-07-25 18:16:27
【问题描述】：

我在各种情况下使用parseInt() 和parseFloat() 已经有一段时间了，我想我知道这两者的来龙去脉。但是最近我有一个奇怪的想法，到目前为止我还无法确定地证明它。

考虑以下函数：

function testProof(strInteger) {
    assert(strInteger === '' + parseInt(strInteger, 10));

    assert(parseInt(strInteger, 10) === parseFloat(strInteger));
}

// Sample calls...
testProof("5");
testProof("109");
testProof("-55");

首先我们assert 将输入转换为整数，然后再转换回字符串会再次生成原始字符串。这可以防止parseInt("100bucks") 返回100 的情况，并且它还确保没有被转换截断的小数部分——我们要确保输入实际上是一个整数、整数字符串。

如果成功，那么我们 assert 即 parseInt(..., 10) 返回与 parseFloat(...) 相同的值。

第一个 assert 失败的原因有很多：

输入的不是整数 ("1.5")
输入有前导零 ("0050")
输入有尾随垃圾 ("100bucks")
输入采用指数表示法 ("1e3")，或者它太大而变成指数形式
输入不可解析，导致NaN
也许是其他人？

但问题是：只要第一个assert 通过，第二个assert 会失败吗？换句话说，如果我们提前知道输入是字符串中的整数，那么parseFloat(...) 可以作为parseInt(..., 10) 的替代品吗？（不是说这是一个好的替代品...... :-P）

【问题讨论】：

标签： javascript parseint proof parsefloat

【解决方案1】：

实际上只有这个输入才会失败：

testProof("NaN");

但如果你真的知道它是一个整数，为什么还要测试呢？此外，parseFloat 不能很好地替代 parseInt，因为在很多情况下，您不知道它是否真的是整数而不是浮点数。

【讨论】：

好收获！我从来没有考虑过尝试文字"NaN"。我同意，这可能是不应该做的事情；这更像是一种理论上的好奇心，看看是否存在两者行为不同的极端情况。
@smitelli 好吧，只有当您不知道字符串中的内容时，它们的行为才会有所不同。另一方面，如果你很确定它是一个字符串化的整数，那么使用+str 或str * 1 会容易得多。

【解决方案2】：

虽然我无法提供证明，但 JS 并没有区分整数和浮点数。 parseFloat 和 parseInt 之间的唯一区别是它们如何解释小数点之类的东西。但是，如果输入字符串是常规表示法中的有效整数（正如第一个断言所断言的那样），它们将始终产生相同的数值，这在 JS 中意味着它们也是相同的类型。

【讨论】：