正則表達式參考文檔
| 修訂歷史 | ||
|---|---|---|
| 修訂 V1.1 | DATE | April 26, 2008 |
製作DocBook格式的第一版 | ||
摘要
簡潔而全面的正則表達式參考文檔
正則表達式（regular expression）就是用一個“字符串”來描述一個特徵，然後去驗證另一個“字符串”是否符合這個特徵。比如 表達式“ab+” 描述的特徵是“一個 'a' 和 任意個 'b' ”，那麼 'ab', 'abb', 'abbbbbbbbbb' 都符合這個特徵。
正則表達式可以用來：（1）驗證字符串是否符合指定特徵，比如驗證是否是合法的郵件地址。（2）用來查找字符串，從一個長的文本中查找符合指定特徵的字符串，比查找固定字符串更加靈活方便。（3）用來替換，比普通的替換更強大
正則表達式學習起來其實是很簡單的，不多的幾個較爲抽象的概念也很容易理解。之所以很多人感覺正則表達式比較複雜，一方面是因爲大多數的文檔沒有做到由淺入深地講解，概念上沒有注意先後順序，給讀者的理解帶來困難；另一方面，各種引擎自帶的文檔一般都要介紹它特有的功能，然而這部分特有的功能並不是我們首先要理解的。
文章中的每一個舉例，都可以點擊進入到測試頁面進行測試。閒話少說，開始。
字母、數字、漢字、下劃線、以及後邊章節中沒有特殊定義的標點符號，都是"普通字符"。表達式中的普通字符，在匹配一個字符串的時候，匹配與之相同的一個字符。
舉例1：表達式"c"，在匹配字符串"abcde"時，匹配結果是：成功；匹配到的內容是："c"；匹配到的位置是：開始於2，結束於3。（注：下標從0開始還是從1開始，因當前編程語言的不同而可能不同）
舉例2：表達式 "bcd"，在匹配字符串 "abcde" 時，匹配結果是：成功；匹配到的內容是："bcd"；匹配到的位置是：開始於1，結束於4。
一些不便書寫的字符，採用在前面加 "/" 的方法。這些字符其實我們都已經熟知了。
| 表達式 | 可匹配 |
|---|---|
| /r, /n | 代表回車和換行符 |
| /t | 製表符 |
| // | 代表“/”本身 |
還有其他一些在後邊章節中有特殊用處的標點符號，在前面加"/"後，就代表該符號本身。比如：^,$都有特殊意義，如果要想匹配字符串中"^"和"$"字符，則表達式就需要寫成 "/^" 和 "/$"。
| 表達式 | 可匹配 |
|---|---|
| /^ | 匹配 ^ 符號本身 |
| /$ | 匹配 $ 符號本身 |
| /. | 匹配小數點（.）本身 |
這些轉義字符的匹配方法與 "普通字符" 是類似的。也是匹配與之相同的一個字符。
舉例1：表達式 "/$d"，在匹配字符串 "abc$de" 時，匹配結果是：成功；匹配到的內容是："$d"；匹配到的位置是：開始於3，結束於5。
正則表達式中的一些表示方法，可以匹配'多種字符'其中的任意一個字符。比如，表達式"/d"可以匹配任意一個數字。雖然可以匹配其中任意字符，但是隻能是一個，不是多個。這就好比玩撲克牌時候，大小王可以代替任意一張牌，但是隻能代替一張牌。
| 表達式 | 可匹配 |
|---|---|
| /d | 任意一個數字，0~9 中的任意一個 |
| /w | 任意一個字母或數字或下劃線，也就是 A~Z,a~z,0~9,_ 中任意一個 |
| /s | 包括空格、製表符、換頁符等空白字符的其中任意一個 |
| . | 小數點可以匹配除了換行符（/n）以外的任意一個字符 |
舉例1：表達式 "/d/d"，在匹配 "abc123" 時，匹配的結果是：成功；匹配到的內容是："12"；匹配到的位置是：開始於3，結束於5。
舉例2：表達式 "a./d"，在匹配 "aaa100" 時，匹配的結果是：成功；匹配到的內容是："aa1"；匹配到的位置是：開始於1，結束於4。
使用方括號[]包含一系列字符，能夠匹配其中任意一個字符。用[^]包含一系列字符，則能夠匹配其中字符之外的任意一個字符。同樣的道理，雖然可以匹配其中任意一個，但是隻能是一個，不是多個。
| 表達式 | 可匹配 |
|---|---|
| [ab5@] | 匹配 "a" 或 "b" 或 "5" 或 "@" |
| [^abc] | 匹配 "a","b","c" 之外的任意一個字符 |
| [f-k] | 匹配 "f"~"k" 之間的任意一個字母 |
| [^A-F0-3] | 匹配 "A"~"F","0"~"3" 之外的任意一個字符 |
舉例1：表達式 "[bcd][bcd]" 匹配 "abc123" 時，匹配的結果是：成功；匹配到的內容是："bc"；匹配到的位置是：開始於1，結束於3。
舉例2：表達式 "[^abc]" 匹配 "abc123" 時，匹配的結果是：成功；匹配到的內容是："1"；匹配到的位置是：開始於3，結束於4。
前面章節中講到的表達式，無論是隻能匹配一種字符的表達式，還是可以匹配多種字符其中任意一個的表達式，都只能匹配一次。如果使用表達式再加上修飾匹配次數的特殊符號，那麼不用重複書寫表達式就可以重複匹配。
使用方法是："次數修飾"放在"被修飾的表達式"後邊。比如："[bcd][bcd]" 可以寫成 "[bcd]{2}"。
| 表達式 | 作用 |
|---|---|
| {n} | 表達式重複n次，比如："/w{2}" 相當於 "/w/w"；"a{5}" 相當於 "aaaaa" |
| {m,n} | 表達式至少重複m次，最多重複n次，比如："ba{1,3}"可以匹配 "ba"或"baa"或"baaa" |
| {m,} | 表達式至少重複m次，比如："/w/d{2,}"可以匹配 "a12","_456","M12344"... |
| ? | 匹配表達式0次或者1次，相當於 {0,1}，比如："a[cd]?"可以匹配 "a","ac","ad" |
| + | 表達式至少出現1次，相當於 {1,}，比如："a+b"可以匹配 "ab","aab","aaab"... |
| * | 表達式不出現或出現任意次，相當於 {0,}，比如："/^*b"可以匹配 "b","^^^b"... |
舉例1：表達式 "/d+/.?/d*" 在匹配 "It costs $12.5" 時，匹配的結果是：成功；匹配到的內容是："12.5"；匹配到的位置是：開始於10，結束於14。
舉例2：表達式 "go{2,8}gle" 在匹配 "Ads by goooooogle" 時，匹配的結果是：成功；匹配到的內容是："goooooogle"；匹配到的位置是：開始於7，結束於17。
一些符號在表達式中代表抽象的特殊意義：
| 表達式 | 作用 |
|---|---|
| ^ | 與字符串開始的地方匹配，不匹配任何字符 |
| $ | 與字符串結束的地方匹配，不匹配任何字符 |
| /b | 匹配一個單詞邊界，也就是單詞和空格之間的位置，不匹配任何字符 |
進一步的文字說明仍然比較抽象，因此，舉例幫助大家理解。
舉例1：表達式 "^aaa" 在匹配 "xxx aaa xxx" 時，匹配結果是：失敗。因爲 "^" 要求與字符串開始的地方匹配，因此，只有當 "aaa" 位於字符串的開頭的時候，"^aaa" 才能匹配，比如："aaa xxx xxx"。
舉例2：表達式 "aaa$" 在匹配 "xxx aaa xxx" 時，匹配結果是：失敗。因爲 "$" 要求與字符串結束的地方匹配，因此，只有當 "aaa" 位於字符串的結尾的時候，"aaa$" 才能匹配，比如："xxx xxx aaa"。
舉例3：表達式 "./b." 在匹配 "@@@abc" 時，匹配結果是：成功；匹配到的內容是："@a"；匹配到的位置是：開始於2，結束於4。
進一步說明："/b" 與 "^" 和 "$" 類似，本身不匹配任何字符，但是它要求它在匹配結果中所處位置的左右兩邊，其中一邊是 "/w" 範圍，另一邊是 非"/w" 的範圍。
舉例4：表達式 "/bend/b" 在匹配 "weekend,endfor,end" 時，匹配結果是：成功；匹配到的內容是："end"；匹配到的位置是：開始於15，結束於18。
一些符號可以影響表達式內部的子表達式之間的關係：
| 表達式 | 作用 |
|---|---|
| | | 左右兩邊表達式之間 "或" 關係，匹配左邊或者右邊 |
| ( ) | (1). 在被修飾匹配次數的時候，括號中的表達式可以作爲整體被修飾 |
舉例5：表達式 "Tom|Jack" 在匹配字符串 "I'm Tom, he is Jack"時，匹配結果是：成功；匹配到的內容是："Tom"；匹配到的位置是：開始於4，結束於7。匹配下一個時，匹配結果是：成功；匹配到的內容是："Jack"；匹配到的位置時：開始於15，結束於19。
舉例6：表達式 "(go/s*)+" 在匹配 "Let's go go go!" 時，匹配結果是：成功；匹配到內容是："go go go"；匹配到的位置是：開始於6，結束於14。
舉例7：表達式 "￥(/d+/.?/d*)" 在匹配 "＄10.9,￥20.5" 時，匹配的結果是：成功；匹配到的內容是："￥20.5"；匹配到的位置是：開始於6，結束於10。單獨獲取括號範圍匹配到的內容是："20.5"。
在使用修飾匹配次數的特殊符號時，有幾種表示方法可以使同一個表達式能夠匹配不同的次數，比如："{m,n}", "{m,}", "?", "*", "+"，具體匹配的次數隨被匹配的字符串而定。這種重複匹配不定次數的表達式在匹配過程中，總是儘可能多的匹配。比如，針對文本 "dxxxdxxxd"，舉例如下：
| 表達式 | 匹配結果 |
|---|---|
| (d)(/w+) | "/w+" 將匹配第一個 "d" 之後的所有字符 "xxxdxxxd" |
| (d)(/w+)(d) | "/w+" 將匹配第一個 "d" 和最後一個 "d" 之間的所有字符 "xxxdxxx"。雖然 "/w+" 也能夠匹配上最後一個 "d"，但是爲了使整個表達式匹配成功，"/w+" 可以 "讓出" 它本來能夠匹配的最後一個 "d" |
由此可見，"/w+" 在匹配的時候，總是儘可能多的匹配符合它規則的字符。雖然第二個舉例中，它沒有匹配最後一個 "d"，但那也是爲了讓整個表達式能夠匹配成功。同理，帶 "*" 和 "{m,n}" 的表達式都是儘可能地多匹配，帶 "?" 的表達式在可匹配可不匹配的時候，也是儘可能的 "要匹配"。這 種匹配原則就叫作 "貪婪" 模式 。
在修飾匹配次數的特殊符號後再加上一個 "?" 號，則可以使匹配次數不定的表達式儘可能少的匹配，使可匹配可不匹配的表達式，儘可能的 "不匹配"。這種匹配原則叫作 "非貪婪" 模式，也叫作 "勉強" 模式。如果少匹配就會導致整個表達式匹配失敗的時候，與貪婪模式類似，非貪婪模式會最小限度的再匹配一些，以使整個表達式匹配成功。舉例如下，針對文本 "dxxxdxxxd" 舉例：
| 表達式 | 匹配結果 |
|---|---|
| (d)(/w+?) | "/w+?" 將儘可能少的匹配第一個 "d" 之後的字符，結果是："/w+?" 只匹配了一個 "x" |
| (d)(/w+?)(d) | 爲了讓整個表達式匹配成功，"/w+?" 不得不匹配 "xxx" 纔可以讓後邊的 "d" 匹配，從而使整個表達式匹配成功。因此，結果是："/w+?" 匹配 "xxx" |
更多的情況，舉例如下：
舉例1：表達式 "<td>(.*)</td>" 與字符串 "<td><p>aa</p></td> <td><p>bb</p></td>" 匹配時，匹配的結果是：成功；匹配到的內容是 "<td><p>aa</p></td> <td><p>bb</p></td>" 整個字符串， 表達式中的 "</td>" 將與字符串中最後一個 "</td>" 匹配。
舉例2：相比之下，表達式 "<td>(.*?)</td>" 匹配舉例1中同樣的字符串時，將只得到 "<td><p>aa</p></td>"， 再次匹配下一個時，可以得到第二個 "<td><p>bb</p></td>"。
表達式在匹配時，表達式引擎會將小括號 "( )" 包含的表達式所匹配到的字符串記錄下來。在獲取匹配結果的時候，小括號包含的表達式所匹配到的字符串可以單獨獲取。這一點，在前面的舉例中，已經多次展示了。在實際應用場合中，當用某種邊界來查找，而所要獲取的內容又不包含邊界時，必須使用小括號來指定所要的範圍。比如前面的 "<td>(.*?)</td>"。
其實，"小括號包含的表達式所匹配到的字符串" 不僅是在匹配結束後纔可以使用，在匹配過程中也可以使用。表達式後邊的部分，可以引用前面 "括號內的子匹配已經匹配到的字符串"。引用方法是 "/" 加上一個數字。"/1" 引用第1對括號內匹配到的字符串，"/2" 引用第2對括號內匹配到的字符串……以此類推，如果一對括號內包含另一對括號，則外層的括號先排序號。換句話說，哪一對的左括號 "(" 在前，那這一對就先排序號。
舉例如下：
舉例1：表達式 "('|")(.*?)(/1)" 在匹配 " 'Hello', "World" " 時，匹配結果是：成功；匹配到的內容是：" 'Hello' "。再次匹配下一個時，可以匹配到 " "World" "。
舉例2：表達式 "(/w)/1{4,}" 在匹配 "aa bbbb abcdefg ccccc 111121111 999999999" 時，匹配結果是：成功；匹配到的內容是 "ccccc"。再次匹配下一個時，將得到 999999999。這個表達式要求 "/w" 範圍的字符至少重複5次，注意與 "/w{5,}" 之間的區別。
舉例3：表達式 "<(/w+)/s*(/w+(=('|").*?/4)?/s*)*>.*?<//1>" 在匹配 "<td id='td1' style="bgcolor:white"></td>" 時，匹配結果是成功。如果 "<td>" 與 "</td>" 不配對，則會匹配失敗；如果改成其他配對，也可以匹配成功。
前面的章節中，我講到了幾個代表抽象意義的特殊符號："^"，"$"，"/b"。它們都有一個共同點，那就是：它們本身不匹配任何字符，只是對 "字符串的兩頭" 或者 "字符之間的縫隙" 附加了一個條件。理解到這個概念以後，本節將繼續介紹另外一種對 "兩頭" 或者 "縫隙" 附加條件的，更加靈活的表示方法。
正向預搜索："(?=xxxxx)"，"(?!xxxxx)"
格式："(?=xxxxx)"，在被匹配的字符串中，它對所處的 "縫隙" 或者 "兩頭" 附加的條件是：所在縫隙的右側，必須能夠匹配上 xxxxx 這部分的表達式。因爲它只是在此作爲這個縫隙上附加的條件，所以它並不影響後邊的表達式去真正匹配這個縫隙之後的字符。這就類似 "/b"，本身不匹配任何字符。"/b" 只是將所在縫隙之前、之後的字符取來進行了一下判斷，不會影響後邊的表達式來真正的匹配。
舉例1：表達式 "Windows (?=NT|XP)" 在匹配 "Windows 98, Windows NT, Windows 2000" 時，將只匹配 "Windows NT" 中的 "Windows "，其他的 "Windows " 字樣則不被匹配。
舉例2：表達式 "(/w)((?=/1/1/1)(/1))+" 在匹配字符串 "aaa ffffff 999999999" 時，將可以匹配6個"f"的前4個，可以匹配9個"9"的前7個。這個表達式可以讀解成：重複4次以上的字母數字，則匹配其剩下最後2位之前的部分。當然，這個表達式可以不這樣寫，在此的目的是作爲演示之用。
格式："(?!xxxxx)"，所在縫隙的右側，必須不能匹配 xxxxx 這部分表達式。
舉例3：表達式 "((?!/bstop/b).)+" 在匹配 "fdjka ljfdl stop fjdsla fdj" 時，將從頭一直匹配到 "stop" 之前的位置，如果字符串中沒有 "stop"，則匹配整個字符串。
舉例4：表達式 "do(?!/w)" 在匹配字符串 "done, do, dog" 時，只能匹配 "do"。在本條舉例中，"do" 後邊使用 "(?!/w)" 和使用 "/b" 效果是一樣的。
反向預搜索："(?<=xxxxx)"，"(?<!xxxxx)"
這兩種格式的概念和正向預搜索是類似的，反向預搜索要求的條件是：所在縫隙的 "左側"，兩種格式分別要求必須能夠匹配和必須不能夠匹配指定表達式，而不是去判斷右側。與 "正向預搜索" 一樣的是：它們都是對所在縫隙的一種附加條件，本身都不匹配任何字符。
舉例5：表達式 "(?<=/d{4})/d+(?=/d{4})" 在匹配 "1234567890123456" 時，將匹配除了前4個數字和後4個數字之外的中間8個數字。由於 JScript.RegExp 不支持反向預搜索，因此，本條舉例不能夠進行演示。很多其他的引擎可以支持反向預搜索，比如：Java 1.4 以上的 java.util.regex 包，.NET 中System.Text.RegularExpressions 命名空間，以及本站推薦的最簡單易用的 DEELX 正則引擎。
還有一些在各個正則表達式引擎之間比較通用的規則，在前面的講解過程中沒有提到。
| 形式 | 字符範圍 |
|---|---|
| /xXX | 編號在 0 ~ 255 範圍的字符，比如：空格可以使用 "/x20" 表示 |
| /uXXXX | 任何字符可以使用 "/u" 再加上其編號的4位十六進制數表示，比如："/u4E2D" |
| 表達式 | 可匹配 |
|---|---|
| /S | 匹配所有非空白字符（"/s" 可匹配各個空白字符） |
| /D | 匹配所有的非數字字符 |
| /W | 匹配所有的字母、數字、下劃線以外的字符 |
| /B | 匹配非單詞邊界，即左右兩邊都是 "/w" 範圍或者左右兩邊都不是 "/w" 範圍時的字符縫隙 |
| 字符 | 說明 |
|---|---|
| ^ | 匹配輸入字符串的開始位置。要匹配 "^" 字符本身，請使用 "/^" |
| $ | 匹配輸入字符串的結尾位置。要匹配 "$" 字符本身，請使用 "/$" |
| ( ) | 標記一個子表達式的開始和結束位置。要匹配小括號，請使用 "/(" 和 "/)" |
| [ ] | 用來自定義能夠匹配 '多種字符' 的表達式。要匹配中括號，請使用 "/[" 和 "/]" |
| { } | 修飾匹配次數的符號。要匹配大括號，請使用 "/{" 和 "/}" |
| . | 匹配除了換行符（/n）以外的任意一個字符。要匹配小數點本身，請使用 "/." |
| ? | 修飾匹配次數爲 0 次或 1 次。要匹配 "?" 字符本身，請使用 "/?" |
| + | 修飾匹配次數爲至少 1 次。要匹配 "+" 字符本身，請使用 "/+" |
| * | 修飾匹配次數爲 0 次或任意次。要匹配 "*" 字符本身，請使用 "/*" |
| | | 左右兩邊表達式之間 "或" 關係。匹配 "|" 本身，請使用 "/|" |
舉例1：表達式 "(?:(/w)/1)+" 匹配 "a bbccdd efg" 時，結果是 "bbccdd"。括號 "(?:)" 範圍的匹配結果不進行記錄，因此 "(/w)" 使用 "/1" 來引用。
| 表達式屬性 | 說明 |
|---|---|
| Ignorecase | 默認情況下，表達式中的字母是要區分大小寫的。配置爲 Ignorecase 可使匹配時不區分大小寫。有的表達式引擎，把 "大小寫" 概念延伸至 UNICODE 範圍的大小寫。 |
| Singleline | 默認情況下，小數點 "." 匹配除了換行符（/n）以外的字符。配置爲 Singleline 可使小數點可匹配包括換行符在內的所有字符。 |
| Multiline | 默認情況下，表達式 "^" 和 "$" 只匹配字符串的開始 ① 和結尾 ④ 位置。如： |
| Global | 主要在將表達式用來替換時起作用，配置爲 Global 表示替換所有的匹配。 |
如果想要了解高級的正則引擎還支持那些複雜的正則語法，可參見本站 DEELX 正則引擎的說明文檔。
如果要要求表達式所匹配的內容是整個字符串，而不是從字符串中找一部分，那麼可以在表達式的首尾使用 "^" 和 "$"，比如："^/d+$" 要求整個字符串只有數字。
如果要求匹配的內容是一個完整的單詞，而不會是單詞的一部分，那麼在表達式首尾使用 "/b"，比如：使用 "/b(if|while|else|void|int……)/b" 來匹配程序中的關鍵字。
表達式不要匹配空字符串。否則會一直得到匹配成功，而結果什麼都沒有匹配到。比如：準備寫一個匹配 "123"、"123."、"123.5"、".5" 這幾種形式的表達式時，整數、小數點、小數數字都可以省略，但是不要將表達式寫成："/d*/.?/d*"，因爲如果什麼都沒有，這個表達式也可以匹配成功。更好的寫法是："/d+/.?/d*|/./d+"。
能匹配空字符串的子匹配不要循環無限次。如果括號內的子表達式中的每一部分都可以匹配 0 次，而這個括號整體又可以匹配無限次，那麼情況可能比上一條所說的更嚴重，匹配過程中可能死循環。雖然現在有些正則表達式引擎已經通過辦法避免了這種情況出現死循環了，比如 .NET 的正則表達式，但是我們仍然應該儘量避免出現這種情況。如果我們在寫表達式時遇到了死循環，也可以從這一點入手，查找一下是否是本條所說的原因。
有時候，我們需要用正則表達式來分析一個計算式中的括號配對情況。比如，使用表達式 "/( [^)]* /)" 或者 "/( .*? /)" 可以匹配一對小括號。但是如果括號 內還嵌有一層括號的話 ，如 "( ( ) )"，則這種寫法將不能夠匹配正確，得到的結果是 "( ( )" 。類似情況的還有 HTML 中支持嵌套的標籤如 "<font> </font>" 等。本節將要討論的是，想辦法把有嵌套的的成對括號或者成對標籤匹配出來。
有的正則表達式引擎，專門針對這種嵌套提供了支持。並且在棧空間允許的情況下，能夠支持任意未知層次的嵌套：比如 Perl，PHP，GRETA 等。在 PHP 和 GRETA 中，表達式中使用 "(?R)" 來表示嵌套部分。 匹配嵌套了未知層次的 "小括號對" 的表達式寫法如下："/( ([^()] | (?R))* /)"。
對於不支持嵌套的正則表達式引擎，只能通過一定的辦法來匹配有限層次的嵌套。思路如下：
第一步，寫一個不能支持嵌套的表達式："/( [^()]* /)"，"<font>((?!</?font>).)*</font>"。 這兩個表達式在匹配有嵌套的文本時，只匹配最內層。
第二步，寫一個可匹配嵌套一層的表達式："/( ([^()] | /( [^()]* /))* /)"。這個表達式在匹配嵌套層數大於一時，只能匹配最裏面的兩層，同時，這個表達式也能匹配沒有嵌套的文本或者嵌套的最裏層。
匹配嵌套一層的 "<font>" 標籤，表達式爲："<font>((?!</?font>).|(<font>((?!</?font>).)*</font>))*</font>"。這個表達式在匹配 "<font>" 嵌套層數大於一的文本時，只匹配最裏面的兩層。
第三步，找到匹配嵌套(n)層的表達式 與 嵌套(n-1)層的表達式之間的關係。比如，能夠匹配嵌套(n)層的表達式爲：
[標記頭] ( [匹配 [標記頭] 和 [標記尾] 之外的表達式] | [匹配 n-1 層的表達式] )* [標記尾]
回頭來看前面編寫的“可匹配嵌套一層”的表達式：
/( ( [^()] | /(([^()])*/) )* /)
<font> ( (?!</?font>). | (<font>((?!</?font>).)*</font>) )* </font>PHP 和 GRETA 的簡便之處在於，匹配嵌套(n-1)層的表達式用 (?R) 表示：
/( ( [^()] | (?R) )* /)
第四步，依此類推，可以編寫出匹配有限(n)層的表達式。這種方式寫出來的表達式，雖然看上去很長，但是這種表達式經過編譯後，匹配效率仍然是很高的。
可能有不少的人和我一樣，有過這樣的經歷：當我們要匹配類似 "<td>內容</td>" 或者 "[b]加粗[/b]" 這樣的文本時，我們根據正向預搜索功能寫出這樣的表達式："<td>([^<]|<(?!/td>))*</td>" 或者 "<td>((?!</td>).)*</td>"。
當發現非貪婪匹配之時，恍然大悟，同樣功能的表達式可以寫得如此簡單："<td>.*?</td>"。 頓時間如獲至寶，凡是按邊界匹配的地方，儘量使用簡捷的非貪婪匹配 ".*?"。特別是對於複雜的表達式來說，採用非貪婪匹配 ".*?" 寫出來的表達式的確是簡練了許多。
然而，當一個表達式中，有多個非貪婪匹配時，或者多個未知匹配次數的表達式時，這個表達式將可能存在效率上的陷阱。有時候，匹配速度慢得莫名奇妙，甚至開始懷疑正則表達式是否實用。
在本站基礎文章裏，對非貪婪匹配的描述中說到：“如果少匹配就會導致整個表達式匹配失敗的時候，與貪婪模式類似，非貪婪模式會最小限度的再匹配一些，以使整個表達式匹配成功。”
具體的匹配過程是這樣的：
"非貪婪部分" 先匹配最少次數，然後嘗試匹配 "右側的表達式"。
如果右側的表達式匹配成功，則整個表達式匹配結束。如果右側表達式匹配失敗，則 "非貪婪部分" 將增加匹配一次，然後再嘗試匹配 "右側的表達式"。
如果右側的表達式又匹配失敗，則 "非貪婪部分" 將再增加匹配一次。再嘗試匹配 "右側的表達式"。
依此類推，最後得到的結果是 "非貪婪部分" 以儘可能少的匹配次數，使整個表達式匹配成功。或者最終仍然匹配失敗。
當一個表達式中有多個非貪婪匹配，以表達式 "d(/w+?)d(/w+?)z" 爲例，對於第一個括號中的 "/w+?" 來說，右邊的 "d(/w+?)z" 屬於它的 "右側的表達式"，對於第二個括號中的 "/w+?" 來說，右邊的 "z" 屬於它的 "右側的表達式"。
當 "z" 匹配失敗時，第二個 "/w+?" 會 "增加匹配一次"，再嘗試匹配 "z"。如果第二個 "/w+?" 無論怎樣 "增加匹配次數"，直至整篇文本結束，"z" 都不能匹配，那麼表示 "d(/w+?)z" 匹配失敗，也就是說第一個 "/w+?" 的 "右側" 匹配失敗。此時，第一個 "/w+?" 會增加匹配一次，然後再進行 "d(/w+?)z" 的匹配。循環前面所講的過程，直至第一個 "/w+?" 無論怎麼 "增加匹配次數"，後邊的 "d(/w+?)z" 都不能匹配時，整個表達式才宣告匹配失敗。
其實，爲了使整個表達式匹配成功，貪婪匹配也會適當的“讓出”已經匹配的字符。因此貪婪匹配也有類似的情況。當一個表達式中有較多的未知匹配次數的表達式時，爲了讓整個表達式匹配成功，各個貪婪或非貪婪的表達式都要進行嘗試減少或增加匹配次數，由此容易形成一個大循環的嘗試，造成了很長的匹配時間。本文之所以稱之爲“陷阱”，因爲這種效率問題往往不易察覺。
舉例："d(/w+?)d(/w+?)d(/w+?)z" 匹配 "ddddddddddd..." 時，將花費較長一段時間才能判斷出匹配失敗 。
避免效率陷阱的原則是：避免“多重循環”的“嘗試匹配”。並不是說非貪婪匹配就是不好的，只是在運用非貪婪匹配的時候，需要注意避免過多“循環嘗試”的問題。
情況一：對於只有一個非貪婪或者貪婪匹配的表達式來說，不存在效率陷阱。也就是說，要匹配類似 "<td> 內容 </td>" 這樣的文本，表達式 "<td>([^<]|<(?!/td>))*</td>" 和 "<td>((?!</td>).)*</td>" 和 "<td>.*?</td>" 的效率是完全相同的。
情況二：如果一個表達式中有多個未知匹配次數的表達式，應防止進行不必要的嘗試匹配。
比如，對表達式 "<script language='(.*?)'>(.*?)</script>" 來說， 如果前面部分表達式在遇到 "<script language='vbscript'>" 時匹配成功後，而後邊的 "(.*?)</script>" 卻匹配失敗，將導致第一個 ".*?" 增加匹配次數再嘗試。而對於表達式真正目的，讓第一個 ".*?" 增加匹配成“vbscript'>”是不對的，因此這種嘗試是不必要的嘗試。
因此，對依靠邊界來識別的表達式，不要讓未知匹配次數的部分跨過它的邊界。前面的表達式中，第一個 ".*?" 應該改寫成 "[^']*"。後邊那個 ".*?" 的右邊再沒有未知匹配次數的表達式，因此這個非貪婪匹配沒有效率陷阱。於是，這個匹配腳本塊的表達式，應該寫成："<script language='([^']*)'>(.*?)</script>" 更好。