關(guān)于正則表達式的文檔很多，但大部分都是英文的，即便有中文的文檔，也翻譯或改編自英文文檔。在介紹功能時，這樣做沒有大問題，但真要處理文本，就 可能會遇到一些英文開發(fā)或應(yīng)用環(huán)境中難得見到的問題。比如中文之類多字節(jié)字符的匹配，就是如此。所以，這篇文章專門談?wù)務(wù)齽t表達式如何處理多字節(jié)字符，更 準確地說，是如何處理Unicode編碼的文本（為什么只提到Unicode編碼，而沒有提到其它編碼，理由在后面詳述）。

　　首先介紹關(guān)于編碼的基礎(chǔ)知識：

　　通常來說，英文編碼較為統(tǒng)一，往往采用ascii編碼或兼容ascii的編碼（即編碼表的前127位與ascii編碼一致，常用的各種編碼，包 括Unicode編碼都是如此）。也就是說，英文字母、阿拉伯?dāng)?shù)字和英文的各種符號，在不同編碼下的表示是一樣的，比如字母A，其編碼總是41，常見的編 碼中，英文字符和半角標(biāo)點符號的編碼都等于ascii編碼，通常只用一個字節(jié)表示。

　　但是中文的情況則不同，常見的中文編碼有GBK（CP936）和Unicode兩種，同一個中文字符在不同編碼下的值并不相同，比如“發(fā)” 字，GBK編碼的值為b7 a2，用兩個字節(jié)表示；而Unicode編碼的值（也就是代碼點，Code Point）為53 d1。如果用UTF-8編碼保存，需要3個字節(jié)（e5 8f 91）；用UTF-16編碼保存，需要4個字節(jié)（fe ff 53 d1）。

　　正因為中文字符需要多個字節(jié)來表示，常見的正則表達式的文檔就有可能無法覆蓋這種情況。比如常見的資料都說，點號『.』可以匹配“除換行符\n之外的任意字符”，但這可能只適用于“單字節(jié)字符”，因為點號匹配的其實只是“除換行符\n之外的任意字節(jié)”而已。不信，我們可以來試試看（以下例子中，程序均使用UTF-8編碼）：

Python 2.x
>>> re.search('^.$', '發(fā)') == None # True
PHP 4.x/5.x
preg_match('/^.$/', '發(fā)') // 0
Ruby 1.8
irb(main):001:0> '發(fā)' =~ /^.$/ # nil

　　之所以會出現(xiàn)這種情況，是因為正則表達式無法正確將多個字節(jié)識別為“單個字符”，讓點號『.』能正確匹配。不過在Python 3.x、Java、.NET和Ruby 1.9中，字符串默認都是采用Unicode編碼，所以不存在上面的問題。如果你使用的是Python 2.x、Ruby 1.8或PHP，也可以顯式指定采用Unicode模式。

Python 2.x
>>> re.search('^.$', u'發(fā)') == None #False
PHP 4.x/5.x
preg_match('/^.$/u', '發(fā)') // 1
Ruby 1.8
irb(main):001:0> '發(fā)' =~ /^.$/u # 0

　　如果你細心就會發(fā)現(xiàn)，在Python 2.x中，我們指定的字符串使用Unicode編碼，而文檔里說了，正則表達式也可以指定Unicode模式的；相反，在PHP和Ruby中，我們指定正則表達式使用Unicode編碼，而字符串并沒有指定。這到底是怎么回事呢？

　　我們知道，正則表達式的操作可以簡要概括為“用正則表達式去匹配字符串”，它涉及兩個對象：正則表達式和字符串。對字符串來說，如果沒有設(shè)定 Unicode模式，則多字節(jié)字符很可能會拆開為多個單字節(jié)字符對待（雖然它們并不是合法的ascii字符），Python 2.x中就是如此，“發(fā)”字在沒有設(shè)定Unicode編碼時，變成了3個單字節(jié)字符構(gòu)成的字符串，點號『.』只能匹配其中的單個“字符”。如果顯式將正則 表達式設(shè)定為Unicode字符串（也就是在 u'發(fā)' ），則“發(fā)”字視為單個字符，點號可以匹配。

　　而且，如果你在正則表達式的字符組里使用了中文字符，表示正則表達式的字符串，也應(yīng)該設(shè)定為Unicode字符串，否則正則表達式會認為字符組里不是單個字符，而是3個單字節(jié)字符：

Python 2.x
>>> re.search('^[我]$', u'我') == None # True
>>> re.search(u'^[我]$', u'我') == None # False

　　另一方面，在PHP和Ruby中并不存在“Unicode字符串”，所以我們無法修改字符串的屬性。但是，設(shè)定正則表達式為Unicode模 式，正則表達式也可以正確識別字符串中的Unicode字符。所以，如果你用PHP或Ruby的正則表達式處理Unicode字符串，一定不要忘記指定 Unicode模式。

　　點號『.』對Unicode字符的匹配“我”（采用UTF-8編碼）。

　　注：PHP和Ruby的正則表達式本身是不包含分隔符（分隔符可以有很多種，常見的是反斜線/）的，但PHP指定Unicode模式必須在后一個分隔符之后寫u，所以在這里將分隔符也寫出來。

　　不過，如果你熟悉Python語言，會發(fā)現(xiàn)Python也可以指定正則表達式使用Unicode模式，這又是怎么回事呢？

　　不妨回頭仔細想想你讀過的文檔，正則表達式中的『\d』和『\w』，都是如何解釋的？或許你的第一反應(yīng)是：『\d』等價于『[0-9]』，『\w』等價于『[0-9a-zA-Z_]』。因為有些文檔說明了這種等價關(guān)系，有些文檔卻說：『\d』匹配數(shù)字字符，『\w』匹配單詞字符。 然而這只是針對ascii編碼的規(guī)定，在Unicode編碼中，全角數(shù)字０、１、２之類，應(yīng)該也可以算“數(shù)字字符”，由『\d』匹配；中文的字符，應(yīng)該也 可以算“單詞字符”，由『\w』匹配；同樣的道理，中文的全角空格，應(yīng)該也可以算作“空白字符”，由『\s』匹配。所以，如果你在Python中指定了正 則表達式使用，『\d』、『\w』、『\s』就能匹配全角數(shù)字、中文字符、全角空格。

Python 2.x（字符均為全角）
>>> re.search('(?u)^\d$', u'１') == None # True
>>> re.search('(?u)^\w$', u'發(fā)') == None # True
>>> re.search('(?u)^\s', u' ') == None # True

　　老實說，這樣的規(guī)定有時候確實讓人抓狂，假設(shè)你希望用正則表達式『\d{6,12}』來驗證一個長度在6到12之間的數(shù)字字符串，卻沒留意『\d』能匹配全角數(shù)字，驗證就不夠嚴密了。

　　下面的表格列出了常見語言中的匹配規(guī)定：

　　注1：一般來說，單詞邊界『\b』能匹配的位置是：一端是『\w』，一端不是『\w』（也可以什么都沒有），其中『\w』的規(guī)定與『\w』一樣，但Java中則不是這樣，細節(jié)比較復(fù)雜，這里不展開，有興趣的讀者可以自己試驗。

　　注2：在Python 3中可以在表達式之前添加『(?a)』指定ascii模式。

　　雖然常見的中文字符編碼有GBK和Unicode兩種，但如果需要使用正則表達式處理中文，我強烈推薦使用Unicode字符，不僅是因為正則 表達式提供了對Unicode的現(xiàn)成支持，而且因為GBK編碼可能會有其它問題。比如：我們要求匹配“收”字或者“發(fā)”字，很自然會想到使用字符組『[收 發(fā)]』，這思路是對的，但如果采用GBK編碼，正則引擎見到的很可能不是“兩個字符構(gòu)成的字符組”，而是“四個字節(jié)構(gòu)成的字符組”。

　　使用GBK編碼，[收發(fā)]的解釋『ca d5 b7 a2』

　　如果我們用『[收發(fā)]』來匹配字符“罰”（它的GBK編碼是b7 a3），就會產(chǎn)生錯誤——雖然“罰”字既不等于“收”也不等于“發(fā)”，但“罰”和『[收發(fā)]』卻可以匹配一個字節(jié)。

　　GBK編碼的情況：

　　罰 b7 a3

　　[收發(fā)] ca d5 b7 a2

　　Unicode編碼的情況（因為Unicode編碼能正確識別，無論采用UTF-8還是UTF-16，Unicode字符都會正確轉(zhuǎn)化為Unicode編碼點）

　　罰 7f5a

　　[收發(fā)] 6536 53d1

　　“罰”的Unicode編碼是7f5a，無論如何也不會發(fā)生錯誤匹配。

　　如果出于某些限制，只能使用GBK編碼，也有一個偏方準確保證『[收發(fā)]』的匹配，就是把字符組『[收發(fā)]』改成多選分支『(收|發(fā))』。此時如果要匹配成功，只能是兩個連續(xù)的字節(jié)ca d5或者b7 a2，而“罰”字兩個字節(jié)為b7 a3，無法匹配。

　　但這樣也會有問題，因為在GBK編碼下字符串被當(dāng)作“字節(jié)序列”來對待。比如字符串 “賬珍”對應(yīng)四個字節(jié)，d5 ca d5 e4，其中正好出現(xiàn)了“收”字對應(yīng)的兩個字節(jié)ca d5，正則表達式就可能在此處匹配成功。

　　更重要的問題在于排除型字符組的匹配，仍然使用上面的例子，假如我們希望匹配一個“收”和“罰”之外的字符，自然的思路就是使用排除型字符組『[^收發(fā)]』。但是通過上面的講解，我們已經(jīng)知道，這樣“排除”的并不是2個字符，而是4個字節(jié)：ca d5 b7 a2。但“罰”字的GBK編碼為b7 a3，b7這個字節(jié)被“排除”了，所以正則表達式會顯示“罰”字不能由『[^收發(fā)]』匹配，這完全違背了我們的本意。

　　總的來說，所以如果使用GBK編碼（或者說非Unicode編碼），對此類問題基本是無解的。因此，根本的辦法還是使用Unicode編碼。

　　推薦使用Unicode的另一個理由是，使用Unicode，我們可以指定字符的代碼點范圍，實現(xiàn)“匹配一個中文字符”的表達式。因為正則引擎 能正確識別的多字節(jié)字符一般只有Unicode字符，所以即便我們知道GBK編碼中中文字符的編碼范圍，也無法指定一個字符組來匹配其中的字符，而 Unicode編碼則可以。

　　在Unicode編碼表里，代碼點4e00-9fff歸類為“CJK 統(tǒng)一表意符號”CJK Unified Ideographs（參見//en.wikipedia.org/wiki/CJK_Unified_Ideographs），涵蓋了絕大多 數(shù)中文字符，我們可以某個字符組里匹配此范圍中任何一個代碼點，但是在不同語言中指定這個范圍的辦法并不同。作為本文的結(jié)尾，在這里列出各種語言中能匹配 “中文字符”的字符組：