为什么八进制文字不能作为字符串转换为数字？ [英] Why doesn't an octal literal as a string cast to a number?

问题描述

在JavaScript中，为什么将八进制数字串转换为十进制数？我可以使用 Number（）或 + 来转换十六进制文字字符串，为什么不是八进制？

In JavaScript, why does an octal number string cast as a decimal number? I can cast a hex literal string using Number() or +, why not an octal?

例如：

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

我知道我可以用<$ c $解析c> parseInt（0100[，8]），但我想知道为什么cast不能像hex和dec数一样工作。

I know I can parse with parseInt("0100" [, 8]), but I'd like to know why casting doesn't work like it does with hex and dec numbers.

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

Also, does anyone know why octal literals are dropped from ECMAScript 5th Edition in strict mode?

推荐答案

我对这个问题有点迟，但我想我能给出一个好的答案。

I'm a bit late to the question but I think I can give a good answer.

接受的答案并没有告诉你更多你真正知道的东西，并在问题本身中提及：数字（值）作为 +值但是而不是 parseInt（value）。

The accepted answer doesn't tell you anything more that what you actually know, and mention in the question itself: Number(value) works as +value but not as parseInt(value).

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

The key is to know that there is a semantic difference between type conversion and parsing.

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

Why does an octal number string cast as a decimal number?

因为作为函数调用的数字构造函数（数字（值））和一元 + 运算符（ + value ）在幕后使用 ToNumber 内部操作。这些结构的目的是类型转换。

Because the Number constructor called as a Function (Number(value)) and the Unary + Operator (+value) behind the scenes use the ToNumber internal operation. The purpose of those constructs is type conversion.

当 ToNumber 应用于字符串类型使用特殊的语法生成，称为 StringNumericLiteral 。

此产品只能包含十进制文字和十六进制整数文字：

This production can hold only Decimal literals and Hexadecimal Integer literals:

...

StrNumericLiteral :::
   StrDecimalLiteral
   HexIntegerLiteral

...

这个语法和正常的语法之间也存在语义差异 NumericLiterals 。

There are also semantic differences between this grammar and the grammar of "normal" NumericLiterals.

A StringNumericLiteral ：

• 可以在空格和/或行终止符之前和/或之后。


• 即十进制可以包含任意数量的前导0位数。 _{no octals！}


• 这是小数，可以在+或 - 前面表示其符号。


• 那是空的或仅包含空格转换为+0。

• May be preceded and/or followed by white space and/or line terminators.
• That is decimal may have any number of leading 0 digits. _{no octals!}
• That is decimal may be preceded by + or − to indicate its sign.
• That is empty or contains only white space is converted to +0.

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

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

The purpose of those functions obviously is parsing, which is semantically different to type conversion, for example:

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

值得一提的是 parseInt ECMAScript第5版规范，它不再将数字的基数解释为八进制只是为了具有前导零：

Is worth mentioning that the algorithm of parseInt changed in the ECMAScript 5th Edition Specification, it no longer interprets a number's radix as octal just for having a leading zero:

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

如你所见，这引入了 ES3和ES5实现之间的行为不兼容，并且建议始终使用radix参数，以避免任何可能问题。

As you can see, that introduced an incompatibility in the behavior between ES3 and ES5 implementations, and as always is recommended to use the radix argument, to avoid any possible problems.

现在你的第二个问题：

为什么八进制文字被删除ECMAScript第5版是严格模式吗？

Why octal literals are dropped from ECMAScript 5th Edition in strict mode?

实际上，自1999年以来，这种摆脱八进制文字的努力来自八进制文字作品（ OctalIntegerLiteral 和 OctalEscapeSequence ）已从 NumericLiteral s的语法中删除自 ECMAScript第3版规范以来，可能包含在< a href =http://bclary.com/2004/11/07/#annex-b =noreferrer>向后兼容性（<使用旧版本标准的href =http://ecma262-5.com/ELS5_HTML.htm#Annex_B =noreferrer>也在ES5中。

Actually, this effort of getting rid of octal literals comes since 1999. The octal literal productions (OctalIntegerLiteral and OctalEscapeSequence) were removed from the grammar of NumericLiterals since the ECMAScript 3rd Edition specification, they might be included for backwards compatibility (also in ES5) with older versions of the standard.

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

In fact, they are included in all major implementations, but technically an ES3 or ES5 compliant implementation could choose to not include them, because they are described as non-normative.

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

That was the first step, now ECMAScript 5 Strict Mode disallows them completely.

但为什么？

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

Because they were considered to be an error prone feature, and in fact, in the past they caused unintentional or hard to catch bugs — just as the same problem of implicit octals of parseInt —.

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

Now, under strict mode an octal literal will cause a SyntaxError exception — currently only observable in Firefox 4.0 Betas —.

这篇关于为什么八进制文字不能作为字符串转换为数字？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！