如何處理無效的正則表達式轉義？

我最近創建了一個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行爲？

來源

2016-11-18 Nicholas Wilson

標題爲ECMAScript IdentityEscape is ambiguous的規格存在問題。還有的討論表明，瀏覽器都使用這個規則來解決這個問題：

IdentityEscape :: 
SourceCharacter but not c

事實上，我可以證實MSDN列出的修補程序。

請記住，該規範規定：

SourceCharacter :: 
any Unicode code unit

所以網上有指\,，\z和\u可以匹配存在。但不是\c。

CharacterEscape :: 
    ControlEscape 
    c ControlLetter 
    HexEscapeSequence 
    UnicodeEscapeSequence 
    OctalEscapeSequence 
    IdentityEscape

具體做法是：：

UnicodeEscapeSequence :: 
u HexDigit HexDigit HexDigit HexDigit

但爲什麼c

\u，當然，只有當它無法比擬這裏匹配？可能是因爲它是特殊（他們可能忘記了它們在c ControlLetter下被覆蓋）。根據Regex101.com：

\cY匹配通常與Control + A到Control + Z：\ x01到\ x1A相關聯的ASCII字符。

Regex101.com還介紹瞭如何\c解析：（我懷疑，Firefox可能治療\u下同）

\c字符\c字面上（區分大小寫）

匹配

...除非您使用u修飾符。在這種情況下，忘記一切，因爲\u和\c就是錯誤。

在PCRE中（其中\u和\c具有相同的含義），這些正則表達式在有和沒有u修飾符時都是錯誤。至少在我看來，這種行爲是「正確的」。

底線：不要轉義定義不清和應該是錯誤。
避免它們。

來源

2016-11-18 18:47:10 Laurel

我會接受答案，但爲了記錄，就我個人而言，ECMAScript規範定義了瀏覽器的「正確」，而不是PCRE的行爲 - 也不關心「應該是「錯誤。 ECMAScript 6中規範附錄B的鏈接解釋了瀏覽器正在做什麼（即它是ECMAScript 5的故意違反，隨後作爲ES6中允許的行爲添加）。 –

如何處理無效的正則表達式轉義？

回答

相關問題