Question

我已经在各种情况下使用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）

Answer 1

它实际上只能通过此输入失败：

testProof("NaN");

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

Answer 2

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

parseInt（）和parseFloat（）：第二个断言是否会失败？

2 个答案: