說明正則表達式通常用於兩種任務驗證搜索/替換用於驗證時通常需要在前後分別加上^和$以匹配整個待驗證字符串;搜索/替換時是否加上此限定則根據搜索的要求而定此外也有可能要在前後加上b而不是^和$此表所列的常用正則表達式除個別外均未在前後加上任何限定請根據需要自行處理
正則表達式(英文Regular Expression)在計算機科學中是指一個用來描述或者匹配一系列符合某個句法規則的字符串的單個字符串
| 說明 |
正則表達式 |
網址（URL）
[azAz]+://[^s]*
IP地址(IP Address)
(([]d|[]|[]?dd?)){}([]d|[]|[]?dd?)
電子郵件(Email)
w+([+]w+)*@w+([]w+)*w+([]w+)*
QQ號碼
[]d{}
HTML標記(包含內容或自閉合)
<(*)(*)>*</>|<(*) />
密碼(由數字/大寫字母/小寫字母/標點符號組成四種都必有位以上)
(?=^{}$)(?=*d)(?=*W+)(?=*[AZ])(?=*[az])(?!*n)*$
日期(年月日)
(d{}|d{})((?([]))|([|]))((?[])|([]([]))|([|]))
日期(月/日/年)
((?[]{})|([|]))/(?[]|([][])|([|]))/(d{}|d{})
時間(小時:分鐘 小時制)
((|?)[]|[]):([][])
漢字(字符)
[ueufa]
中文及全角標點符號(字符)
[uueufeufeufeufeufeufebuffuffee]
中國大陸固定電話號碼
(d{}|d{})?(d{}|d{})
中國大陸手機號碼
d{}
中國大陸郵政編碼
[]d{}
中國大陸身份證號(位或位)
d{}(dd[xX])?
非負整數(正整數或零)
d+
正整數
[]*[][]*
負整數
[]*[][]*
整數
?d+
小數
(?d+)(d+)?
以上正則表達式均經過多次測試並不斷增加因為不同程序或工具的正則表達式略有區別大家可以根據需要進行簡單修改
常用正則表達式
正則表達式用於字符串處理表單驗證等場合實用高效現將一些常用的表達式收集於此以備不時之需
用戶名/^[az_]{}$/
密碼/^[az_]{}$/
十六進制值/^#?([af]{}|[af]{})$/
電子郵箱/^([az_]+)@([daz]+)([az]{})$/
URL/^(https?://)?([daz]+)([az]{})([/w ]*)*/?$/
IP 地址/^(?:(?:[]|[][]|[]?[][]?)){}(?:[]|[][]|[]?[][]?)$/
HTML 標簽/^<([az]+)([^<]+)*(?:>(*)</>|s+/>)$/
Unicode編碼中的漢字范圍/^[ueufa]{}$/
匹配中文字符的正則表達式 [ueufa]
評注匹配中文還真是個頭疼的事有了這個表達式就好辦了
匹配雙字節字符(包括漢字在內)[^xxff]
評注可以用來計算字符串的長度(一個雙字節字符長度計ASCII字符計)
匹配空白行的正則表達式ns*r
評注可以用來刪除空白行
匹配HTML標記的正則表達式<(S*?)[^>]*>*?|<*? />
評注網上流傳的版本太糟糕上面這個也僅僅能匹配部分對於復雜的嵌套標記依舊無能為力
匹配首尾空白字符的正則表達式^s*|s*$
評注可以用來刪除行首行尾的空白字符(包括空格制表符換頁符等等)非常有用的表達式
匹配Email地址的正則表達式w+([+]w+)*@w+([]w+)*w+([]w+)*
評注表單驗證時很實用
匹配網址URL的正則表達式[azAz]+://[^s]*
評注網上流傳的版本功能很有限上面這個基本可以滿足需求
匹配帳號是否合法(字母開頭允許字節允許字母數字下劃線)^[azAZ][azAZ_]{}$
評注表單驗證時很實用
匹配國內電話號碼d{}d{}|d{}d{}
評注匹配形式如 或
匹配騰訊QQ號[][]{}
評注騰訊QQ號從開始
匹配中國大陸郵政編碼[]d{}(?!d)
評注中國大陸郵政編碼為位數字
匹配身份證d{}|d{}
評注中國大陸的身份證為位或位
匹配ip地址d+d+d+d+
評注提取ip地址時有用
匹配特定數字
^[]d*$ //匹配正整數
^[]d*$ //匹配負整數
^?[]d*$ //匹配整數
^[]d*|$ //匹配非負整數(正整數 + )
^[]d*|$ //匹配非正整數(負整數 + )
^[]d*d*|d*[]d*$ //匹配正浮點數
^([]d*d*|d*[]d*)$ //匹配負浮點數
^?([]d*d*|d*[]d*|?+|)$ //匹配浮點數
^[]d*d*|d*[]d*|?+|$ //匹配非負浮點數(正浮點數 + )
^(([]d*d*|d*[]d*))|?+|$ //匹配非正浮點數(負浮點數 + )
評注處理大量數據時有用具體應用時注意修正
匹配特定字符串
^[AZaz]+$ //匹配由個英文字母組成的字符串
^[AZ]+$ //匹配由個英文字母的大寫組成的字符串
^[az]+$ //匹配由個英文字母的小寫組成的字符串
^[AZaz]+$ //匹配由數字和個英文字母組成的字符串
^w+$ //匹配由數字個英文字母或者下劃線組成的字符串
表達式全集
正則表達式有多種不同的風格下表是在PCRE中元字符及其在正則表達式上下文中的行為的一個完整列表
字符 |
描述 |
|
將下一個字符標記為一個特殊字符
或一個原義字符
或一個向後引用
或一個八進制轉義符
例如
“n”匹配字符“n”
“n”匹配一個換行符
序列“”匹配“”而“(”則匹配“(”
^ |
匹配輸入字符串的開始位置
如果設置了RegExp對象的Multiline屬性
^也匹配“n”或“r”之後的位置
$ |
匹配輸入字符串的結束位置
如果設置了RegExp對象的Multiline屬性
$也匹配“n”或“r”之前的位置
* |
匹配前面的子表達式零次或多次
例如
zo*能匹配“z”以及“zoo”
*等價於{
}
+ |
匹配前面的子表達式一次或多次
例如
“zo+”能匹配“zo”以及“zoo”
但不能匹配“z”
+等價於{
}
? |
匹配前面的子表達式零次或一次
例如
“do(es)?”可以匹配“do”或“does”中的“do”
?等價於{
}
{n} |
n是一個非負整數
匹配確定的n次
例如
“o{
}”不能匹配“Bob”中的“o”
但是能匹配“food”中的兩個o
{n} |
n是一個非負整數
至少匹配n次
例如
“o{
}”不能匹配“Bob”中的“o”
但能匹配“foooood”中的所有o
“o{
}”等價於“o+”
“o{
}”則等價於“o*”
{nm} |
m和n均為非負整數
其中n<=m
最少匹配n次且最多匹配m次
例如
“o{
}”將匹配“fooooood”中的前三個o
“o{
}”等價於“o?”
請注意在逗號和兩個數之間不能有空格
? |
當該字符緊跟在任何一個其他限制符（*
+
?
{n}
{n
}
{n
m}）後面時
匹配模式是非貪婪的
非貪婪模式盡可能少的匹配所搜索的字符串
而默認的貪婪模式則盡可能多的匹配所搜索的字符串
例如
對於字符串“oooo”
“o+?”將匹配單個“o”
而“o+”將匹配所有“o”
|
匹配除“n”之外的任何單個字符
要匹配包括“n”在內的任何字符
請使用像“[
n]”的模式
(pattern) |
匹配pattern並獲取這一匹配
所獲取的匹配可以從產生的Matches集合得到
在VBScript中使用SubMatches集合
在JScript中則使用$
…$
屬性
要匹配圓括號字符
請使用“(”或“)”
(?:pattern) |
匹配pattern但不獲取匹配結果
也就是說這是一個非獲取匹配
不進行存儲供以後使用
這在使用或字符“(|)”來組合一個模式的各個部分是很有用
例如“industr(?:y|ies)”就是一個比“industry|industries”更簡略的表達式
(?=pattern) |
正向預查
在任何匹配pattern的字符串開始處匹配查找字符串
這是一個非獲取匹配
也就是說
該匹配不需要獲取供以後使用
例如
“Windows(?=
|
|NT|
)”能匹配“Windows
”中的“Windows”
但不能匹配“Windows
”中的“Windows”
預查不消耗字符
也就是說
在一個匹配發生後
在最後一次匹配之後立即開始下一次匹配的搜索
而不是從包含預查的字符之後開始
(?!pattern) |
負向預查
在任何不匹配pattern的字符串開始處匹配查找字符串
這是一個非獲取匹配
也就是說
該匹配不需要獲取供以後使用
例如“Windows(?!
|
|NT|
)”能匹配“Windows
”中的“Windows”
但不能匹配“Windows
”中的“Windows”
預查不消耗字符
也就是說
在一個匹配發生後
在最後一次匹配之後立即開始下一次匹配的搜索
而不是從包含預查的字符之後開始
x|y |
匹配x或y
例如
“z|food”能匹配“z”或“food”
“(z|f)ood”則匹配“zood”或“food”
[xyz] |
字符集合
匹配所包含的任意一個字符
例如
“[abc]”可以匹配“plain”中的“a”
[^xyz] |
負值字符集合
匹配未包含的任意字符
例如
“[^abc]”可以匹配“plain”中的“p”
[az] |
字符范圍
匹配指定范圍內的任意字符
例如
“[a
z]”可以匹配“a”到“z”范圍內的任意小寫字母字符
[^az] |
負值字符范圍
匹配任何不在指定范圍內的任意字符
例如
“[^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 |
匹配一個數字字符
等價於[
]
D |
匹配一個非數字字符
等價於[^
]
f |
匹配一個換頁符
等價於x
c和cL
n |
匹配一個換行符
等價於x
a和cJ
r |
匹配一個回車符
等價於x
d和cM
s |
匹配任何空白字符
包括空格
制表符
換頁符等等
等價於[fnrtv]
S |
匹配任何非空白字符
等價於[^fnrtv]
t |
匹配一個制表符
等價於x
和cI
v |
匹配一個垂直制表符
等價於x
b和cK
w |
匹配包括下劃線的任何單詞字符
等價於“[A
Za
z
_]”
W |
匹配任何非單詞字符
等價於“[^A
Za
z
_]”
xn |
匹配n
其中n為十六進制轉義值
十六進制轉義值必須為確定的兩個數字長
例如
“x
”匹配“A”
“x
”則等價於“x
&
”
正則表達式中可以使用ASCII編碼
num |
匹配num
其中num是一個正整數
對所獲取的匹配的引用
例如
“(
)
”匹配兩個連續的相同字符
n |
標識一個八進制轉義值或一個向後引用
如果n之前至少n個獲取的子表達式
則n為向後引用
否則
如果n為八進制數字（
）
則n為一個八進制轉義值
nm |
標識一個八進制轉義值或一個向後引用
如果nm之前至少有nm個獲得子表達式
則nm為向後引用
如果nm之前至少有n個獲取
則n為一個後跟文字m的向後引用
如果前面的條件都不滿足
若n和m均為八進制數字（
）
則nm將匹配八進制轉義值nm
nml |
如果n為八進制數字（
）
且m和l均為八進制數字（
）
則匹配八進制轉義值nml
un |
匹配n
其中n是一個用四個十六進制數字表示的Unicode字符
例如
u
A
匹配版權符號（?）
以下是以PHP的語法所寫的示例
驗證字符串是否只含數字與英文字符串長度並在~個字符之間
$str = 'a1234';
if (preg_match("^[a-zA-Z0-9]{4,16}$", $str)) {
echo "驗證成功";
} else {
echo "驗證失敗";
}
?>
簡易的台灣身份證字號驗證
$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";
如何寫出高效率的正則表達式
如果純粹是為了挑戰自己的正則水平，用來實現一些特效(例如使用正則表達式計算質數、解線性方程)，效率不是問題;如果所寫的正則表達式只是為了滿足一兩次、幾十次的運行，優化與否區別也不太大。TW.WinGwiT.Com但是，如果所寫的正則表達式會百萬次、千萬次地運行，效率就是很大的問題了。我這裡總結了幾條提升正則表達式運行效率的經驗(工作中學到的，看書學來的，自己的體會)，貼在這裡。如果您有其它的經驗而這裡沒有提及，歡迎賜教。
為行文方便，先定義兩個概念。
誤匹配：指正則表達式所匹配的內容范圍超出了所需要范圍，有些文本明明不符合要求，但是被所寫的正則式“擊中了”。例如，如果使用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，就不要用點號;只要能夠預測重復次數的，就不要用任意量詞。例如，寫析取twitter消息的腳本，假設一條消息的xml正文部分結構是…且正文中無尖括號，那麼[^<]{1,480}這種寫法的思路要好於.*，原因有二：一是使用[^<]，它保證了文本的范圍不會超出下一個小於號所在的位置;二是明確長度范圍，{1,480}，其依據是一條twitter消息大致能的字符長度范圍。當然，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等等定位錨點，能有效提升找到成功匹配、淘汰不成功匹配的效率。
From:http://tw.wingwit.com/Article/program/Java/JSP/201311/20218.html
