Number.toString 在 Firefox 和 Chrome 中的不同精度答案

【问题标题】：Number.toString different prescision in Firefox and ChromeNumber.toString 在 Firefox 和 Chrome 中的不同精度
【发布时间】：2014-05-27 14:30:37
【问题描述】：

这个简单的代码(1/3).toString(17).length 在 Firefox(16) 和 chrome(1101) 中输出不同的数字。

http://jsfiddle.net/3uLVw/

我正在寻找为什么 Chrome 和 Firefox 的 Number.toString 实现不同的解释。

【问题讨论】：

两种情况下的确切输出是什么？
@JanDvorak，chrome = 1101，ff = 16，我想。因为我在 Chrome 的控制台中得到了 1101
哇。那是很多个七进制数字......也许是一个错误？
toString(17) 一定是导致问题的原因...如果将其删除，则数字的长度相同。以下还返回不同的字符串(1/3).toString(17) ... firefox 似乎以某种方式舍入了数字。我没有理由为什么... jsfiddle.net/3uLVw/1
@Adween base 19、23 等似乎也引发了这个问题...jsfiddle.net/3uLVw/2 ...问题是这有多相关。

标签： javascript google-chrome firefox tostring

【解决方案1】：

Chrome 为某些碱基提供了荒谬的数字。使用常见的基数 2、8、10 和 16 可以正常工作，但许多其他基数给出的数字远远超出了 Number 类型所能达到的精度。

测试用例：https://code.google.com/p/chrome-browser/source/browse/trunk/src/webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/js/number-toString-expected.txt?spec=svn7140&r=7140

【讨论】：

知道为什么会这样或者它是否是一个错误？是否有针对异常碱基的正确行为的规范？
@JanDvorak：这当然是一个错误，因为结果是不合理的。规范（ECMA-262 edition 5.1）15.7.4.2 说该算法是依赖于实现的，但它应该是 9.8.1（Number.toString()）中算法的概括，它基本上说位数应该尽可能小以完全精确地再现数字。
我将您的答案解读为“按设计 - 这是对来源的测试”
@Viller：是的，他们是这样编写代码的，而且当时可能只测试了最常见的碱基，后来发现其他碱基不能以最佳方式工作。因为他们知道这个问题并且还没有解决它，是因为它的优先级很低。