正規表示式速查表

這是一張語法表，而不是教程

正規表示式天生就寫得很密。^(?:\d{1,3}\.){3}\d{1,3}$ 這樣一個模式，用三十來個字元就塞進了一個完整的 IPv4 校驗器——自己寫的時候很爽，讀別人寫的時候很痛苦。難點其實大多不在概念，而在於這套詞彙量大、寫法簡短，且極容易記個半吊子。

本頁就是這套詞彙的查詢表，按照實際構建模式的順序組織：匹配單個字元的寫法、如何自定義字元集合、如何表達「重複若干次」、在哪裡加錨點、怎樣分組與選擇，以及哪些標誌位會改變引擎行為。篩選框會同時搜尋記號、說明和示例，因此輸入「惰性」「boundary」或「lookbehind」都能直接跳到你記了一半的那一行。

這些記號遵循哪種方言

正規表示式並不是一種統一的語言。grep、PCRE、Python、Java、Go 的 RE2 和 JavaScript 共享一個核心，但在細節上各不相同。這裡列出的全部內容都以 ECMAScript 定義的 JavaScript 方言為準，因為那正是瀏覽器、Node.js 和絕大多數前端工具鏈所執行的方言。

有三處差異值得特別提醒。第一，後行斷言 (?<=...) 與 (?<!...) 在現代 JavaScript 引擎中受支援，但 Go 的 RE2 和較舊版本的 Safari 並不支援，因此依賴它的模式並非處處可移植。第二，JavaScript 沒有 x 詳細模式標誌，無法像 Python 那樣把模式拆成多行並加註釋；較長的模式通常改用字串片段拼接而成。第三，JavaScript 中的 \d 與 \w 預設只覆蓋 ASCII，因此 \w 不會匹配帶重音的字母或中日韓字元，除非配合 u 標誌改用 \p{L} 這類 Unicode 屬性轉義。

寫出可維護的模式

兩個習慣能避免絕大多數正則相關的痛苦。第一是有意識地加錨點。沒有錨點的模式會在字串的任意位置尋找匹配——掃描文本時這正是你要的，但做校驗時幾乎從來不是。加上 ^ 和 $，就把「包含某個看起來像日期的片段」變成了「本身就是一個日期」，而這條區別背後藏著相當比例的校驗缺陷。

第二是優先使用惰性量詞和排除型字元類，而不是貪婪通配。經典錯誤是在類 HTML 文本上寫 <.+>：由於 + 是貪婪的，它會一路吞到該行最後一個 >。寫成 <.+?>，或者更好的 <[^>]+>，才只匹配單個標籤。排除型字元類的版本還明顯更快，因為引擎完全不需要回溯。

最後要留意災難性回溯。像 (a+)+b 這樣巢狀量詞，可能讓引擎在得出「不匹配」結論之前，先嚐試指數級數量的切分方式；一旦這種模式接觸使用者輸入，一次校驗呼叫就變成了拒絕服務的攻擊面。如果模式裡有一個帶量詞的分組、內部又含量詞，就應該重寫它——通常改成「一個字元類加一個量詞」就能線上性時間內完成同樣的工作。而當模式長到超過一兩行時，坦白講，正確的工具往往是一個真正的解析器，而不是正則。