作为一个一直做收银台技术业务的人,对这个问题也是耿耿于怀。本以为简单的toFixed可以解决一切,其实不然,翻看各大论坛,就这个话题给出一个完美解决方案。
先明白原因
浮点数运算后的精度问题
1 | // 加法 ===================== |
toFixed不是万能
在遇到浮点数运算后出现的精度问题时,刚开始我是使用toFixed(2)来解决的,因为在W3school上明确写着定义:toFixed()方法可把Number四舍五入为指定小数位数的数字。
但是在chrome下测试结果不太令人满意:1
2
3
4
5
61.35.toFixed(1) // 1.4 正确
1.335.toFixed(2) // 1.33 错误
1.3335.toFixed(3) // 1.333 错误
1.33335.toFixed(4) // 1.3334 正确
1.333335.toFixed(5) // 1.33333 错误
1.3333335.toFixed(6) // 1.333333 错误
而IE确实正确的1
2
3
4
5
61.35.toFixed(1) // 1.4 正确
1.335.toFixed(2) // 1.34 正确
1.3335.toFixed(3) // 1.334 正确
1.33335.toFixed(4) // 1.3334 正确
1.333335.toFixed(5) // 1.33334 正确
1.3333335.toFixed(6) // 1.333334 正确
果然IE才是爸爸。难道是浏览器兼容性问题?兼容性问题难道不应该是出在IE中吗?既然找到问题所在,就好下手
为什么会产生
让我们来看一下为什么0.1+0.2会等于0.30000000000000004,而不是0.3。首先,想要知道为什么会产生这样的问题,那就回忆一下计算机组成原理。虽然已经全部还给大学老师了,但是没关系,我们还有百度嘛。
浮点数的存储
和其它语言如Java和Python不同,JavaScript中所有数字包括整数和小数都只有一种类型 — Number。它的实现遵循 IEEE 754 标准,使用64位固定长度来表示,也就是标准的 double 双精度浮点数(相关的还有float 32位单精度)。
这样的存储结构优点是可以归一化处理整数和小数,节省存储空间。
64位比特又可分为三个部分:
符号位S:第 1 位是正负数符号位(sign),0代表正数,1代表负数
指数位E:中间的 11 位存储指数(exponent),用来表示次方数
尾数位M:最后的 52 位是尾数(mantissa),超出的部分自动进一舍零
浮点数的运算
那么JavaScript在计算0.1+0.2时到底发生了什么呢?
首先,十进制的0.1和0.2会被转换成二进制的,但是由于浮点数用二进制表示时是无穷的:1
20.1 -> 0.0001 1001 1001 1001...(1100循环)
0.2 -> 0.0011 0011 0011 0011...(0011循环)
IEEE 754 标准的 64 位双精度浮点数的小数部分最多支持53位二进制位,所以两者相加之后得到二进制为:1
0.0100110011001100110011001100110011001100110011001100
1 | /*** method ** |