JavaScript八进制转义序列的正确解析

Question

根据ECMA规范，八进制转义序列定义为

OctalEscapeSequence ::  
    OctalDigit [lookahead ∉ DecimalDigit]  
    ZeroToThree OctalDigit [lookahead ∉ DecimalDigit]  
    FourToSeven OctalDigit  
    ZeroToThree OctalDigit OctalDigit  

ZeroToThree :: one of
    0 1 2 3

FourToSeven :: one of
    4 5 6 7

根据这个规范，字符串"\379"不是八进制转义\37，后面是9。我看得对吗？它不符合第一条规则，因为7是一个十进制数字。它不能满足第二个，因为9是一个十进制数字。它不能满足第三个，因为三个不是4 5 6 7之一。最后，它不满足第四个，因为9不是一个八进制数字。

那么，"\379"的价值是什么呢？我试过几个JavaScript翻译器，他们把它解释为八进制转义\37，然后是9。这是口译员的错误吗？

更新

我知道八进制转义序列在最新的ECMA规范中是可选的。

Answer 1

八进制转义序列不是现代浏览器实现的官方规范的一部分。

B.1附加语法 过去版本的ECMAScript包含了用于指定八进制文字和八进制转义序列的附加语法和语义。这些已经从ECMAScript的这个版本中删除了。该非规范附件为八进制文字和八进制转义序列提供了统一的语法和语义，以便与一些较旧的ECMAScript程序兼容。

在严格的模式下，这是明确不允许的：

B.1.1数字文字 7.8.3的语法和语义可以按以下方式扩展，但这个扩展不允许用于严格模式代码

考虑到这一点，\379不是八进制转义序列，因为十进制数列的负前瞻-- \3和\37 --不被视为八进制转义序列。

这是一个语法错误，因为没有其他产品与之匹配。具体来说，

CharacterEscapeSequence ::
  SingleEscapeCharacter
  NonEscapeCharacter

(这就是导致"\-"等于"-"的原因)不适用，因为数字既不在SingleEscapeCharacter中，也不在NonEscapeCharacter中。

这是口译员的错误吗？

如果它只是在不严格的模式下发生，也许就不会了。允许口译员在第16章中定义其他语法：

实现可以扩展程序语法和正则表达式模式或标志语法。

解释器作者可能会证明它们是符合此行为的实现，它们只是扩展语法以支持八进制，其方式与B.1节所建议的不同。