为什么八进制文字不作为字符串转换为数字？

Question

在 JavaScript 中，为什么八进制数字字符串会转换为十进制数字？我可以使用 Number() 或 + 转换十六进制文字字符串，为什么不转换八进制呢？

例如：

1000 === +"1000" // -> true
0xFF === +"0xFF" // -> true
0100 === +"0100" // -> false - +"0100" gives 100, not 64

我知道我可以使用 parseInt("0100" [, 8]) 进行解析，但我想知道为什么转换不能像处理十六进制和十进制数字那样工作。

另外，有谁知道为什么八进制文字在严格模式下从 ECMAScript 第五版中删除？

Answer 1

我的问题有点晚了，但我想我可以给出一个很好的答案。

接受的答案不会告诉您更多您实际知道的内容，并在问题本身中提到： Number(value) 用作 +value 但不用作 parseInt(值)。

关键是要知道类型转换和解析之间存在语义差异。

为什么八进制数字字符串会转换为十进制数字？

因为 作为函数调用的 Number 构造函数 (Number(value)< /code>) 和 一元 + 运算符 ( +value) 在幕后使用 ToNumber内部操作。这些构造的目的是类型转换。

当 ToNumber 应用于字符串类型时，一个特殊的使用称为StringNumericLiteral的语法产生式。

此产生式只能保存十进制文字和十六进制整数文字：

...

StrNumericLiteral :::
   StrDecimalLiteral
   HexIntegerLiteral

...

此语法与“正常”语法 数字文字。

A StringNumericLiteral：

• 前面和/或后面可以有空格和/或行终止符。
• 即小数可以有任意数量的前导 0 数字。 _{没有八进制！}
• 即十进制前面可以加 + 或 − 来指示其符号。
• 即为空或仅包含空格时将转换为+0。

现在我将使用 parseInt 和 parseFloat 函数。

这些函数的目的显然是解析，这在语义上与类型转换不同，例如：

parseInt("20px");     // 20
parseInt("10100", 2); // 20
parseFloat("3.5GB");  // 3.5
// etc..

值得一提的是parseInt 在 ECMAScript 第五版规范中进行了更改，它不再仅仅因为有一个前导零就将数字的基数解释为八进制：

parseInt("010"); // 10, ECMAScript 5 behavior
parseInt("010"); // 8,  ECMAScript 3 behavior

如您所见，这引入了 ES3 和 ES5 实现之间的行为不兼容，并且一如既往地建议使用基数参数，以避免任何可能的问题。

现在你的第二个问题：

为什么八进制文字在严格模式下从 ECMAScript 第五版中被删除？

实际上，这种摆脱八进制文字的努力始于 1999 年。八进制文字产生式（OctalIntegerLiteral 和 OctalEscapeSequence）已从 NumericLiteral 语法中删除> 自 ECMAScript 第三版规范以来，它们可能被包含在内向后兼容性 (也在 ES5 中）以及旧版本的标准。

事实上，它们包含在所有主要实现中，但从技术上讲，符合 ES3 或 ES5 的实现可以选择不包含它们，因为它们被描述为非规范。

这是第一步，现在 ECMAScript 5 严格模式 完全不允许它们。

但为什么？

因为它们被认为是容易出错的功能，事实上，在过去它们会导致无意或难以捕获错误 - 就像与 parseInt 的隐式八进制相同的问题 —。

现在，在严格模式下，八进制文字将导致 SyntaxError 异常 - 目前仅在 Firefox 4.0 Betas 中观察到 -。

Answer 2

因为你实际上并没有执行正确意义上的转换（JS 没有转换）——这只是类型杂耍。

当您在 Javascript 中拥有任何文字并对其执行方法时，就会在幕后为您创建一个对象。

例如，"foo".toUpperCase() 被替换为大致如下所示的代码评估 new String( "foo" ).toUpperCase();

字符串不能使用一元 + 运算符进行计算，JS 将字符串转换为数字 - 并且它不使用 parseInt() 或 parseFloat() 内部 - 你猜对了 - 它使用 Number() 。

因此，您看到的值就是您从 Number 返回值中看到的值()，它似乎不采用八进制。

Answer 3

详细说明为什么 ES5 中删除了八进制支持，主要是因为对于新手或非程序员来说，语法是意想不到的。想象一下垂直对齐一系列数字（可能是相加的），例如使用前导零来对齐它们——如果您的数字不使用 8 或 9，它们最终将被视为八进制。突然间，您的代码无缘无故地消失了！这就是删除八进制支持的原因。如果不会造成这样的不幸的话，有一天可能会添加不同的八进制语法（我想我记得看到 0o755 作为一个稻草人的想法），但现在八进制已经过时了。

关于过去回复中提到的不兼容的 parseInt 更改：没有实现进行此更改，并且我怀疑没有实现会做出此更改。 ES5 大部分是基于现实的。它的新功能通常不会破坏不尝试使用新功能的现有代码（当然，新代码在使用新功能时必须注意不要破坏现有代码作为该使用的一部分）。它的不兼容性也大多可以忽略不计，或者它们是无关紧要的，因为现实世界的实现出于兼容性原因而轻率地忽略了规范。但并非所有的不兼容都是有充分根据的：有些不兼容更多的是出于愿望而不是协调。对 parseInt 的更改是一个理想更改的示例。它打破了现有的代码，需要八进制语法，没有显式基数，解析为八进制。

在几天的时间里，SpiderMonkey（Mozilla 的 JavaScript 引擎）实现了一个中途更改，使 parseInt 在从严格模式代码调用时忽略八进制，并在不从严格模式代码调用时支持八进制。这更接近 ES5 想要的，但它显然是把非严格代码转换为严格模式的障碍，它可能会让用户感到困惑，而且——也许对实现者来说最有趣的是——这意味着你无法实现 < JavaScript 本身中的 code>parseInt （因为规范中没有办法检查调用函数的严格性），这在将来的某个时候可能是需要的（以减少攻击面、简化实现等）。所以我们取消了依赖。 （我编写了补丁来使 parseInt 依赖于调用者，并且我审查了该补丁以撤消它，这是在我的初始补丁落地后通过进一步讨论产生的。） parseInt 现在符合又是 ES3，考虑到 Web 的现状，并且 ES5 的语义可能与其不兼容，我怀疑我们会做出改变。因此我怀疑其他人也会改变。 （我也很确定他们会同意我们对 ES5 在 parseInt 中禁止隐式八进制语法的网络不兼容程度的估计，并且可能也同意我们的其他原因。即使我们要改变，我不确定他们会跟随，但我怀疑他们不这样做是明智的。）