常用的正則表達式全面總結
PS:正則表達式用于字符串處理、表單驗證等場合,實用高效。以下表達式本人收集于網絡,做了簡單整理,以備不時之需。沒有全部驗證,可能會存在部分錯誤,讀者請自己調試鑒別更正。
匹配中文字符的正則表達式: [u4e00-u9fa5]
評注:匹配中文還真是個頭疼的事,有了這個表達式就好辦了
匹配雙字節字符(包括漢字在內):[^x00-xff]
評注:可以用來計算字符串的長度(一個雙字節字符長度計2,ASCII字符計1)
匹配空白行的正則表達式:ns*r
評注:可以用來刪除空白行
匹配HTML標記的正則表達式:<(S*?)[^>]*>.*?</1>|<.*? />
評注:網上流傳的版本太糟糕,上面這個也僅僅能匹配部分,對于復雜的嵌套標記依舊無能為力
匹配首尾空白字符的正則表達式:^s*|s*$
評注:可以用來刪除行首行尾的空白字符(包括空格、制表符、換頁符等等),非常有用的表達式
匹配Email地址的正則表達式:w+([-+.]w+)*@w+([-.]w+)*.w+([-.]w+)*
評注:表單驗證時很實用
匹配網址URL的正則表達式:[a-zA-z]+://[^s]*
評注:網上流傳的版本功能很有限,上面這個基本可以滿足需求
匹配帳號是否合法(字母開頭,允許5-16字節,允許字母數字下劃線):^[a-zA-Z][a-zA-Z0-9_]{4,15}$
評注:表單驗證時很實用
匹配國內電話號碼:d{3}-d{8}|d{4}-d{7}
評注:匹配形式如 0511-4405222 或 021-87888822
匹配騰訊QQ號:[1-9][0-9]{4,}
評注:騰訊QQ號從10000開始
匹配中國郵政編碼:[1-9]d{5}(?!d)
評注:中國郵政編碼為6位數字
匹配身份證:d{15}|d{18}
評注:中國的身份證為15位或18位
匹配ip地址:d+.d+.d+.d+
評注:提取ip地址時有用
匹配特定數字:
^[1-9]d*$ //匹配正整數
^-[1-9]d*$ //匹配負整數
^-?[1-9]d*$ //匹配整數
^[1-9]d*|0$ //匹配非負整數(正整數 + 0)
^-[1-9]d*|0$ //匹配非正整數(負整數 + 0)
^[1-9]d*.d*|0.d*[1-9]d*$ //匹配正浮點數
^-([1-9]d*.d*|0.d*[1-9]d*)$ //匹配負浮點數
^-?([1-9]d*.d*|0.d*[1-9]d*|0?.0+|0)$ //匹配浮點數
^[1-9]d*.d*|0.d*[1-9]d*|0?.0+|0$ //匹配非負浮點數(正浮點數 + 0)
^(-([1-9]d*.d*|0.d*[1-9]d*))|0?.0+|0$ //匹配非正浮點數(負浮點數 + 0)
評注:處理大量數據時有用,具體應用時注意修正
匹配特定字符串:
^[A-Za-z]+$ //匹配由26個英文字母組成的字符串
^[A-Z]+$ //匹配由26個英文字母的大寫組成的字符串
^[a-z]+$ //匹配由26個英文字母的小寫組成的字符串
^[A-Za-z0-9]+$ //匹配由數字和26個英文字母組成的字符串
^w+$ //匹配由數字、26個英文字母或者下劃線組成的字符串
評注:上面是最基本也是最常用的一些表達式
在使用RegularExpressionValidator驗證控件時的驗證功能及其驗證表達式介紹如下:
只能輸入數字:“^[0-9]*$”
只能輸入n位的數字:“^d{n}$”
只能輸入至少n位數字:“^d{n,}$”
只能輸入m-n位的數字:“^d{m,n}$”
只能輸入零和非零開頭的數字:“^(0|[1-9][0-9]*)$”
只能輸入有兩位小數的正實數:“^[0-9]+(.[0-9]{2})?$”
只能輸入有1-3位小數的正實數:“^[0-9]+(.[0-9]{1,3})?$”
只能輸入非零的正整數:“^+?[1-9][0-9]*$”
只能輸入非零的負整數:“^-[1-9][0-9]*$”
只能輸入長度為3的字符:“^.{3}$”
只能輸入由26個英文字母組成的字符串:“^[A-Za-z]+$”
只能輸入由26個大寫英文字母組成的字符串:“^[A-Z]+$”
只能輸入由26個小寫英文字母組成的字符串:“^[a-z]+$”
只能輸入由數字和26個英文字母組成的字符串:“^[A-Za-z0-9]+$”
只能輸入由數字、26個英文字母或者下劃線組成的字符串:“^w+$”
驗證用戶密碼:“^[a-zA-Z]w{5,17}$”正確格式為:以字母開頭,長度在6-18之間,
只能包含字符、數字和下劃線。
驗證是否含有^%&’,;=?$”等字符:“[^%&',;=?$x22]+”
只能輸入漢字:“^[u4e00-u9fa5],{0,}$”
驗證Email地址:“^w+[-+.]w+)*@w+([-.]w+)*.w+([-.]w+)*$”
驗證InternetURL:“^http://([w-]+.)+[w-]+(/[w-./?%&=]*)?$”
驗證電話號碼:“^((d{3,4})|d{3,4}-)?d{7,8}$”
正確格式為:“XXXX-XXXXXXX”,“XXXX-XXXXXXXX”,“XXX-XXXXXXX”,
“XXX-XXXXXXXX”,“XXXXXXX”,“XXXXXXXX”。
驗證身份證號(15位或18位數字):“^d{15}|d{}18$”
驗證一年的12個月:“^(0?[1-9]|1[0-2])$”正確格式為:“01”-“09”和“1”“12”
驗證一個月的31天:“^((0?[1-9])|((1|2)[0-9])|30|31)$”
正確格式為:“01”“09”和“1”“31”。
表達式全集
正則表達式有多種不同的風格。下表是在PCRE中元字符及其在正則表達式上下文中的行為的一個完整列表:
字符 | 描述 |
---|---|
將下一個字符標記為一個特殊字符、或一個原義字符、或一個向后引用、或一個八進制轉義符。例如,“n ”匹配字符“n ”。“n ”匹配一個換行符。序列“\ ”匹配“ ”而“( ”則匹配“( ”。 |
|
^ | 匹配輸入字符串的開始位置。如果設置了RegExp對象的Multiline屬性,^也匹配“n ”或“r ”之后的位置。 |
$ | 匹配輸入字符串的結束位置。如果設置了RegExp對象的Multiline屬性,$也匹配“n ”或“r ”之前的位置。 |
* | 匹配前面的子表達式零次或多次。例如,zo*能匹配“z ”以及“zoo ”。*等價于{0,}。 |
+ | 匹配前面的子表達式一次或多次。例如,“zo+ ”能匹配“zo ”以及“zoo ”,但不能匹配“z ”。+等價于{1,}。 |
? | 匹配前面的子表達式零次或一次。例如,“do(es)? ”可以匹配“do ”或“does ”中的“do ”。?等價于{0,1}。 |
{n} | n是一個非負整數。匹配確定的n次。例如,“o{2} ”不能匹配“Bob ”中的“o ”,但是能匹配“food ”中的兩個o。 |
{n,} | n是一個非負整數。至少匹配n次。例如,“o{2,} ”不能匹配“Bob ”中的“o ”,但能匹配“foooood ”中的所有o。“o{1,} ”等價于“o+ ”。“o{0,} ”則等價于“o* ”。 |
{n,m} | m和n均為非負整數,其中n<=m。最少匹配n次且最多匹配m次。例如,“o{1,3} ”將匹配“fooooood ”中的前三個o。“o{0,1} ”等價于“o? ”。請注意在逗號和兩個數之間不能有空格。 |
? | 當該字符緊跟在任何一個其他限制符(*,+,?,{n},{n,},{n,m})后面時,匹配模式是非貪婪的。非貪婪模式盡可能少的匹配所搜索的字符串,而默認的貪婪模式則盡可能多的匹配所搜索的字符串。例如,對于字符串“oooo ”,“o+? ”將匹配單個“o ”,而“o+ ”將匹配所有“o ”。 |
. | 匹配除“
n ”之外的任何單個字符。要匹配包括“
n ”在內的任何字符,請使用像“[. n ] ”的模式。 |
(pattern) | 匹配pattern并獲取這一匹配。所獲取的匹配可以從產生的Matches集合得到,在VBScript中使用SubMatches集合,在JScript中則使用$0…$9屬性。要匹配圓括號字符,請使用“( ”或“) ”。 |
(?:pattern) | 匹配pattern但不獲取匹配結果,也就是說這是一個非獲取匹配,不進行存儲供以后使用。這在使用或字符“(|) ”來組合一個模式的各個部分是很有用。例如“industr(?:y|ies) ”就是一個比“industry|industries ”更簡略的表達式。 |
(?=pattern) | 正向預查,在任何匹配pattern的字符串開始處匹配查找字符串。這是一個非獲取匹配,也就是說,該匹配不需要獲取供以后使用。例如,“Windows(?=95|98|NT|2000) ”能匹配“Windows2000 ”中的“Windows ”,但不能匹配“Windows3.1 ”中的“Windows ”。預查不消耗字符,也就是說,在一個匹配發生后,在最后一次匹配之后立即開始下一次匹配的搜索,而不是從包含預查的字符之后開始。 |
(?!pattern) | 負向預查,在任何不匹配pattern的字符串開始處匹配查找字符串。這是一個非獲取匹配,也就是說,該匹配不需要獲取供以后使用。例如“Windows(?!95|98|NT|2000) ”能匹配“Windows3.1 ”中的“Windows ”,但不能匹配“Windows2000 ”中的“Windows ”。預查不消耗字符,也就是說,在一個匹配發生后,在最后一次匹配之后立即開始下一次匹配的搜索,而不是從包含預查的字符之后開始 |
x|y | 匹配x或y。例如,“z|food ”能匹配“z ”或“food ”。“(z|f)ood ”則匹配“zood ”或“food ”。 |
[xyz] | 字符集合。匹配所包含的任意一個字符。例如,“[abc] ”可以匹配“plain ”中的“a ”。 |
[^xyz] | 負值字符集合。匹配未包含的任意字符。例如,“[^abc] ”可以匹配“plain ”中的“p ”。 |
[a-z] | 字符范圍。匹配指定范圍內的任意字符。例如,“[a-z] ”可以匹配“a ”到“z ”范圍內的任意小寫字母字符。 |
[^a-z] | 負值字符范圍。匹配任何不在指定范圍內的任意字符。例如,“[^a-z] ”可以匹配任何不在“a ”到“z ”范圍內的任意字符。 |
b | 匹配一個單詞邊界,也就是指單詞和空格間的位置。例如,“erb ”可以匹配“never ”中的“er ”,但不能匹配“verb ”中的“er ”。 |
B | 匹配非單詞邊界。“erB ”能匹配“verb ”中的“er ”,但不能匹配“never ”中的“er ”。 |
cx | 匹配由x指明的控制字符。例如,cM匹配一個Control-M或回車符。x的值必須為A-Z或a-z之一。否則,將c視為一個原義的“c ”字符。 |
d | 匹配一個數字字符。等價于[0-9]。 |
D | 匹配一個非數字字符。等價于[^0-9]。 |
f | 匹配一個換頁符。等價于x0c和cL。 |
n | 匹配一個換行符。等價于x0a和cJ。 |
r | 匹配一個回車符。等價于x0d和cM。 |
s | 匹配任何空白字符,包括空格、制表符、換頁符等等。等價于[fnrtv]。 |
S | 匹配任何非空白字符。等價于[^fnrtv]。 |
t | 匹配一個制表符。等價于x09和cI。 |
v | 匹配一個垂直制表符。等價于x0b和cK。 |
w | 匹配包括下劃線的任何單詞字符。等價于“[A-Za-z0-9_] ”。 |
W | 匹配任何非單詞字符。等價于“[^A-Za-z0-9_] ”。 |
xn | 匹配n,其中n為十六進制轉義值。十六進制轉義值必須為確定的兩個數字長。例如,“x41 ”匹配“A ”。“x041 ”則等價于“x04&1 ”。正則表達式中可以使用ASCII編碼。. |
num | 匹配num,其中num是一個正整數。對所獲取的匹配的引用。例如,“(.)1 ”匹配兩個連續的相同字符。 |
n | 標識一個八進制轉義值或一個向后引用。如果n之前至少n個獲取的子表達式,則n為向后引用。否則,如果n為八進制數字(0-7),則n為一個八進制轉義值。 |
nm | 標識一個八進制轉義值或一個向后引用。如果nm之前至少有nm個獲得子表達式,則nm為向后引用。如果nm之前至少有n個獲取,則n為一個后跟文字m的向后引用。如果前面的條件都不滿足,若n和m均為八進制數字(0-7),則nm將匹配八進制轉義值nm。 |
nml | 如果n為八進制數字(0-3),且m和l均為八進制數字(0-7),則匹配八進制轉義值nml。 |
un | 匹配n,其中n是一個用四個十六進制數字表示的Unicode字符。例如,u00A9匹配版權符號(?)。 |
以下是以PHP的語法所寫的示例
驗證字符串是否只含數字與英文,字符串長度并在4~16個字符之間
<?php $str = 'a1234'; if (preg_match("^[a-zA-Z0-9]{4,16}$", $str)) { echo "驗證成功"; } else { echo "驗證失敗"; } ?>
簡易的臺灣身份證字號驗證
<?php $str = 'a1234'; if (preg_match("/^w[12]d{8}$/", $str)) { echo "驗證成功"; } else { echo "驗證失敗"; } ?>
以下示例是用 Perl 語言寫的,與上面的示例功能相同
print $str = "a1234" =~ m:^[a-zA-Z0-9]{4,16}$: ? "COMFIRM" : "FAILED";
print $str = "a1234" =~ m"^w[12]d{8}$" ? "COMFIRM" : "INVAILD";
如何寫出高效率的正則表達式
如果純粹是為了挑戰自己的正則水平,用來實現一些特效(例如使用正則表達式計算質數、解線性方程),效率不是問題;如果所寫的正則表達式只是為了滿足一兩次、幾十次的運行,優化與否區別也不太大。但是,如果所寫的正則表達式會百萬次、千萬次地運行,效率就是很大的問題了。我這里總結了幾條提升正則表達式運行效率的經驗(工作中學到的,看書學來的,自己的體會),貼在這里。如果您有其它的經驗而這里沒有提及,歡迎賜教。
為行文方便,先定義兩個概念。
誤匹配:指正則表達式所匹配的內容范圍超出了所需要范圍,有些文本明明不符合要求,但是被所寫的正則式“擊中了”。例如,如果使用d{11}來匹配11位的手機號,d{11}不單能匹配正確的手機號,它還會匹配98765432100這樣的明顯不是手機號的字符串。我們把這樣的匹配稱之為誤匹配。
漏匹配:指正則表達式所匹配的內容所規定的范圍太狹窄,有些文本確實是所需要的,但是所寫的正則沒有將這種情況囊括在內。例如,使用d{18}來匹配18位的身份證號碼,就會漏掉結尾是字母X的情況。
寫出一條正則表達式,既可能只出現誤匹配(條件寫得極寬松,其范圍大于目標文本),也可能只出現漏匹配(只描述了目標文本中多種情況種的一種),還可能既有誤匹配又有漏匹配。例如,使用w+.com來匹配.com結尾的域名,既會誤匹配abc_.com這樣的字串(合法的域名中不含下劃線,w包含了下劃線這種情況),又會漏掉ab-c.com這樣的域名(合法域名中可以含中劃線,但是w不匹配中劃線)。
精準的正則表達式意味著既無誤匹配且無漏匹配。當然,現實中存在這樣的情況:只能看到有限數量的文本,根據這些文本寫規則,但是這些規則將會用到海量的文本中。這種情況下,盡可能地(如果不是完全地)消除誤匹配以及漏匹配,并提升運行效率,就是我們的目標。本文所提出的經驗,主要是針對這種情況。
掌握語法細節。正則表達式在各種語言中,其語法大致相同,細節各有千秋。明確所使用語言的正則的語法的細節,是寫出正確、高效正則表達式的基礎。例如,perl中與w等效的匹配范圍是[a-zA-Z0-9_];perl正則式不支持肯定逆序環視中使用可變的重復(variable repetition inside lookbehind,例如(?<=.*)abc),但是.Net語法是支持這一特性的;又如,JavaScript連逆序環視(Lookbehind,如(?<=ab)c)都不支持,而perl和python是支持的。《精通正則表達式》第3章《正則表達式的特性和流派概覽》明確地列出了各大派系正則的異同,這篇文章也簡要地列出了幾種常用語言、工具中正則的比較。對于具體使用者而言,至少應該詳細了解正在使用的那種工作語言里正則的語法細節。
先粗后精,先加后減。使用正則表達式語法對于目標文本進行描述和界定,可以像畫素描一樣,先大致勾勒出框架,再逐步在局步實現細節。仍舉剛才的手機號的例子,先界定d{11},總不會錯;再細化為1[358]d{9},就向前邁了一大步(至于第二位是不是3、5、8,這里無意深究,只舉這樣一個例子,說明逐步細化的過程)。這樣做的目的是先消除漏匹配(剛開始先盡可能多地匹配,做加法),然后再一點一點地消除誤匹配(做減法)。這樣有先有后,在考慮時才不易出錯,從而向“不誤不漏”這個目標邁進。
留有余地。所能看到的文本sample是有限的,而待匹配檢驗的文本是海量的,暫時不可見的。對于這樣的情況,在寫正則表達式時要跳出所能見到的文本的圈子,開拓思路,作出“戰略性前瞻”。例如,經常收到這樣的垃圾短信:“發*票”、“發#漂”。如果要寫規則屏蔽這樣煩人的垃圾短信,不但要能寫出可以匹配當前文本的正則表達式 發[*#](?:票|漂),還要能夠想到 發.(?:票|漂|飄)之類可能出現的“變種”。這在具體的領域或許會有針對性的規則,不多言。這樣做的目的是消除漏匹配,延長正則表達式的生命周期。
明確。具體說來,就是謹慎用點號這樣的元字符,盡可能不用星號和加號這樣的任意量詞。只要能確定范圍的,例如w,就不要用點號;只要能夠預測重復次數的,就不要用任意量詞。例如,寫析取推ter消息的腳本,假設一條消息的xml正文部分結構是<span class=”msg”>…</span>且正文中無尖括號,那么<span class=”msg”>[^<]{1,480}</span>這種寫法的思路要好于<span class=”msg”>.*</span>,原因有二:一是使用[^<],它保證了文本的范圍不會超出下一個小于號所在的位置;二是明確長度范圍,{1,480},其依據是一條推ter消息大致能的字符長度范圍。當然,480這個長度是否正確還可推敲,但是這種思路是值得借鑒的。說得狠一點,“濫用點號、星號和加號是不環保、不負責任的做法”。
不要讓稻草壓死駱駝。每使用一個普通括號()而不是非捕獲型括號(?:…),就會保留一部分內存等著你再次訪問。這樣的正則表達式、無限次地運行次數,無異于一根根稻草的堆加,終于能將駱駝壓死。養成合理使用(?:…)括號的習慣。
寧簡勿繁。將一條復雜的正則表達式拆分為兩條或多條簡單的正則表達式,編程難度會降低,運行效率會提升。例如用來消除行首和行尾空白字符的正則表達式s/^s+|s+$//g;,其運行效率理論上要低于s/^s+//g; s/s+$//g; 。這個例子出自《精通正則表達式》第五章,書中對它的評論是“它幾乎總是最快的,而且顯然最容易理解”。既快又容易理解,何樂而不為?工作中我們還有其它的理由要將C==(A|B)這樣的正則表達式拆為A和B兩條表達式分別執行。例如,雖然A和B這兩種情況只要有一種能夠擊中所需要的文本模式就會成功匹配,但是如果只要有一條子表達式(例如A)會產生誤匹配,那么不論其它的子表達式(例如B)效率如何之高,范圍如何精準,C的總體精準度也會因A而受到影響。
巧妙定位。有時候,我們需要匹配的the,是作為單詞的the(兩邊有空格),而不是作為單詞一部分的t-h-e的有序排列(例如together中的the)。在適當的時候用上^,$,b等等定位錨點,能有效提升找到成功匹配、淘汰不成功匹配的效率。
來自:http://www.ha97.com/4458.html