轉貼：深入淺出之Regex

前言： 半年前我對Regex產生了興趣，在網上尋找過不少資料，看過不少的教程，最後在使用一個Regex工具RegexBuddy時發現他的教程寫的非常好，可以說是我目前見過最好的Regex教程。於是一直想把他翻譯過來。這個願望直到這個五一長假才得以實現，結果就有了這篇文章。關於本文的名字，使用“深入淺出”似乎已經太俗。但是通讀原文以後，覺得只有用“深入淺出”才能準確的表達出該教程給我的感受，所以也就不能免俗了。 本文是Jan Goyvaerts為RegexBuddy寫的教程的譯文，著作權歸原作者所有，歡迎轉載。但是為了尊重原作者和譯者的勞動，請註明出處！謝謝！  1.什麼是Regex 基本說來，Regex是一種用來描述一定數量文本的模式。Regex代表Regular Express。本文將用<<regex>>來表示一段具體的Regex。 一段文本就是最基本的模式，簡單的匹配相同的文本。  2.不同的Regex引擎 Regex引擎是一種可以處理Regex的軟體。通常，引擎是更大的應用程式的一部分。在軟體世界，不同的Regex並不互相相容。本教程會集中討論Perl 5 類型的引擎，因為這種引擎是應用最廣泛的引擎。同時我們也會提到一些和其他引擎的區別。許多近代的引擎都很類似，但不完全一樣。例如.NET正則庫，JDK正則包。  3.文字元號 最基本的Regex由單個文字元號組成。如<<a>>，它將匹配字串中第一次出現的字元“a”。如對字串“Jack is a boy”。“J”後的“a”將被匹配。而第二個“a”將不會被匹配。 Regex也可以匹配第二個“a”，這必須是你告訴Regex引擎從第一次匹配的地方開始搜尋。在文字編輯器中，你可以使用“尋找下一個”。在程式設計語言中，會有一個函數可以使你從前一次匹配的位置開始繼續向後搜尋。 類似的，<<cat>>會匹配“About cats and dogs”中的“cat”。這等於是告訴Regex引擎，找到一個<<c>>，緊跟一個<<a>>，再跟一個<<t>>。 要注意，Regex引擎預設是大小寫敏感的。除非你告訴引擎忽略大小寫，否則<<cat>>不會匹配“Cat”。  · 特殊字元 對於文字字元，有11個字元被保留作特殊用途。他們是： [ ] / ^ $ . | ? * + ( ) 這些特殊字元也被稱作元字元。 如果你想在Regex中將這些字元用作文本字元，你需要用反斜線“/”對其進行換碼 (escape)。例如你想匹配“1+1=2”，正確的運算式為<<1/+1=2>>. 需要注意的是，<<1+1=2>>也是有效Regex。但它不會匹配“1+1=2”，而會匹配“123+111=234”中的“111=2”。因為“+”在這裡表示特殊含義（重複1次到多次）。 在程式設計語言中，要注意，一些特殊的字元會先被編譯器處理，然後再傳遞給正則引擎。因此Regex<<1/+2=2>>在C++中要寫成“1//+1=2”。為了匹配“C:/temp”，你要用Regex<<C://temp>>。而在C++中，Regex則變成了“C:////temp”。  ·不可顯示字元 可以使用特殊字元序列來代表某些不可顯示字元： <</t>>代表Tab(0x09) <</r>>代表斷行符號符(0x0D) <</n>>代表分行符號(0x0A) 要注意的是Windows中文字檔使用“/r/n”來結束一行而Unix使用“/n”。  4.Regex引擎的內部工作機制 知道Regex引擎是如何工作的有助於你很快理解為何某個Regex不像你期望的那樣工作。 有兩種類型的引擎：文本導向(text-directed)的引擎和正則導向(regex-directed)的引擎。Jeffrey Friedl把他們稱作DFA和NFA引擎。本文談到的是正則導向的引擎。這是因為一些非常有用的特性，如“惰性”量詞(lazy quantifiers)和反向引用(backreferences)，只能在正則導向的引擎中實現。所以毫不意外這種引擎是目前最流行的引擎。 你可以輕易分辨出所使用的引擎是文本導向還是正則導向。如果反向引用或“惰性”量詞被實現，則可以肯定你使用的引擎是正則導向的。你可以作如下測試：將Regex<<regex|regex not>>應用到字串“regex not”。如果匹配的結果是regex，則引擎是正則導向的。如果結果是regex not，則是文本導向的。因為正則導向的引擎是“猴急”的，它會很急切的進行表功，報告它找到的第一個匹配 。  ·正則導向的引擎總是返回最左邊的匹配 這是需要你理解的很重要的一點：即使以後有可能發現一個“更好”的匹配，正則導向的引擎也總是返回最左邊的匹配。 當把<<cat>>應用到“He captured a catfish for his cat”，引擎先比較<<c>>和“H”，結果失敗了。於是引擎再比較<<c>>和“e”，也失敗了。直到第四個字元，<<c>>匹配了“c”。<<a>>匹配了第五個字元。到第六個字元<<t>>沒能匹配“p”，也失敗了。引擎再繼續從第五個字元重新檢查匹配性。直到第十五個字元開始，<<cat>>匹配上了“catfish”中的“cat”，Regex引擎急切的返回第一個匹配的結果，而不會再繼續尋找是否有其他更好的匹配。

5.字元集 字元集是由一對方括弧“[]”括起來的字元集合。使用字元集，你可以告訴Regex引擎僅僅匹配多個字元中的一個。如果你想匹配一個“a”或一個“e”，使用<<[ae]>>。你可以使用<<gr[ae]y>>匹配gray或grey。這在你不確定你要搜尋的字元是採用美國英語還是英國英語時特別有用。相反，<<gr[ae]y>>將不會匹配graay或graey。字元集中的字元順序並沒有什麼關係，結果都是相同的。 你可以使用連字號“-”定義一個字元範圍作為字元集。<<[0-9]>>匹配0到9之間的單個數字。你可以使用不止一個範圍。<<[0-9a-fA-F] >>匹配單個的十六進位數字，並且大小寫不敏感。你也可以結合範圍定義與單個字元定義。<<[0-9a-fxA-FX]>>匹配一個十六進位數字或字母X。再次強調一下，字元和範圍定義的先後順序對結果沒有影響。  ·字元集的一些應用 尋找一個可能有拼字錯誤的單詞，比如<<sep[ae]r[ae]te>> 或 <<li[cs]en[cs]e>>。 尋找程式語言的標識符，<<A-Za-z_][A-Za-z_0-9]*>>。(*表示重複0或多次) 尋找C風格的十六進位數<<0[xX][A-Fa-f0-9]+>>。(+表示重複一次或多次)  ·取反字元集 在左方括弧“[”後面緊跟一個角括弧“^”，將會對字元集取反。結果是字元集將匹配任何不在方括弧中的字元。不像“.”，取反字元集是可以匹配斷行符號分行符號的。 需要記住的很重要的一點是，取反字元集必須要匹配一個字元。<<q[^u]>>並不意味著：匹配一個q，後面沒有u跟著。它意味著：匹配一個q，後面跟著一個不是u的字元。所以它不會匹配“Iraq”中的q，而會匹配“Iraq is a country”中的q和一個空格符。事實上，空格符是匹配中的一部分，因為它是一個“不是u的字元”。 如果你只想匹配一個q，條件是q後面有一個不是u的字元，我們可以用後面將講到的向前查看來解決。  ·字元集中的元字元 需要注意的是，在字元集中只有4個 字元具有特殊含義。它們是：“] / ^ -”。“]”代表字元集定義的結束；“/”代錶轉義；“^”代表取反；“-”代表範圍定義。其他常見的元字元在字元集定義內部都是正常字元，不需要轉義。例如，要搜尋星號*或加號+，你可以用<<[+*]>>。當然，如果你對那些通常的元字元進行轉義，你的Regex一樣會工作得很好，但是這會降低可讀性。 在字元集定義中為了將反斜線“/”作為一個文字字元而非特殊含義的字元，你需要用另一個反斜線對它進行轉義。<<[//x]>>將會匹配一個反斜線和一個X。“]^-”都可以用反斜線進行轉義，或者將他們放在一個不可能使用到他們特殊含義的位置。我們推薦後者，因為這樣可以增加可讀性。比如對於字元“^”，將它放在除了左括弧“[”後面的位置，使用的都是文字字元含義而非取反含義。如<<[x^]>>會匹配一個x或^。<<[]x]>>會匹配一個“]”或“x”。<<[-x]>>或<<[x-]>>都會匹配一個“-”或“x”。  ·字元集的簡寫 因為一些字元集非常常用，所以有一些簡寫方式。 <</d>>代表<<[0-9]>>; <</w>>代表單詞字元。這個是隨Regex實現的不同而有些差異。絕大多數的Regex實現的單詞字元集都包含了<<A-Za-z0-9_]>>。 <</s>>代表“白字元”。這個也是和不同的實現有關的。在絕大多數的實現中，都包含了空格符和Tab符，以及斷行符號分行符號<</r/n>>。 字元集的縮寫形式可以用在方括弧之內或之外。<</s/d>>匹配一個白字元後面緊跟一個數字。<<[/s/d]>>匹配單個白字元或數字。<<[/da-fA-F]>>將匹配一個十六進位數字。 取反字元集的簡寫 <<[/S]>> = <<[^/s]>> <<[/W]>> = <<[^/w]>> <<[/D]>> = <<[^/d]>> ·字元集的重複 如果你用“?*+”操作符來重複一個字元集，你將會重複整個字元集。而不僅是它匹配的那個字元。Regex<<[0-9]+>>會匹配837以及222。 如果你僅僅想重複被匹配的那個字元，可以用反向參考達到目的。我們以後將講到反向參考。  6.使用?*或+ 進行重複 ?：告訴引擎匹配前置字元0次或一次。事實上是表示前置字元是可選的。 +：告訴引擎匹配前置字元1次或多次 *：告訴引擎匹配前置字元0次或多次 <[A-Za-z][A-Za-z0-9]*>匹配沒有屬性的HTML標籤，“<”以及“>”是文字元號。第一個字元集匹配一個字母，第二個字元集匹配一個字母或數字。 我們似乎也可以用<[A-Za-z0-9]+>。但是它會匹配<1>。但是這個Regex在你知道你要搜尋的字串不包含類似的無效標籤時還是足夠有效。  ·限制性重複 許多現代的Regex實現，都允許你定義對一個字元重複多少次。詞法是：{min,max}。min和max都是非負整數。如果逗號有而max被忽略了，則max沒有限制。如果逗號和max都被忽略了，則重複min次。 因此{0,}和*一樣，{1，}和+ 的作用一樣。 你可以用<</b[1-9][0-9]{3}/b>>匹配1000~9999之間的數字(“/b”表示單詞邊界)。<</b[1-9][0-9]{2,4}/b>>匹配一個在100~99999之間的數字。  ·注意貪婪性 假設你想用一個Regex匹配一個HTML標籤。你知道輸入將會是一個有效HTML檔案，因此Regex不需要排除那些無效的標籤。所以如果是在兩個角括弧之間的內容，就應該是一個HTML標籤。 許多Regex的新手會首先想到用Regex<< <.+> >>，他們會很驚訝的發現，對於測試字串，“This is a <EM>first</EM> test”，你可能期望會返回<EM>，然後繼續進行匹配的時候，返回</EM>。 但事實是不會。Regex將會匹配“<EM>first</EM>”。很顯然這不是我們想要的結果。原因在於“+”是貪婪的。也就是說，“+”會導致Regex引擎試圖儘可能的重複前置字元。只有當這種重複會引起整個Regex匹配失敗的情況下，引擎會進行回溯。也就是說，它會放棄最後一次的“重複”，然後處理Regex餘下的部分。 和“+”類似，“?*”的重複也是貪婪的。

·深入Regex引擎內部 讓我們來看看正則引擎如何匹配前面的例子。第一個記號是“<”，這是一個文字元號。第二個符號是“.”，匹配了字元“E”，然後“+”一直可以匹配其餘的字元，直到一行的結束。然後到了分行符號，匹配失敗(“.”不匹配分行符號)。於是引擎開始對下一個Regex符號進行匹配。也即試圖匹配“>”。到目前為止，“<.+”已經匹配了“<EM>first</EM> test”。引擎會試圖將“>”與分行符號進行匹配，結果失敗了。於是引擎進行回溯。結果是現在“<.+”匹配“<EM>first</EM> tes”。於是引擎將“>”與“t”進行匹配。顯然還是會失敗。這個過程繼續，直到“<.+”匹配“<EM>first</EM”，“>”與“>”匹配。於是引擎找到了一個匹配“<EM>first</EM>”。記住，正則導向的引擎是“急切的”，所以它會急著報告它找到的第一個匹配。而不是繼續回溯，即使可能會有更好的匹配，例如“<EM>”。所以我們可以看到，由於“+”的貪婪性，使得Regex引擎返回了一個最左邊的最長的匹配。  ·用懶惰性取代貪婪性 一個用於修正以上問題的可能方案是用“+”的惰性代替貪婪性。你可以在“+”後面緊跟一個問號“?”來達到這一點。“*”，“{}”和“?”表示的重複也可以用這個方案。因此在上面的例子中我們可以使用“<.+?>”。讓我們再來看看Regex引擎的處理過程。 再一次，Regex記號“<”會匹配字串的第一個“<”。下一個正則記號是“.”。這次是一個懶惰的“+”來重複上一個字元。這告訴正則引擎，儘可能少的重複上一個字元。因此引擎匹配“.”和字元“E”，然後用“>”匹配“M”，結果失敗了。引擎會進行回溯，和上一個例子不同，因為是惰性重複，所以引擎是擴充惰性重複而不是減少，於是“<.+”現在被擴充為“<EM”。引擎繼續匹配下一個記號“>”。這次得到了一個成功匹配。引擎於是報告“<EM>”是一個成功的匹配。整個過程大致如此。  ·惰性擴充的一個替代方案 我們還有一個更好的替代方案。可以用一個窮盡重複與一個取反字元集：“<[^>]+>”。之所以說這是一個更好的方案在於使用惰性重複時，引擎會在找到一個成功匹配前對每一個字元進行回溯。而使用取反字元集則不需要進行回溯。 最後要記住的是，本教程僅僅談到的是正則導向的引擎。文本導向的引擎是不回溯的。但是同時他們也不支援惰性重複操作。  7.使用“.”匹配幾乎任一字元 在Regex中，“.”是最常用的符號之一。不幸的是，它也是最容易被誤用的符號之一。 “.”匹配一個單個的字元而不用關心被匹配的字元是什麼。唯一的例外是新行符。在本教程中談到的引擎，預設情況下都是不匹配新行符的。因此在預設情況下，“.”等於是字元集[^/n/r](Window)或[^/n]( Unix)的簡寫。 這個例外是因為曆史的原因。因為早期使用Regex的工具是基於行的。它們都是一行一行的讀入一個檔案，將Regex分別應用到每一行上去。在這些工具中，字串是不包含新行符的。因此“.”也就從不匹配新行符。 現代的工具和語言能夠將Regex應用到很大的字串甚至整個檔案上去。本教程討論的所有Regex實現都提供一個選項，可以使“.”匹配所有的字元，包括新行符。在RegexBuddy, EditPad Pro或PowerGREP等工具中，你可以簡單的選中“點號匹配新行符”。在Perl中，“.”可以匹配新行符的模式被稱作“單行模式”。很不幸，這是一個很容易混淆的名詞。因為還有所謂“多行模式”。多行模式隻影響行首行尾的錨定(anchor)，而單行模式隻影響“.”。 其他語言和Regex庫也採用了Perl的術語定義。當在.NET Framework中使用Regex類時，你可以用類似下面的語句來啟用單行模式：Regex.Match(“string”,”regex”,RegexOptions.SingleLine)  ·保守的使用點號“.” 點號可以說是最強大的元字元。它允許你偷懶：用一個點號，就能匹配幾乎所有的字元。但是問題在於，它也常常會匹配不該匹配的字元。 我會以一個簡單的例子來說明。讓我們看看如何匹配一個具有“mm/dd/yy”格式的日期，但是我們想允許使用者來選擇分隔字元。很快能想到的一個方案是<</d/d./d/d./d/d>>。看上去它能匹配日期“02/12/03”。問題在於02512703也會被認為是一個有效日期。 <</d/d[-/.]/d/d[-/.]/d/d>>看上去是一個好一點的解決方案。記住點號在一個字元集裡不是元字元。這個方案遠不夠完善，它會匹配“99/99/99”。而<<[0-1]/d[-/.][0-3]/d[-/.]/d/d>>又更進一步。儘管他也會匹配“19/39/99”。你想要你的Regex達到如何完美的程度取決於你想達到什麼樣的目的。如果你想校正使用者輸入，則需要儘可能的完美。如果你只是想分析一個已知的源，並且我們知道沒有錯誤的資料，用一個比較好的Regex來匹配你想要搜尋的字元就已經足夠。  8.字串開始和結束的錨定 錨定和一般的Regex符號不同，它不匹配任何字元。相反，他們匹配的是字元之前或之後的位置。“^”匹配一行字串第一個字元前的位置。<<^a>>將會匹配字串“abc”中的a。<<^b>>將不會匹配“abc”中的任何字元。 類似的，$匹配字串中最後一個字元的後面的位置。所以<<c$>>匹配“abc”中的c。  ·錨定的應用 在程式設計語言中校正使用者輸入時，使用錨定是非常重要的。如果你想校正使用者的輸入為整數，用<<^/d+$>>。 使用者輸入中，常常會有多餘的前置空格或結束空格。你可以用<<^/s*>>和<</s*$>>來匹配前置空格或結束空格。  ·使用“^”和“$”作為行的開始和結束錨定 如果你有一個包含了多行的字串。例如：“first line/n/rsecond line”(其中/n/r表示一個新行符)。常常需要對每行分別處理而不是整個字串。因此，幾乎所有的Regex引擎都提供一個選項，可以擴充這兩種錨定的含義。“^”可以匹配字串的開始位置(在f之前)，以及每一個新行符的後面位置(在/n/r和s之間)。類似的，$會匹配字串的結束位置(最後一個e之後)，以及每個新行符的前面(在e與/n/r之間)。 在.NET中，當你使用如下代碼時，將會定義錨定匹配每一個新行符的前面和後面位置：Regex.Match("string", "regex", RegexOptions.Multiline) 應用：string str = Regex.Replace(Original, "^", "> ", RegexOptions.Multiline)--將會在每行的行首插入“> ”。 · 絕對錨定 <</A>>只匹配整個字串的開始位置，<</Z>>只匹配整個字串的結束位置。即使你使用了“多行模式”，<</A>>和<</Z>>也從不匹配新行符。 即使/Z和$只匹配字串的結束位置，仍然有一個例外的情況。如果字串以新行符結束，則/Z和$將會匹配新行符前面的位置，而不是整個字串的最後面。這個“改進”是由Perl引進的，然後被許多的Regex實現所遵循，包括Java，.NET等。如果應用<<^[a-z]+$>>到“joe/n”，則匹配結果是“joe”而不是“joe/n”。

 

出處：摩詰