如何处理无效的regex转义？

Question

我最近创建了一个C++11 std::regex的实现，它通过了许多一致性测试。由于C++11 std::regex语法和语义是从ECMAScript 5.1派生出来的，所以我想我应该在浏览器上运行相同的测试，以检查这些行为是否匹配。

在处理无效的转义序列时，我发现了一些奇怪的差异。

/* As expected, matching the standard: */
/\,/.exec(",") -> [","]

/* Err... this should throw, it doesn't match any ECMAScript production:
   IdentityEscape := SourceCharacter but not IdentifierPart (ES 5.1)
                     SourceCharacter but not UnicodeIDContinue (ES 6.0) */
/\z/.exec("z") -> ["z"] (Chrome & Firefox!)

/* It even works for characters that have a defined meaning: */
/\u/.exec("u") -> ["u"] (Chrome)
                  null (Firefox)

/* Errr...! This is creepiest, it matches a backslash!!! */
/\c/.exec("\\c") -> ["\c"] (Chrome & Firefox!)

这些是在Chrome和Firefox中已知的一致性问题，还是符合以前/未来的ECMAScript行为？

Answer 1

有一个问题，规格名为ECMAScript IdentityEscape模棱两可。那里的讨论表明，浏览器正在使用这个规则来解决这个问题：

IdentityEscape :：SourceCharacter但不是c

实际上，我可以确认MSDN列出了修复程序。

请记住，规范规定：

SourceCharacter :：任何Unicode代码单元

因此，这里的行意味着\,、\z和\u可以在那里匹配。但不是\c。

当然，只有当\u不能在这里匹配时，它才会匹配：

CharacterEscape :：ControlEscape c ControlLetter HexEscapeSequence UnicodeEscapeSequence OctalEscapeSequence IdentityEscape

具体地说：

UnicodeEscapeSequence :：U HexDigit HexDigit

但为什么是c？可能是因为它是特殊的(而且他们可能已经忘记了，他们已经被c ControlLetter覆盖了)。据Regex101.com称：

\cY通过Control+Z：\x01到\x1A匹配通常与Control+A关联的ASCII字符。

Regex101.com还解释了如何解析\c：

\c与字符\c匹配(区分大小写)

(我怀疑火狐可能对\u也有类似的看法。)

...Unless --您正在使用u修饰符。在这种情况下，忘记一切，因为\u和\c本身就是错误。

在PCRE中，(其中\u和\c具有相同的含义)，这些正则表达式是带和不带u修饰符的错误。这种行为是“正确的”，至少在我的脑海里。

errors.底线:不必要的转义定义很差，应该是

避开他们.