創建對象并寫入信息: 寫在另外一個FLA文件中,讀取信息: 文件保存到: |
李一男2003年在港灣給開發人員培訓時的語錄,堪稱新時代的毛澤東思想。 【10】該出手時便出手!永遠不可能有100%把握?。。l件差不多就要大膽去干,去闖出自己的事業,不要猶豫,不要彷徨,干了不一定成功,但至少為下一次沖擊積累了經驗,不干永遠沒出息,而且要干成必然要經歷失敗。不經歷風雨,怎么見彩虹,沒有人能隨隨便便成功 ! |
版本:v2.3 (2008-4-13) 作者:deerchao 轉載請注明來源
30分鐘內讓你明白正則表達式是什么,并對它有一些基本的了解,讓你可以在自己的程序或網頁里使用它。
最重要的是——請給我30分鐘,如果你沒有使用正則表達式的經驗,請不要試圖在30秒內入門——除非你是超人 :)
別被下面那些復雜的表達式嚇倒,只要跟著我一步一步來,你會發現正則表達式其實并沒有你想像中的那么困難。當然,如果你看完了這篇教程之后,發現自己明白了很多,卻又幾乎什么都記不得,那也是很正常的——我認為,沒接觸過正則表達式的人在看完這篇教程后,能把提到過的語法記住80%以上的可能性為零。這里只是讓你明白基本的原理,以后你還需要多練習,多使用,才能熟練掌握正則表達式。
除了作為入門教程之外,本文還試圖成為可以在日常工作中使用的正則表達式語法參考手冊。就作者本人的經歷來說,這個目標還是完成得不錯的——你看,我自己也沒能把所有的東西記下來,不是嗎?
清除格式?文本格式約定:專業術語?元字符/語法格式?正則表達式?正則表達式中的一部分(用于分析)?對其進行匹配的源字符串?對正則表達式或其中一部分的說明
隱藏邊注?本文右邊有一些注釋,主要是用來提供一些相關信息,或者給沒有程序員背景的讀者解釋一些基本概念,通??梢院雎浴?/p>
字符是計算機軟件處理文字時最基本的單位,可能是字母,數字,標點符號,空格,換行符,漢字等等。字符串是0個或更多個字符的序列。文本也就是文字,字符串。說某個字符串匹配某個正則表達式,通常是指這個字符串里有一部分(或幾部分分別)能滿足表達式給出的條件。
在編寫處理字符串的程序或網頁時,經常會有查找符合某些復雜規則的字符串的需要。正則表達式就是用于描述這些規則的工具。換句話說,正則表達式就是記錄文本規則的代碼。
很可能你使用過Windows/Dos下用于文件查找的通配符(wildcard),也就是*和?。如果你想查找某個目錄下的所有的Word文檔的話,你會搜索*.doc。在這里,*會被解釋成任意的字符串。和通配符類似,正則表達式也是用來進行文本匹配的工具,只不過比起通配符,它能更精確地描述你的需求——當然,代價就是更復雜——比如你可以編寫一個正則表達式,用來查找所有以0開頭,后面跟著2-3個數字,然后是一個連字號“-”,最后是7或8位數字的字符串(像010-12345678或0376-7654321)。
學習正則表達式的最好方法是從例子開始,理解例子之后再自己對例子進行修改,實驗。下面給出了不少簡單的例子,并對它們作了詳細的說明。
假設你在一篇英文小說里查找hi,你可以使用正則表達式hi。
這幾乎是最簡單的正則表達式了,它可以精確匹配這樣的字符串:由兩個字符組成,前一個字符是h,后一個是i。通常,處理正則表達式的工具會提供一個忽略大小寫的選項,如果選中了這個選項,它可以匹配hi,HI,Hi,hI這四種情況中的任意一種。
不幸的是,很多單詞里包含hi這兩個連續的字符,比如him,history,high等等。用hi來查找的話,這里邊的hi也會被找出來。如果要精確地查找hi這個單詞的話,我們應該使用\bhi\b。
\b是正則表達式規定的一個特殊代碼(好吧,某些人叫它元字符,metacharacter),代表著單詞的開頭或結尾,也就是單詞的分界處。雖然通常英文的單詞是由空格,標點符號或者換行來分隔的,但是\b并不匹配這些單詞分隔字符中的任何一個,它只匹配一個位置。
如果需要更精確的說法,\b匹配這樣的位置:它的前一個字符和后一個字符不全是(一個是,一個不是或不存在)\w。
假如你要找的是hi后面不遠處跟著一個Lucy,你應該用\bhi\b.*\bLucy\b。
這里,.是另一個元字符,匹配除了換行符以外的任意字符。*同樣是元字符,不過它代表的不是字符,也不是位置,而是數量——它指定*前邊的內容可以連續重復出現任意次以使整個表達式得到匹配。因此,.*連在一起就意味著任意數量的不包含換行的字符?,F在\bhi\b.*\bLucy\b的意思就很明顯了:先是一個單詞hi,然后是任意個任意字符(但不能是換行),最后是Lucy這個單詞。
換行符就是'\n',ASCII編碼為10(十六進制0x0A)的字符。
如果同時使用其它元字符,我們就能構造出功能更強大的正則表達式。比如下面這個例子:
0\d\d-\d\d\d\d\d\d\d\d匹配這樣的字符串:以0開頭,然后是兩個數字,然后是一個連字號“-”,最后是8個數字(也就是中國的電話號碼。當然,這個例子只能匹配區號為3位的情形)。
這里的\d是個新的元字符,匹配一位數字(0,或1,或2,或……)。-不是元字符,只匹配它本身——連字符或者減號。
為了避免那么多煩人的重復,我們也可以這樣寫這個表達式:0\d{2}-\d{8}。 這里\d后面的{2}({8})的意思是前面\d必須連續重復匹配2次(8次)。
其它可用的測試工具:
如果你不覺得正則表達式很難讀寫的話,要么你是一個天才,要么,你不是地球人。正則表達式的語法很令人頭疼,即使對經常使用它的人來說也是如此。由于難于讀寫,容易出錯,所以找一種工具對正則表達式進行測試是很有必要的。
由于在不同的環境下正則表達式的一些細節是不相同的,本教程介紹的是微軟 .Net Framework 2.0下正則表達式的行為,所以,我向你介紹一個.Net下的工具Regex Tester。首先你確保已經安裝了.Net Framework 2.0,然后下載Regex Tester。這是個綠色軟件,下載完后打開壓縮包,直接運行RegexTester.exe就可以了。
下面是Regex Tester運行時的截圖:
現在你已經知道幾個很有用的元字符了,如\b,.,*,還有\d.正則表達式里還有更多的元字符,比如\s匹配任意的空白符,包括空格,制表符(Tab),換行符,中文全角空格等。\w匹配字母或數字或下劃線或漢字等。
對中文/漢字的特殊處理是由.Net提供的正則表達式引擎支持的,其它環境下的具體情況請查看相關文檔。
下面來看看更多的例子:
\ba\w*\b匹配以字母a開頭的單詞——先是某個單詞開始處(\b),然后是字母a,然后是任意數量的字母或數字(\w*),最后是單詞結束處(\b)。
好吧,現在我們說說正則表達式里的單詞是什么意思吧:就是多于一個的連續的\w。不錯,這與學習英文時要背的成千上萬個同名的東西的確關系不大 :)
\d+匹配1個或更多連續的數字。這里的+是和*類似的元字符,不同的是*匹配重復任意次(可能是0次),而+則匹配重復1次或更多次。
\b\w{6}\b 匹配剛好6個字母/數字的單詞。
代碼 | 說明 |
---|---|
. | 匹配除換行符以外的任意字符 |
\w | 匹配字母或數字或下劃線或漢字 |
\s | 匹配任意的空白符 |
\d | 匹配數字 |
\b | 匹配單詞的開始或結束 |
^ | 匹配字符串的開始 |
$ | 匹配字符串的結束 |
元字符^(和數字6在同一個鍵位上的符號)和$都匹配一個位置,這和\b有點類似。^匹配你要用來查找的字符串的開頭,$匹配結尾。這兩個代碼在驗證輸入的內容時非常有用,比如一個網站如果要求你填寫的QQ號必須為5位到12位數字時,可以使用:^\d{5,12}$。
這里的{5,12}和前面介紹過的{2}是類似的,只不過{2}匹配只能不多不少重復2次,{5,12}則是重復的次數不能少于5次,不能多于12次,否則都不匹配。
因為使用了^和$,所以輸入的整個字符串都要用來和\d{5,12}來匹配,也就是說整個輸入必須是5到12個數字,因此如果輸入的QQ號能匹配這個正則表達式的話,那就符合要求了。
和忽略大小寫的選項類似,有些正則表達式處理工具還有一個處理多行的選項。如果選中了這個選項,^和$的意義就變成了匹配行的開始處和結束處。
如果你想查找元字符本身的話,比如你查找.,或者*,就出現了問題:你沒辦法指定它們,因為它們會被解釋成別的意思。這時你就得使用\來取消這些字符的特殊意義。因此,你應該使用\.和\*。當然,要查找\本身,你也得用\\.
例如:unibetter\.com匹配unibetter.com,C:\\Windows匹配C:\Windows。
你已經看過了前面的*,+,{2},{5,12}這幾個匹配重復的方式了。下面是正則表達式中所有的限定符(指定數量的代碼,例如*,{5,12}等):
代碼/語法 | 說明 |
---|---|
* | 重復零次或更多次 |
+ | 重復一次或更多次 |
? | 重復零次或一次 |
{n} | 重復n次 |
{n,} | 重復n次或更多次 |
{n,m} | 重復n到m次 |
下面是一些使用重復的例子:
Windows\d+匹配Windows后面跟1個或更多數字
^\w+匹配一行的第一個單詞(或整個字符串的第一個單詞,具體匹配哪個意思得看選項設置)
要想查找數字,字母或數字,空白是很簡單的,因為已經有了對應這些字符集合的元字符,但是如果你想匹配沒有預定義元字符的字符集合(比如元音字母a,e,i,o,u),應該怎么辦?
很簡單,你只需要在方括號里列出它們就行了,像[aeiou]就匹配任何一個英文元音字母,[.?!]匹配標點符號(.或?或!)。
我們也可以輕松地指定一個字符范圍,像[0-9]代表的含意與\d就是完全一致的:一位數字;同理[a-z0-9A-Z_]也完全等同于\w(如果只考慮英文的話)。
下面是一個更復雜的表達式:\(?0\d{2}[) -]?\d{8}。
“(”和“)”也是元字符,后面的分組節里會提到,所以在這里需要使用轉義。
這個表達式可以匹配幾種格式的電話號碼,像(010)88886666,或022-22334455,或02912345678等。我們對它進行一些分析吧:首先是一個轉義字符\(,它能出現0次或1次(?),然后是一個0,后面跟著2個數字(\d{2}),然后是)或-或空格中的一個,它出現1次或不出現(?),最后是8個數字(\d{8})。
不幸的是,剛才那個表達式也能匹配010)12345678或(022-87654321這樣的“不正確”的格式。要解決這個問題,我們需要用到分枝條件。正則表達式里的分枝條件指的是有幾種規則,如果滿足其中任意一種規則都應該當成匹配,具體方法是用|把不同的規則分隔開。聽不明白?沒關系,看例子:
0\d{2}-\d{8}|0\d{3}-\d{7}這個表達式能匹配兩種以連字號分隔的電話號碼:一種是三位區號,8位本地號(如010-12345678),一種是4位區號,7位本地號(0376-2233445)。
\(0\d{2}\)[- ]?\d{8}|0\d{2}[- ]?\d{8}這個表達式匹配3位區號的電話號碼,其中區號可以用小括號括起來,也可以不用,區號與本地號間可以用連字號或空格間隔,也可以沒有間隔。你可以試試用分枝條件把這個表達式擴展成也支持4位區號的。
\d{5}-\d{4}|\d{5}這個表達式用于匹配美國的郵政編碼。美國郵編的規則是5位數字,或者用連字號間隔的9位數字。之所以要給出這個例子是因為它能說明一個問題:使用分枝條件時,要注意各個條件的順序。如果你把它改成\d{5}|\d{5}-\d{4}的話,那么就只會匹配5位的郵編(以及9位郵編的前5位)。原因是匹配分枝條件時,將會從左到右地測試每個條件,如果滿足了某個分枝的話,就不會去再管其它的條件了。
我們已經提到了怎么重復單個字符(直接在字符后面加上限定符就行了);但如果想要重復多個字符又該怎么辦?你可以用小括號來指定子表達式(也叫做分組),然后你就可以指定這個子表達式的重復次數了,你也可以對子表達式進行其它一些操作(后面會有介紹)。
(\d{1,3}\.){3}\d{1,3}是一個簡單的IP地址匹配表達式。要理解這個表達式,請按下列順序分析它:\d{1,3}匹配1到3位的數字,(\d{1,3}\.){3}匹配三位數字加上一個英文句號(這個整體也就是這個分組)重復3次,最后再加上一個一到三位的數字(\d{1,3})。
IP地址中每個數字都不能大于255,大家千萬不要被《24》第三季的編劇給忽悠了...
不幸的是,它也將匹配256.300.888.999這種不可能存在的IP地址。如果能使用算術比較的話,或許能簡單地解決這個問題,但是正則表達式中并不提供關于數學的任何功能,所以只能使用冗長的分組,選擇,字符類來描述一個正確的IP地址:((2[0-4]\d|25[0-5]|[01]?\d\d?)\.){3}(2[0-4]\d|25[0-5]|[01]?\d\d?)。
理解這個表達式的關鍵是理解2[0-4]\d|25[0-5]|[01]?\d\d?,這里我就不細說了,你自己應該能分析得出來它的意義。
有時需要查找不屬于某個能簡單定義的字符類的字符。比如想查找除了數字以外,其它任意字符都行的情況,這時需要用到反義:
代碼/語法 | 說明 |
---|---|
\W | 匹配任意不是字母,數字,下劃線,漢字的字符 |
\S | 匹配任意不是空白符的字符 |
\D | 匹配任意非數字的字符 |
\B | 匹配不是單詞開頭或結束的位置 |
[^x] | 匹配除了x以外的任意字符 |
[^aeiou] | 匹配除了aeiou這幾個字母以外的任意字符 |
例子:\S+匹配不包含空白符的字符串。
<a[^>]+>匹配用尖括號括起來的以a開頭的字符串。
使用小括號指定一個子表達式后,匹配這個子表達式的文本(也就是此分組捕獲的內容)可以在表達式或其它程序中作進一步的處理。默認情況下,每個分組會自動擁有一個組號,規則是:從左向右,以分組的左括號為標志,第一個出現的分組的組號為1,第二個為2,以此類推。
后向引用用于重復搜索前面某個分組匹配的文本。例如,\1代表分組1匹配的文本。難以理解?請看示例:
\b(\w+)\b\s+\1\b可以用來匹配重復的單詞,像go go, 或者kitty kitty。這個表達式首先是一個單詞,也就是單詞開始處和結束處之間的多于一個的字母或數字(\b(\w+)\b),這個單詞會被捕獲到編號為1的分組中,然后是1個或幾個空白符(\s+),最后是分組1中捕獲的內容(也就是前面匹配的那個單詞)(\1)。
你也可以自己指定子表達式的組名。要指定一個子表達式的組名,請使用這樣的語法:(?<Word>\w+)(或者把尖括號換成'也行:(?'Word'\w+)),這樣就把\w+的組名指定為Word了。要反向引用這個分組捕獲的內容,你可以使用\k<Word>,所以上一個例子也可以寫成這樣:\b(?<Word>\w+)\b\s+\k<Word>\b。
使用小括號的時候,還有很多特定用途的語法。下面列出了最常用的一些:
分類 | 代碼/語法 | 說明 |
---|---|---|
捕獲 | (exp) | 匹配exp,并捕獲文本到自動命名的組里 |
(?<name>exp) | 匹配exp,并捕獲文本到名稱為name的組里,也可以寫成(?'name'exp) | |
(?:exp) | 匹配exp,不捕獲匹配的文本,也不給此分組分配組號 | |
零寬斷言 | (?=exp) | 匹配exp前面的位置 |
(?<=exp) | 匹配exp后面的位置 | |
(?!exp) | 匹配后面跟的不是exp的位置 | |
(?<!exp) | 匹配前面不是exp的位置 | |
注釋 | (?#comment) | 這種類型的分組不對正則表達式的處理產生任何影響,用于提供注釋讓人閱讀 |
我們已經討論了前兩種語法。第三個(?:exp)不會改變正則表達式的處理方式,只是這樣的組匹配的內容不會像前兩種那樣被捕獲到某個組里面,也不會擁有組號。
地球人,是不是覺得這些術語名稱太復雜,太難記了?我也和你一樣。知道有這么一種東西就行了,它叫什么,隨它去吧!“無名,萬物之始...”
接下來的四個用于查找在某些內容(但并不包括這些內容)之前或之后的東西,也就是說它們像\b,^,$那樣用于指定一個位置,這個位置應該滿足一定的條件(即斷言),因此它們也被稱為零寬斷言。最好還是拿例子來說明吧:
斷言用來聲明一個應該為真的事實。正則表達式中只有當斷言為真時才會繼續進行匹配。
(?=exp)也叫零寬度正預測先行斷言,它斷言自身出現的位置的后面能匹配表達式exp。比如\b\w+(?=ing\b),匹配以ing結尾的單詞的前面部分(除了ing以外的部分),如查找I'm singing while you're dancing.時,它會匹配sing和danc。
(?<=exp)也叫零寬度正回顧后發斷言,它斷言自身出現的位置的前面能匹配表達式exp。比如(?<=\bre)\w+\b會匹配以re開頭的單詞的后半部分(除了re以外的部分),例如在查找reading a book時,它匹配ading。
假如你想要給一個很長的數字中每三位間加一個逗號(當然是從右邊加起了),你可以這樣查找需要在前面和里面添加逗號的部分:((?<=\d)\d{3})*\b,用它對1234567890進行查找時結果是234567890。
下面這個例子同時使用了這兩種斷言:(?<=\s)\d+(?=\s)匹配以空白符間隔的數字(再次強調,不包括這些空白符)。
前面我們提到過怎么查找不是某個字符或不在某個字符類里的字符的方法(反義)。但是如果我們只是想要確保某個字符沒有出現,但并不想去匹配它時怎么辦?例如,如果我們想查找這樣的單詞--它里面出現了字母q,但是q后面跟的不是字母u,我們可以嘗試這樣:
\b\w*q[^u]\w*\b匹配包含后面不是字母u的字母q的單詞。但是如果多做測試(或者你思維足夠敏銳,直接就觀察出來了),你會發現,如果q出現在單詞的結尾的話,像Iraq,Benq,這個表達式就會出錯。這是因為[^u]總要匹配一個字符,所以如果q是單詞的最后一個字符的話,后面的[^u]將會匹配q后面的單詞分隔符(可能是空格,或者是句號或其它的什么),后面的\w*\b將會匹配下一個單詞,于是\b\w*q[^u]\w*\b就能匹配整個Iraq fighting。負向零寬斷言能解決這樣的問題,因為它只匹配一個位置,并不消費任何字符?,F在,我們可以這樣來解決這個問題:\b\w*q(?!u)\w*\b。
零寬度負預測先行斷言 (?!exp),斷言此位置的后面不能匹配表達式exp。例如:\d{3}(?!\d)匹配三位數字,而且這三位數字的后面不能是數字;\b((?!abc)\w)+\b匹配不包含連續字符串abc的單詞。
同理,我們可以用(?<!exp),零寬度正回顧后發斷言來斷言此位置的前面不能匹配表達式exp:(?<![a-z])\d{7}匹配前面不是小寫字母的七位數字。
請詳細分析表達式(?<=<(\w+)>).*(?=<\/\1>),這個表達式最能表現零寬斷言的真正用途。
一個更復雜的例子:(?<=<(\w+)>).*(?=<\/\1>)匹配不包含屬性的簡單HTML標簽內里的內容。(<?(\w+)>)指定了這樣的前綴:被尖括號括起來的單詞(比如可能是<b>),然后是.*(任意的字符串),最后是一個后綴(?=<\/\1>)。注意后綴里的\/,它用到了前面提過的字符轉義;\1則是一個反向引用,引用的正是捕獲的第一組,前面的(\w+)匹配的內容,這樣如果前綴實際上是<b>的話,后綴就是</b>了。整個表達式匹配的是<b>和</b>之間的內容(再次提醒,不包括前綴和后綴本身)。
小括號的另一種用途是通過語法(?#comment)來包含注釋。例如:2[0-4]\d(?#200-249)|25[0-5](?#250-255)|[01]?\d\d?(?#0-199)。
要包含注釋的話,最好是啟用“忽略模式里的空白符”選項,這樣在編寫表達式時能任意的添加空格,Tab,換行,而實際使用時這些都將被忽略。啟用這個選項后,在#后面到這一行結束的所有文本都將被當成注釋忽略掉。例如,我們可以前面的一個表達式寫成這樣:
(?<= # 斷言要匹配的文本的前綴
<(\w+)> # 查找尖括號括起來的字母或數字(即HTML/XML標簽)
) # 前綴結束
.* # 匹配任意文本
(?= # 斷言要匹配的文本的后綴
<\/\1> # 查找尖括號括起來的內容:前面是一個"/",后面是先前捕獲的標簽
) # 后綴結束
當正則表達式中包含能接受重復的限定符時,通常的行為是(在使整個表達式能得到匹配的前提下)匹配盡可能多的字符。考慮這個表達式:a.*b,它將會匹配最長的以a開始,以b結束的字符串。如果用它來搜索aabab的話,它會匹配整個字符串aabab。這被稱為貪婪匹配。
有時,我們更需要懶惰匹配,也就是匹配盡可能少的字符。前面給出的限定符都可以被轉化為懶惰匹配模式,只要在它后面加上一個問號?。這樣.*?就意味著匹配任意數量的重復,但是在能使整個匹配成功的前提下使用最少的重復?,F在看看懶惰版的例子吧:
a.*?b匹配最短的,以a開始,以b結束的字符串。如果把它應用于aabab的話,它會匹配aab(第一到第三個字符)和ab(第四到第五個字符)。
為什么第一個匹配是aab(第一到第三個字符)而不是ab(第二到第三個字符)?簡單地說,因為正則表達式有另一條規則,比懶惰/貪婪規則的優先級更高:最先開始的匹配擁有最高的優先權——The match that begins earliest wins。
代碼/語法 | 說明 |
---|---|
*? | 重復任意次,但盡可能少重復 |
+? | 重復1次或更多次,但盡可能少重復 |
?? | 重復0次或1次,但盡可能少重復 |
{n,m}? | 重復n到m次,但盡可能少重復 |
{n,}? | 重復n次以上,但盡可能少重復 |
在C#中,你可以使用Regex(String, RegexOptions)構造函數來設置正則表達式的處理選項。如:Regex regex = new Regex("\ba\w{6}\b", RegexOptions.IgnoreCase);
上面介紹了幾個選項如忽略大小寫,處理多行等,這些選項能用來改變處理正則表達式的方式。下面是.Net中常用的正則表達式選項:
名稱 | 說明 |
---|---|
IgnoreCase(忽略大小寫) | 匹配時不區分大小寫。 |
Multiline(多行模式) | 更改^和$的含義,使它們分別在任意一行的行首和行尾匹配,而不僅僅在整個字符串的開頭和結尾匹配。(在此模式下,$的精確含意是:匹配\n之前的位置以及字符串結束前的位置.) |
Singleline(單行模式) | 更改.的含義,使它與每一個字符匹配(包括換行符\n)。 |
IgnorePatternWhitespace(忽略空白) | 忽略表達式中的非轉義空白并啟用由#標記的注釋。 |
RightToLeft(從右向左查找) | 匹配從右向左而不是從左向右進行。 |
ExplicitCapture(顯式捕獲) | 僅捕獲已被顯式命名的組。 |
ECMAScript(JavaScript兼容模式) | 使表達式的行為與它在JavaScript里的行為一致。 |
一個經常被問到的問題是:是不是只能同時使用多行模式和單行模式中的一種?答案是:不是。這兩個選項之間沒有任何關系,除了它們的名字比較相似(以至于讓人感到疑惑)以外。
這里介紹的平衡組語法是由.Net Framework支持的;其它語言/庫不一定支持這種功能,或者支持此功能但需要使用不同的語法。
有時我們需要匹配像( 100 * ( 50 + 15 ) )這樣的可嵌套的層次性結構,這時簡單地使用\(.+\)則只會匹配到最左邊的左括號和最右邊的右括號之間的內容(這里我們討論的是貪婪模式,懶惰模式也有下面的問題)。假如原來的字符串里的左括號和右括號出現的次數不相等,比如( 5 / ( 3 + 2 ) ) ),那我們的匹配結果里兩者的個數也不會相等。有沒有辦法在這樣的字符串里匹配到最長的,配對的括號之間的內容呢?
為了避免(和\(把你的大腦徹底搞糊涂,我們還是用尖括號代替圓括號吧?,F在我們的問題變成了如何把xx <aa <bbb> <bbb> aa> yy這樣的字符串里,最長的配對的尖括號內的內容捕獲出來?
這里需要用到以下的語法構造:
如果你不是一個程序員(或者你自稱程序員但是不知道堆棧是什么東西),你就這樣理解上面的三種語法吧:第一個就是在黑板上寫一個"group",第二個就是從黑板上擦掉一個"group",第三個就是看黑板上寫的還有沒有"group",如果有就繼續匹配yes部分,否則就匹配no部分。
我們需要做的是每碰到了左括號,就在壓入一個"Open",每碰到一個右括號,就彈出一個,到了最后就看看堆棧是否為空--如果不為空那就證明左括號比右括號多,那匹配就應該失敗。正則表達式引擎會進行回溯(放棄最前面或最后面的一些字符),盡量使整個表達式得到匹配。
< #最外層的左括號
[^<>]* #最外層的左括號后面的不是括號的內容
(
(
(?'Open'<) #碰到了左括號,在黑板上寫一個"Open"
[^<>]* #匹配左括號后面的不是括號的內容
)+
(
(?'-Open'>) #碰到了右括號,擦掉一個"Open"
[^<>]* #匹配右括號后面不是括號的內容
)+
)*
(?(Open)(?!)) #在遇到最外層的右括號前面,判斷黑板上還有沒有沒擦掉的"Open";如果還有,則匹配失敗
> #最外層的右括號
平衡組的一個最常見的應用就是匹配HTML,下面這個例子可以匹配嵌套的<div>標簽:<div[^>]*>[^<>]*(((?'Open'<div[^>]*>)[^<>]*)+((?'-Open'</div>)[^<>]*)+)*(?(Open)(?!))</div>.
我已經描述了構造正則表達式的大量元素,還有一些我沒有提到的東西。下面是未提到的元素的列表,包含語法和簡單的說明。你可以在網上找到更詳細的參考資料來學習它們--當你需要用到它們的時候。如果你安裝了MSDN Library,你也可以在里面找到關于.net下正則表達式詳細的文檔。
代碼/語法 | 說明 |
---|---|
\a | 報警字符(打印它的效果是電腦嘀一聲) |
\b | 通常是單詞分界位置,但如果在字符類里使用代表退格 |
\t | 制表符,Tab |
\r | 回車 |
\v | 豎向制表符 |
\f | 換頁符 |
\n | 換行符 |
\e | Escape |
\0nn | ASCII代碼中八進制代碼為nn的字符 |
\xnn | ASCII代碼中十六進制代碼為nn的字符 |
\unnnn | Unicode代碼中十六進制代碼為nnnn的字符 |
\cN | ASCII控制字符。比如\cC代表Ctrl+C |
\A | 字符串開頭(類似^,但不受處理多行選項的影響) |
\Z | 字符串結尾或行尾(不受處理多行選項的影響) |
\z | 字符串結尾(類似$,但不受處理多行選項的影響) |
\G | 當前搜索的開頭 |
\p{name} | Unicode中命名為name的字符類,例如\p{IsGreek} |
(?>exp) | 貪婪子表達式 |
(?<x>-<y>exp) | 平衡組 |
(?im-nsx:exp) | 在子表達式exp中改變處理選項 |
(?im-nsx) | 為表達式后面的部分改變處理選項 |
(?(exp)yes|no) | 把exp當作零寬正向先行斷言,如果在這個位置能匹配,使用yes作為此組的表達式;否則使用no |
(?(exp)yes) | 同上,只是使用空表達式作為no |
(?(name)yes|no) | 如果命名為name的組捕獲到了內容,使用yes作為表達式;否則使用no |
(?(name)yes) | 同上,只是使用空表達式作為no |
JDK1.6官方下載_JDK6官方下載地址:http://www.java.net/download/jdk6/6u10/promoted/b32/binaries/jdk-6u10-rc2-bin-b32-windows-i586-p-12_sep_2008.exe
JDK6 API CHM中文參考下載:
JDK6API中文參考070114.rar : http://chinesedocument.com/upimg/soft/JDK6API中文參考070114.rar
Java SE 6 API 中文版 CHM 下載:http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/publish/1.6.0/chm/JDK_API_1_6_zh_CN.CHM
Java SE 5 API 中文版 CHM 下載:http://download.java.net/jdk/jdk-api-localizations/jdk-api-zh-cn/builds/JDK_API_1_5_zh_CN.CHM
JDK6 API 中文版下載:
一、漢字編碼的種類
??? 漢字編碼中現在主要用到的有三類,包括GBK,GB2312和Big5。
??? 1 、GB2312又稱國標碼, 由國家標準總局發布, 1981 年 5 月 1 日實施,通行于大陸。新加坡等地也使用此編碼。它是一個簡化字的編碼規范,當然也包括其他的符號、字母、日文假名等,共 7445 個圖形字符,其中漢字占 6763 個。我們平時說 6768 個漢字,實際上里邊有 5 個編碼為空白,所以總共有 6763 個漢字。
? ??? GB2312 規定“對任意一個圖形字符都采用兩個字節表示,每個字節均采用七位編碼表示”,習慣上稱第一個字節為“高字節”,第二個字節為“低字節”。 GB2312 中漢字的編碼范圍為,第一字節0xB0-0xF7(對應十進制為176-247),第二個字節0xA0-0xFE(對應十進制為160-254)。
??? GB2312 將代碼表分為 94 個區,對應第一字節( 0xa1-0xfe );每個區 94 個位( 0xa1-0xfe ),對應第二字節,兩個字節的值分別為區號值和位號值加 32 ( 2OH ),因此也稱為區位碼。 01-09 區為符號、數字區, 16-87 區為漢字區( 0xb0-0xf7 ), 10-15 區、 88-94 區是有待進一步標準化的空白區。
?
?????? 2 、 Big5 又稱大五碼,主要為香港與臺灣使用,即是一個繁體字編碼。 每個漢字由兩個字節構成,第一個字節的范圍從 0X81 - 0XFE (即 129-255 ),共 126 種。第二個字節的范圍不連續,分別為 0X40 - 0X7E (即 64-126 ), 0XA1 - 0XFE (即 161-254 ),共 157 種。
?
??? 3 、GBK是GB2312的擴展,是向上兼容的,因此GB2312中的漢字的編碼與GBK中漢字的相同。另外,GBK中還包含繁體字的編碼,它與Big5編碼之間的關系我還沒有弄明白,好像是不一致的。GBK中每個漢字仍然包含兩個字節,第一個字節的范圍是0x81-0xFE(即129-254),第二個字節的范圍是0x40-0xFE(即64-254)。GBK中有碼位23940個,包含漢字21003個。
????????????????????????????????????
?????????????????????????????????? 表1 漢字編碼范圍
名稱 |
第一字節 |
第二字節 |
GB2312 |
0xB0-0xF7(176-247) |
0xA0-0xFE ( 160-254 ) |
GBK |
0x81-0xFE ( 129-254 ) |
0x40-0xFE ( 64-254 ) |
Big5 |
0x81-0xFE ( 129-255 ) |
0x40-0x7E ( 64-126 ) 0xA1 - 0xFE ( 161-254 ) |
?
?
二、對漢字進行hash
??? 為了處理漢字的方便,在查找漢字的時候,我們通常會用到hash的方法,那怎么來確定一個漢字位置呢?這就和每種編碼的排列有關了,這里主要給出一種hash函數的策略。
??? 對于GB2312編碼,設輸入的漢字為GBword,我們可以采用公式(C1-176)*94 + (C2-161)確定GBindex。其中,C1表示第一字節,C2表示第二字節。具體如下:
??? GBindex = ((unsigned char)GBword.at(0)-176)*94 + (unsigned char)GBword.at(1) - 161;
??? 之所以用unsigned char類型,是因為char是一個字節,如果用unsigend int,因為int是4個字節的,所以會造成擴展,導致錯誤。
?????? 對于GBK編碼,設輸入的漢字為GBKword,則可以采用公式?? index=(ch1-0x81)*190+(ch2-0x40)-(ch2/128) ,其中ch1是第一字節,ch2是第二字節。
??? 具體的,
??? GBKindex = ((unsigned char)GBKword[0]-129)*190 +
??????? ?????? ((unsigned char)GBKword[1]-64) - (unsigned char)GBKword[1]/128;
?
三、怎樣判斷一個漢字的是什么編碼
直接根據漢字的編碼范圍判斷,對于GB2312和GBK可用下面兩個程序實現。
1 、判斷是否是GB2312
bool isGBCode(const string& strIn)
{
??? unsigned char ch1;
??? unsigned char ch2;
???
??? if (strIn.size() >= 2)
??? {
??????? ch1 = (unsigned char)strIn.at(0);
??????? ch2 = (unsigned char)strIn.at(1);
??????? if (ch1>=176 && ch1<=247 && ch2>=160 && ch2<=254)
??????????? return true;
??????? else return false;
??? }
??? else return false;
}
2 、判斷是否是GBK編碼
bool isGBKCode(const string& strIn)
{
??? unsigned char ch1;
??? unsigned char ch2;
???
??? if (strIn.size() >= 2)
??? {
??????? ch1 = (unsigned char)strIn.at(0);
??????? ch2 = (unsigned char)strIn.at(1);
??????? if (ch1>=129 && ch1<=254 && ch2>=64 && ch2<=254)
??????????? return true;
??????? else return false;
??? }
??? else return false;
}
?
3 、對于Big5
??? 它的范圍為:高字節從0xA0到0xFE,低字節從0x40到0x7E,和0xA1到0xFE兩部分。判斷一個漢字是否是BIG5編碼,可以如上對字符的編碼范圍判斷即可。如何定位呢?那么也想象所有編碼排列為一個二維坐標,縱坐標是高字節,橫坐標是低字節。這樣一行上的漢字個數:(0x7E-0x40+1)+(0xFE-0xA1+1)=157。那么定位算法分兩塊,為: ?
??? if 0x40<=ch2<=0x7E: #is big5 char
??? index=((ch1-0xA1)*157+(ch2-0x40))*2
??? elif 0xA1<=ch2<=0xFE: #is big5 char
??? index=((ch1-0xA1)*157+(ch2-0xA1+63))*2
?
對于第二塊,計算偏移量時因為有兩塊數值,所以在計算后面一段值時,不要忘了前面還有一段值。0x7E-0x40+1=63。
?
四、如果判斷一個字符是西文字符還是中文字符
??? 大家知道西文字符主要是指 ASCII 碼,它用一個字節表示。且這個字符轉換成數字之后,該數字是大于0的,而漢字是兩個字節的,第一個字節的轉化為數字之后應該是小于0的,因此可以根據每個字節轉化為數字之后是否小于0,判斷它是否是漢字。
??? 例如,設輸入字為strin,則,
???? If (strin.at(0) < 0)
?????? cout << ” 是漢字” << endl;
???? else cout << ” 不是漢字” << endl;
五、編碼表下載
?? GBK編碼表,下載
?? GB2312編碼表,下載
下面都是我收集的一些比較常用的正則表達式,因為平常可能在表單驗證的時候,用到的比較多。特發出來,讓各位朋友共同使用。呵呵。
匹配中文字符的正則表達式: [u4e00-u9fa5]
評注:匹配中文還真是個頭疼的事,有了這個表達式就好辦了
匹配雙字節字符(包括漢字在內):[^x00-xff]
評注:可以用來計算字符串的長度(一個雙字節字符長度計2,ASCII字符計1)
匹配空白行的正則表達式:ns*r
評注:可以用來刪除空白行
匹配HTML標記的正則表達式:< (S*?)[^>]*>.*?|< .*? />
評注:網上流傳的版本太糟糕,上面這個也僅僅能匹配部分,對于復雜的嵌套標記依舊無能為力
匹配首尾空白字符的正則表達式:^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”。
匹配中文字符的正則表達式: [u4e00-u9fa5]
匹配雙字節字符(包括漢字在內):[^x00-xff]
匹配空行的正則表達式:n[s| ]*r
匹配HTML標記的正則表達式:/< (.*)>.*|< (.*) />/
匹配首尾空格的正則表達式:(^s*)|(s*$)
匹配Email地址的正則表達式:w+([-+.]w+)*@w+([-.]w+)*.w+([-.]w+)*
匹配網址URL的正則表達式:http://([w-]+.)+[w-]+(/[w- ./?%&=]*)?
(1)應用:計算字符串的長度(一個雙字節字符長度計2,ASCII字符計1)
String.prototype.len=function(){return this.replace([^x00-xff]/g,”aa”).length;}
(2)應用:javascript中沒有像vbscript那樣的trim函數,我們就可以利用這個表達式來實現
String.prototype.trim = function()
{
return this.replace(/(^s*)|(s*$)/g, “”);
}
(3)應用:利用正則表達式分解和轉換IP地址
function IP2V(ip) //IP地址轉換成對應數值
{
re=/(d+).(d+).(d+).(d+)/g //匹配IP地址的正則表達式
if(re.test(ip))
{
return RegExp.$1*Math.pow(255,3))+RegExp.$2*Math.pow(255,2))+RegExp.$3*255+RegExp.$4*1
}
else
{
throw new Error(”Not a valid IP address!”)
}
}
(4)應用:從URL地址中提取文件名的javascript程序
s=”http://www.9499.net/page1.htm”;
s=s.replace(/(.*/){0,}([^.]+).*/ig,”$2″) ; //Page1.htm
(5)應用:利用正則表達式限制網頁表單里的文本框輸入內容
用正則表達式限制只能輸入中文:onkeyup=”value=”/blog/value.replace(/["^u4E00-u9FA5]/g,”) ” onbeforepaste=”clipboardData.setData(’text’,clipboardData.getData(’text’).replace(/[^u4E00-u9FA5]/g,”))”
用正則表達式限制只能輸入全角字符: onkeyup=”value=”/blog/value.replace(/["^uFF00-uFFFF]/g,”) ” onbeforepaste=”clipboardData.setData(’text’,clipboardData.getData(’text’).replace(/[^uFF00-uFFFF]/g,”))”
用正則表達式限制只能輸入數字:onkeyup=”value=”/blog/value.replace(/["^d]/g,”) “onbeforepaste= “clipboardData.setData(’text’,clipboardData.getData(’text’).replace(/[^d]/g,”))”
用正則表達式限制只能輸入數字和英文:onkeyup=”value=”/blog/value.replace(/[W]/g,””) “onbeforepaste=”clipboardData.setData(’text’,clipboardData.getData(’text’).replace(/[^d]/g,”
一、漢字編碼的種類
??? 漢字編碼中現在主要用到的有三類,包括GBK,GB2312和Big5。
??? 1 、GB2312又稱國標碼, 由國家標準總局發布, 1981 年 5 月 1 日實施,通行于大陸。新加坡等地也使用此編碼。它是一個簡化字的編碼規范,當然也包括其他的符號、字母、日文假名等,共 7445 個圖形字符,其中漢字占 6763 個。我們平時說 6768 個漢字,實際上里邊有 5 個編碼為空白,所以總共有 6763 個漢字。
? ??? GB2312 規定“對任意一個圖形字符都采用兩個字節表示,每個字節均采用七位編碼表示”,習慣上稱第一個字節為“高字節”,第二個字節為“低字節”。 GB2312 中漢字的編碼范圍為,第一字節0xB0-0xF7(對應十進制為176-247),第二個字節0xA0-0xFE(對應十進制為160-254)。
??? GB2312 將代碼表分為 94 個區,對應第一字節( 0xa1-0xfe );每個區 94 個位( 0xa1-0xfe ),對應第二字節,兩個字節的值分別為區號值和位號值加 32 ( 2OH ),因此也稱為區位碼。 01-09 區為符號、數字區, 16-87 區為漢字區( 0xb0-0xf7 ), 10-15 區、 88-94 區是有待進一步標準化的空白區。
?
?????? 2 、 Big5 又稱大五碼,主要為香港與臺灣使用,即是一個繁體字編碼。 每個漢字由兩個字節構成,第一個字節的范圍從 0X81 - 0XFE (即 129-255 ),共 126 種。第二個字節的范圍不連續,分別為 0X40 - 0X7E (即 64-126 ), 0XA1 - 0XFE (即 161-254 ),共 157 種。
?
??? 3 、GBK是GB2312的擴展,是向上兼容的,因此GB2312中的漢字的編碼與GBK中漢字的相同。另外,GBK中還包含繁體字的編碼,它與Big5編碼之間的關系我還沒有弄明白,好像是不一致的。GBK中每個漢字仍然包含兩個字節,第一個字節的范圍是0x81-0xFE(即129-254),第二個字節的范圍是0x40-0xFE(即64-254)。GBK中有碼位23940個,包含漢字21003個。
????????????????????????????????????
?????????????????????????????????? 表1 漢字編碼范圍
名稱 |
第一字節 |
第二字節 |
GB2312 |
0xB0-0xF7(176-247) |
0xA0-0xFE ( 160-254 ) |
GBK |
0x81-0xFE ( 129-254 ) |
0x40-0xFE ( 64-254 ) |
Big5 |
0x81-0xFE ( 129-255 ) |
0x40-0x7E ( 64-126 ) 0xA1 - 0xFE ( 161-254 ) |
?
?
二、對漢字進行hash
??? 為了處理漢字的方便,在查找漢字的時候,我們通常會用到hash的方法,那怎么來確定一個漢字位置呢?這就和每種編碼的排列有關了,這里主要給出一種hash函數的策略。
??? 對于GB2312編碼,設輸入的漢字為GBword,我們可以采用公式(C1-176)*94 + (C2-161)確定GBindex。其中,C1表示第一字節,C2表示第二字節。具體如下:
??? GBindex = ((unsigned char)GBword.at(0)-176)*94 + (unsigned char)GBword.at(1) - 161;
??? 之所以用unsigned char類型,是因為char是一個字節,如果用unsigend int,因為int是4個字節的,所以會造成擴展,導致錯誤。
?????? 對于GBK編碼,設輸入的漢字為GBKword,則可以采用公式?? index=(ch1-0x81)*190+(ch2-0x40)-(ch2/128) ,其中ch1是第一字節,ch2是第二字節。
??? 具體的,
??? GBKindex = ((unsigned char)GBKword[0]-129)*190 +
??????? ?????? ((unsigned char)GBKword[1]-64) - (unsigned char)GBKword[1]/128;
?
三、怎樣判斷一個漢字的是什么編碼
直接根據漢字的編碼范圍判斷,對于GB2312和GBK可用下面兩個程序實現。
1 、判斷是否是GB2312
bool isGBCode(const string& strIn)
{
??? unsigned char ch1;
??? unsigned char ch2;
???
??? if (strIn.size() >= 2)
??? {
??????? ch1 = (unsigned char)strIn.at(0);
??????? ch2 = (unsigned char)strIn.at(1);
??????? if (ch1>=176 && ch1<=247 && ch2>=160 && ch2<=254)
??????????? return true;
??????? else return false;
??? }
??? else return false;
}
2 、判斷是否是GBK編碼
bool isGBKCode(const string& strIn)
{
??? unsigned char ch1;
??? unsigned char ch2;
???
??? if (strIn.size() >= 2)
??? {
??????? ch1 = (unsigned char)strIn.at(0);
??????? ch2 = (unsigned char)strIn.at(1);
??????? if (ch1>=129 && ch1<=254 && ch2>=64 && ch2<=254)
??????????? return true;
??????? else return false;
??? }
??? else return false;
}
?
3 、對于Big5
??? 它的范圍為:高字節從0xA0到0xFE,低字節從0x40到0x7E,和0xA1到0xFE兩部分。判斷一個漢字是否是BIG5編碼,可以如上對字符的編碼范圍判斷即可。如何定位呢?那么也想象所有編碼排列為一個二維坐標,縱坐標是高字節,橫坐標是低字節。這樣一行上的漢字個數:(0x7E-0x40+1)+(0xFE-0xA1+1)=157。那么定位算法分兩塊,為: ?
??? if 0x40<=ch2<=0x7E: #is big5 char
??? index=((ch1-0xA1)*157+(ch2-0x40))*2
??? elif 0xA1<=ch2<=0xFE: #is big5 char
??? index=((ch1-0xA1)*157+(ch2-0xA1+63))*2
?
對于第二塊,計算偏移量時因為有兩塊數值,所以在計算后面一段值時,不要忘了前面還有一段值。0x7E-0x40+1=63。
?
四、如果判斷一個字符是西文字符還是中文字符
??? 大家知道西文字符主要是指 ASCII 碼,它用一個字節表示。且這個字符轉換成數字之后,該數字是大于0的,而漢字是兩個字節的,第一個字節的轉化為數字之后應該是小于0的,因此可以根據每個字節轉化為數字之后是否小于0,判斷它是否是漢字。
??? 例如,設輸入字為strin,則,
???? If (strin.at(0) < 0)
?????? cout << ” 是漢字” << endl;
???? else cout << ” 不是漢字” << endl;
漢字在 Unicode 里面有單獨的幾塊區域,是中日韓(朝鮮)共享的。
以下兩段
U+4e00 ~ U+9FB0 原來 GB2312 和 GBK 中的漢字
U+3400 ~ U+4DB6 包括 GB18030.2000 中那些增加的漢字
五、編碼表下載
?? GBK編碼表,下載
?? GB2312編碼表,下載
這一段出現了亂碼,那么不妨用窮舉法猜測一下它的實際編碼格式。Unicode字符編碼規范
Unicode是一種字符編碼規范 。
先從ASCII說起。ASCII是用來表示英文字符的一種編碼規范,每個ASCII字符占用1個字節(8bits)
因此,ASCII編碼可以表示的最大字符數是256,其實英文字符并沒有那么多,一般只用前128個(最高位為0),其中包括了控制字符、數字、大小寫字母和其他一些符號
。
而最高位為1的另128個字符被成為“擴展ASCII”,一般用來存放英文的制表符、部分音標字符等等的一些其他符號
這種字符編碼規范顯然用來處理英文沒有什么問題
。(實際上也可以用來處理法文、德文等一些其他的西歐字符,但是不能和英文通用),但是面對中文、阿拉伯文之類復雜的文字,255個字符顯然不夠用
于是,各個國家紛紛制定了自己的文字編碼規范,其中中文的文字編碼規范叫做“GB2312-80”,它是和ASCII兼容的一種編碼規范,其實就是利用擴展ASCII沒有真正標準化這一點,把一個中文字符用兩個擴展ASCII字符來表示。
但 是這個方法有問題,最大的問題就是,中文文字沒有真正屬于自己的編碼,因為擴展ASCII碼雖然沒有真正的標準化,但是PC里的ASCII碼還是有一個事 實標準的(存放著英文制表符),所以很多軟件利用這些符號來畫表格。這樣的軟件用到中文系統中,這些表格符就會被誤認作中文字,破壞版面。而且,統計中英 文混合字符串中的字數,也是比較復雜的,我們必須判斷一個ASCII碼是否擴展,以及它的下一個ASCII是否擴展,然后才“猜”那可能是一個中文字
。
總之當時處理中文是很痛苦的。而更痛苦的是GB2312是國家標準,臺灣當時有一個Big5編碼標準,很多編碼和GB是相同的,所以……,嘿嘿。
這 時候,我們就知道,要真正解決中文問題,不能從擴展ASCII的角度入手,也不能僅靠中國一家來解決。而必須有一個全新的編碼系統,這個系統要可以將中 文、英文、法文、德文……等等所有的文字統一起來考慮,為每個文字都分配一個單獨的編碼,這樣才不會有上面那種現象出現。
于是,Unicode誕生了。
Unicode有兩套標準,一套叫UCS-2(Unicode-16),用2個字節為字符編碼,另一套叫UCS-4(Unicode-32),用4個字節為字符編碼。
以目前常用的UCS-2為例,它可以表示的字符數為2^16=65535,基本上可以容納所有的歐美字符和絕大部分的亞洲字符
。
UTF-8的問題后面會提到 。
在Unicode里,所有的字符被一視同仁。漢字不再使用“兩個擴展ASCII”,而是使用“1個Unicode”,注意,現在的漢字是“一個字符”了,于是,拆字、統計字數這些問題也就自然而然的解決了
。
但是,這個世界不是理想的,不可能在一夜之間所有的系統都使用Unicode來處理字符,所以Unicode在誕生之日,就必須考慮一個嚴峻的問題:和ASCII字符集之間的不兼容問題。
我們知道,ASCII字符是單個字節的,比如“A”的ASCII是65。而Unicode是雙字節的,比如“A”的Unicode是0065,這就造成了一個非常大的問題:以前處理ASCII的那套機制不能被用來處理Unicode了
。
另一個更加嚴重的問題是,C語言使用’\0′作為字符串結尾,而Unicode里恰恰有很多字符都有一個字節為0,這樣一來,C語言的字符串函數將無法正常處理Unicode,除非把世界上所有用C寫的程序以及他們所用的函數庫全部換掉
。
于是,比Unicode更偉大的東東誕生了,之所以說它更偉大是因為它讓Unicode不再存在于紙上,而是真實的存在于我們大家的電腦中。那就是:UTF
。
UTF= UCS Transformation Format UCS轉換格式
它是將Unicode編碼規則和計算機的實際編碼對應起來的一個規則?,F在流行的UTF有2種:UTF-8和UTF-16
。
其中UTF-16和上面提到的Unicode本身的編碼規范是一致的,這里不多說了。而UTF-8不同,它定義了一種“區間規則”,這種規則可以和ASCII編碼保持最大程度的兼容
。
UTF-8有點類似于Haffman編碼,它將Unicode編碼為00000000-0000007F的字符,用單個字節來表示;
00000080-000007FF的字符用兩個字節表示
00000800-0000FFFF的字符用3字節表示
因為目前為止Unicode-16規范沒有指定FFFF以上的字符,所以UTF-8最多是使用3個字節來表示一個字符。但理論上來說,UTF-8最多需要用6字節表示一個字符。
在UTF-8里,英文字符仍然跟ASCII編碼一樣,因此原先的函數庫可以繼續使用。而中文的編碼范圍是在0080-07FF之間,因此是2個字節表示(但這兩個字節和GB編碼的兩個字節是不同的),用專門的Unicode處理類可以對UTF編碼進行處理。
下面說說中文的問題。
由于歷史的原因,在Unicode之前,一共存在過3套中文編碼標準。
GB2312-80,是中國大陸使用的國家標準,其中一共編碼了6763個常用簡體漢字。Big5,是臺灣使用的編碼標準,編碼了臺灣使用的繁體漢字,大概有8千多個。HKSCS,是中國香港使用的編碼標準,字體也是繁體,但跟Big5有所不同。
這3套編碼標準都采用了兩個擴展ASCII的方法,因此,幾套編碼互不兼容,而且編碼區間也各有不同
因為其不兼容性,在同一個系統中同時顯示GB和Big5基本上是不可能的。當時的南極星、RichWin等等軟件,在自動識別中文編碼、自動顯示正確編碼方面都做了很多努力
。
他們用了怎樣的技術我就不得而知了,我知道好像南極星曾經以同屏顯示繁簡中文為賣點。
后來,由于各方面的原因,國際上又制定了針對中文的統一字符集GBK和GB18030,其中GBK已經在Windows、Linux等多種操作系統中被實現。
GBK兼容GB2312,并增加了大量不常用漢字,還加入了幾乎所有的Big5中的繁體漢字。但是GBK中的繁體漢字和Big5中的幾乎不兼容。
GB18030相當于是GBK的超集,比GBK包含的字符更多。據我所知目前還沒有操作系統直接支持GB18030。
談談Unicode編碼,簡要解釋UCS、UTF、BMP、BOM等名詞
這是一篇程序員寫給程序員的趣味讀物。所謂趣味是指可以比較輕松地了解一些原來不清楚的概念,增進知識,類似于打RPG游戲的升級。整理這篇文章的動機是兩個問題:
問題一:
使用Windows記事本的“另存為”,可以在GBK、Unicode、Unicode big
endian和UTF-8這幾種編碼方式間相互轉換。同樣是txt文件,Windows是怎樣識別編碼方式的呢?
我很早前就發現Unicode、Unicode big
endian和UTF-8編碼的txt文件的開頭會多出幾個字節,分別是FF、FE(Unicode),FE、FF(Unicode big
endian),EF、BB、BF(UTF-8)。但這些標記是基于什么標準呢?
問題二:
最 近在網上看到一個ConvertUTF.c,實現了UTF-32、UTF-16和UTF-8這三種編碼方式的相互轉換。對于Unicode(UCS2)、 GBK、UTF-8這些編碼方式,我原來就了解。但這個程序讓我有些糊涂,想不起來UTF-16和UCS2有什么關系。
查了查相關資料,總算將這些問題弄清楚了,順帶也了解了一些Unicode的細節。寫成一篇文章,送給有過類似疑問的朋友。本文在寫作時盡量做到通俗易懂,但要求讀者知道什么是字節,什么是十六進制。
0、big endian和little endian
big endian和little
endian是CPU處理多字節數的不同方式。例如“漢”字的Unicode編碼是6C49。那么寫到文件里時,究竟是將6C寫在前面,還是將49寫在前面?如果將6C寫在前面,就是big
endian。還是將49寫在前面,就是little endian。
“endian”這個詞出自《格列佛游記》。小人國的內戰就源于吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開,由此曾發生過六次叛亂,其中一個皇帝送了命,另一個丟了王位。
我們一般將endian翻譯成“字節序”,將big endian和little
endian稱作“大尾”和“小尾”。
1、字符編碼、內碼,順帶介紹漢字編碼
字符必須編碼后才能被計算機處理。計算機使用的缺省編碼方式就是計算機的內碼。早期的計算機使用7位的ASCII編碼,為了處理漢字,程序員設計了用于簡體中文的GB2312和用于繁體中文的big5。
GB2312(1980年)一共收錄了7445個字符,包括6763個漢字和682個其它符號。漢字區的內碼范圍高字節從B0-F7,低字節從A1-FE,占用的碼位是72*94=6768。其中有5個空位是D7FA-D7FE。
GB2312 支持的漢字太少。1995年的漢字擴展規范GBK1.0收錄了21886個符號,它分為漢字區和圖形符號區。漢字區包括21003個字符。2000年的 GB18030是取代GBK1.0的正式國家標準。該標準收錄了27484個漢字,同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字?,F在的PC平 臺必須支持GB18030,對嵌入式產品暫不作要求。所以手機、MP3一般只支持GB2312。
從ASCII、GB2312、GBK到 GB18030,這些編碼方法是向下兼容的,即同一個字符在這些方案中總是有相同的編碼,后面的標準支持更多的字符。在這些編碼中,英文和中文可以統一地 處理。區分中文編碼的方法是高字節的最高位不為0。按照程序員的稱呼,GB2312、GBK到GB18030都屬于雙字節字符集
(DBCS)。
有的中文Windows的缺省內碼還是GBK,可以通過GB18030升級包升級到GB18030。不過GB18030相對GBK增加的字符,普通人是很難用到的,通常我們還是用GBK指代中文Windows內碼。
這里還有一些細節:
GB2312的原文還是區位碼,從區位碼到內碼,需要在高字節和低字節上分別加上A0。
在DBCS中,GB內碼的存儲格式始終是big endian,即高位在前。
GB2312 的兩個字節的最高位都是1。但符合這個條件的碼位只有128*128=16384個。所以GBK和GB18030的低字節最高位都可能不是1。不過這不影 響DBCS字符流的解析:在讀取DBCS字符流時,只要遇到高位為1的字節,就可以將下兩個字節作為一個雙字節編碼,而不用管低字節的高位是什么。
2、Unicode、UCS和UTF
前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下兼容的。而Unicode只與ASCII兼容(更準確地說,是與ISO-8859-1兼容),與GB碼不兼容。例如“漢”字的Unicode編碼是6C49,而GB碼是BABA。
Unicode也是一種字符編碼方法,不過它是由國際組織設計,可以容納全世界所有語言文字的編碼方案。Unicode的學名是”Universal
Multiple-Octet Coded Character Set”,簡稱為UCS。UCS可以看作是”Unicode
Character Set”的縮寫。
根據維基百科全書(http://zh.wikipedia.org/wiki/)的記載:歷史上存在兩個試圖獨立設計Unicode的組織,即國際標準化組織(ISO)和一個軟件制造商的協會(unicode.org)。ISO開發了ISO
10646項目,Unicode協會開發了Unicode項目。
在1991年前后,雙方都認識到世界不需要兩個不兼容的字符集。于是它們開始合并雙方的工作成果,并為創立一個單一編碼表而協同工作。從Unicode2.0開始,Unicode項目采用了與ISO
10646-1相同的字庫和字碼。
目前兩個項目仍都存在,并獨立地公布各自的標準。Unicode協會現在的最新版本是2005年的Unicode
4.1.0。ISO的最新標準是10646-3:2003。
UCS規定了怎么用多個字節表示各種文字。怎樣傳輸這些編碼,是由UTF(UCS
Transformation Format)規范規定的,常見的UTF規范包括UTF-8、UTF-7、UTF-16。
IETF的RFC2781和RFC3629以RFC的一貫風格,清晰、明快又不失嚴謹地描述了UTF-16和UTF-8的編碼方法。我總是記不得IETF是Internet
Engineering Task
Force的縮寫。但IETF負責維護的RFC是Internet上一切規范的基礎。
3、UCS-2、UCS-4、BMP
UCS有兩種格式:UCS-2和UCS-4。顧名思義,UCS-2就是用兩個字節編碼,UCS-4就是用4個字節(實際上只用了31位,最高位必須為0)編碼。下面讓我們做一些簡單的數學游戲:
UCS-2有2^16=65536個碼位,UCS-4有2^31=2147483648個碼位。
UCS-4根據最高位為0的最高字節分成2^7=128個group。每個group再根據次高字節分為256個plane。每個plane根據第3個字節分為256行
(rows),每行包含256個cells。當然同一行的cells只是最后一個字節不同,其余都相同。
group 0的plane 0被稱作Basic Multilingual Plane,
即BMP?;蛘哒fUCS-4中,高兩個字節為0的碼位被稱作BMP。
將UCS-4的BMP去掉前面的兩個零字節就得到了UCS-2。在UCS-2的兩個字節前加上兩個零字節,就得到了UCS-4的BMP。而目前的UCS-4規范中還沒有任何字符被分配在BMP之外。
4、UTF編碼
UTF-8就是以8位為單元對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下:
UCS-2編碼(16進制) UTF-8 字節流(二進制)
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx
例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間,所以肯定要用3字節模板了:1110xxxx
10xxxxxx 10xxxxxx。將6C49寫成二進制是:0110 110001 001001,
用這個比特流依次代替模板中的x,得到:11100110 10110001 10001001,即E6 B1 89。
讀者可以用記事本測試一下我們的編碼是否正確。
UTF -16以16位為單元對UCS進行編碼。對于小于0×10000的UCS碼,UTF-16編碼就等于UCS碼對應的16位無符號整數。對于不小于 0×10000的UCS碼,定義了一個算法。不過由于實際使用的UCS2,或者UCS4的BMP必然小于0×10000,所以就目前而言,可以認為UTF -16和UCS-2基本相同。但UCS-2只是一個編碼方案,UTF-16卻要用于實際的傳輸,所以就不得不考慮字節序的問題。
5、UTF的字節序和BOM
UTF -8以字節為編碼單元,沒有字節序的問題。UTF-16以兩個字節為編碼單元,在解釋一個UTF-16文本前,首先要弄清楚每個編碼單元的字節序。例如收 到一個“奎”的Unicode編碼是594E,“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節流“594E”,那么這是“奎”還是 “乙”?
Unicode規范中推薦的標記字節順序的方法是BOM。BOM不是“Bill Of
Material”的BOM表,而是Byte Order Mark。BOM是一個有點小聰明的想法:
在UCS編碼中有一個叫做”ZERO WIDTH NO-BREAK
SPACE”的字符,它的編碼是FEFF。而FFFE在UCS中是不存在的字符,所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前,先傳輸字符”ZERO
WIDTH NO-BREAK SPACE”。
這樣如果接收者收到FEFF,就表明這個字節流是Big-Endian的;如果收到FFFE,就表明這個字節流是Little-Endian的。因此字符”ZERO
WIDTH NO-BREAK SPACE”又被稱作BOM。
UTF-8不需要BOM來表明字節順序,但可以用BOM來表明編碼方式。字符”ZERO
WIDTH NO-BREAK SPACE”的UTF-8編碼是EF BB
BF(讀者可以用我們前面介紹的編碼方法驗證一下)。所以如果接收者收到以EF BB
BF開頭的字節流,就知道這是UTF-8編碼了。
Windows就是使用BOM來標記文本文件的編碼方式的。
6、進一步的參考資料
本文主要參考的資料是 “Short overview of ISO-IEC 10646 and Unicode”
(http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。
我還找了兩篇看上去不錯的資料,不過因為我開始的疑問都找到了答案,所以就沒有看:
“Understanding Unicode A general introduction to the Unicode Standard”
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
“Character set encoding basics Understanding character set encodings
and legacy encodings”
(http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)
附錄1 再說說區位碼、GB2312、內碼和代碼頁
有的朋友對文章中這句話還有疑問: “GB2312的原文還是區位碼,從區位碼到內碼,需要在高字節和低字節上分別加上A0?!?br />我再詳細解釋一下:
“GB2312 的原文”是指國家1980年的一個標準《中華人民共和國國家標準 信息交換用漢字編碼字符集 基本集 GB 2312-80》。這個標準用兩個數來編碼漢字和中文符號。第一個數稱為“區”,第二個數稱為“位”。所以也稱為區位碼。1-9區是中文符號,16-55 區是一級漢字,56-87區是二級漢字?,F在Windows也還有區位輸入法,例如輸入1601得到“啊”。
內碼是指操作系統內部的字符 編碼。早期操作系統的內碼是與語言相關的.現在的Windows在內部統一使用Unicode,然后用代碼頁適應各種語言,“內碼”的概念就比較模糊了。 微軟一般將缺省代碼頁指定的編碼說成是內碼,在特殊的場合也會說自己的內碼是Unicode,例如在 GB18030問題的處理上。
所謂代碼頁(code page)就是針對一種語言文字的字符編碼。例如GBK的code page是CP936,BIG5的code page是CP950,GB2312的code page是CP20936。
Windows中有缺省代碼頁的概念,即缺省用什么編碼來解釋字符。例如Windows的記事本打開了一個文本文件,里面的內容是字節流:BA、BA、D7、D6。Windows應該去怎么解釋它呢?
是 按照Unicode編碼解釋、還是按照GBK解釋、還是按照BIG5解釋,還是按照ISO8859-1去解釋?如果按GBK去解釋,就會得到“漢字”兩個 字。按照其它編碼解釋,可能找不到對應的字符,也可能找到錯誤的字符。所謂“錯誤”是指與文本作者的本意不符,這時就產生了亂碼。
答案是Windows按照當前的缺省代碼頁去解釋文本文件里的字節流。缺省代碼頁可以通過控制面板的區域選項設置。記事本的另存為中有一項ANSI,其實就是按照缺省代碼頁的編碼方法保存。
Windows的內碼是Unicode,它在技術上可以同時支持多個代碼頁。只要文件能說明自己使用什么編碼,用戶又安裝了對應的代碼頁,Windows就能正確顯示,例如在HTML文件中就可以指定charset。
有 的HTML文件作者,特別是英文作者,認為世界上所有人都使用英文,在文件中不指定charset。如果他使用了0×80-0xff之間的字符,中文 Windows又按照缺省的GBK去解釋,就會出現亂碼。這時只要在這個html文件中加上指定charset的語句,例如:如果原作者使用的代碼頁和 ISO8859-1兼容,就不會出現亂碼了。
再說區位碼,啊的區位碼是1601,寫成16進制是0×10,0×01。這和計算機廣泛使用 的ASCII編碼沖突。為了兼容00-7f的 ASCII編碼,我們在區位碼的高、低字節上分別加上A0。這樣“啊”的編碼就成為B0A1。我們將加過兩個A0的編碼也稱為GB2312編碼,雖然 GB2312的原文根本沒提到這一點。
本文來源于 冰山上的播客 http://xinsync.xju.edu.cn , 原文地址:http://xinsync.xju.edu.cn/index.php/archives/483
mysql 創建 數據庫時指定編碼很重要,很多開發者都使用了默認編碼,但是我使用的經驗來看,制定數據庫的編碼可以很大程度上避免倒入導出帶來的亂碼問題。
我們遵循的標準是,數據庫,表,字段和頁面或文本的編碼要統一起來
很多mysql數據庫工具(除了phpmyadmin,我偶爾用,功能強速度慢)都不支持創建時指定數據庫編碼,當然可以改my.ini來解決這個問題,但是需要重新啟動mysql,
不過用下面的語句會更有效
GBK: create database test2 DEFAULT CHARACTER SET gbk COLLATE gbk_chinese_ci;
UTF8: CREATE DATABASE `test2` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci
6.5.4 ? ALTER ? TABLE ? 句法???最近發現用htmlparser解析一些網頁時,繁體中文會變成亂碼.分析了下原因,發現在用stringbean的時候htmlparser會自己根據meta來決定用哪種內碼來解碼,而有的網站在meta中是用gb2312來做charset,實際應用的時候又用到了gbk.gb2312是不能表示繁體的,所以就出現了亂碼.解決的辦法很簡單,gbk是兼容gb2312的,所以在htmlparser的page.java的getcharser()那里加一句判斷,如果ret是gb2312就設置為gbk,這樣問題就解決了.?
修改的page.java的代碼如下(/lexer/page.java)
??? public String getCharset (String content)
??? {
??????? final String CHARSET_STRING = "charset";
??????? int index;
??????? String ret;
??????? if (null == mSource)
??????????? ret = DEFAULT_CHARSET;
??????? else
??????????? // use existing (possibly supplied) character set:
??????????? // bug #1322686 when illegal charset specified
??????????? ret = mSource.getEncoding ();
??????? if (null != content)
??????? {
??????????? index = content.indexOf (CHARSET_STRING);
??????????? if (index != -1)
??????????? {
??????????????? content = content.substring (index +
??????????????????? CHARSET_STRING.length ()).trim ();
??????????????? if (content.startsWith ("="))
??????????????? {
??????????????????? content = content.substring (1).trim ();
??????????????????? index = content.indexOf (";");
??????????????????? if (index != -1)
??????????????????????? content = content.substring (0, index);
??????????????????? //remove any double quotes from around charset string
??????????????????? if (content.startsWith ("\"") && content.endsWith ("\"")
??????????????????????? && (1 < content.length ()))
??????????????????????? content = content.substring (1, content.length () - 1);
??????????????????? //remove any single quote from around charset string
??????????????????? if (content.startsWith ("'") && content.endsWith ("'")
??????????????????????? && (1 < content.length ()))
??????????????????????? content = content.substring (1, content.length () - 1);
??????????????????? ret = findCharset (content, ret);
??????????????????? // Charset names are not case-sensitive;
??????????????????? // that is, case is always ignored when comparing
??????????????????? // charset names.
//??????????????????? if (!ret.equalsIgnoreCase (content))
//??????????????????? {
//??????????????????????? System.out.println (
//??????????????????????????? "detected charset \""
//??????????????????????????? + content
//??????????????????????????? + "\", using \""
//??????????????????????????? + ret
//??????????????????????????? + "\"");
//??????????????????? }
??????????????? }
??????????? }
??????? }
??????? if(ret.equalsIgnoreCase("gb2312"))ret="GBK"; //to avoid decode problem
??????????????????????????????????????????????????????????????????????????????????????? ? ?//edited by linyunfan
??????? return (ret);
??? }
?
在最后加入了這句
??????? if(ret.equalsIgnoreCase("gb2312"))ret="GBK";
發現了一個很不錯的電影網站,http://www.mdianying.com?收藏一下public class Escape {
??????? private final static String[] hex = { "00", "01", "02", "03", "04", "05",
??????? "06", "07", "08", "09", "0A", "0B", "0C", "0D", "0E", "0F", "10",
??????? "11", "12", "13", "14", "15", "16", "17", "18", "19", "1A", "1B",
??????? "1C", "1D", "1E", "1F", "20", "21", "22", "23", "24", "25", "26",
??????? "27", "28", "29", "2A", "2B", "2C", "2D", "2E", "2F", "30", "31",
??????? "32", "33", "34", "35", "36", "37", "38", "39", "3A", "3B", "3C",
??????? "3D", "3E", "3F", "40", "41", "42", "43", "44", "45", "46", "47",
??????? "48", "49", "4A", "4B", "4C", "4D", "4E", "4F", "50", "51", "52",
??????? "53", "54", "55", "56", "57", "58", "59", "5A", "5B", "5C", "5D",
??????? "5E", "5F", "60", "61", "62", "63", "64", "65", "66", "67", "68",
??????? "69", "6A", "6B", "6C", "6D", "6E", "6F", "70", "71", "72", "73",
??????? "74", "75", "76", "77", "78", "79", "7A", "7B", "7C", "7D", "7E",
??????? "7F", "80", "81", "82", "83", "84", "85", "86", "87", "88", "89",
??????? "8A", "8B", "8C", "8D", "8E", "8F", "90", "91", "92", "93", "94",
??????? "95", "96", "97", "98", "99", "9A", "9B", "9C", "9D", "9E", "9F",
??????? "A0", "A1", "A2", "A3", "A4", "A5", "A6", "A7", "A8", "A9", "AA",
??????? "AB", "AC", "AD", "AE", "AF", "B0", "B1", "B2", "B3", "B4", "B5",
??????? "B6", "B7", "B8", "B9", "BA", "BB", "BC", "BD", "BE", "BF", "C0",
??????? "C1", "C2", "C3", "C4", "C5", "C6", "C7", "C8", "C9", "CA", "CB",
??????? "CC", "CD", "CE", "CF", "D0", "D1", "D2", "D3", "D4", "D5", "D6",
??????? "D7", "D8", "D9", "DA", "DB", "DC", "DD", "DE", "DF", "E0", "E1",
??????? "E2", "E3", "E4", "E5", "E6", "E7", "E8", "E9", "EA", "EB", "EC",
??????? "ED", "EE", "EF", "F0", "F1", "F2", "F3", "F4", "F5", "F6", "F7",
??????? "F8", "F9", "FA", "FB", "FC", "FD", "FE", "FF" };
??????? private final static byte[] val = { 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x00, 0x01,
??????? 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F,
??????? 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F, 0x3F };
??????? /**
??????? * 編碼
??????? *
??????? * @param s
??????? * @return
??????? */
??????? public static String escape(String s) {
??????? StringBuffer sbuf = new StringBuffer();
??????? int len = s.length();
??????? for (int i = 0; i < len; i++) {
??????? int ch = s.charAt(i);
??????? if ('A' <= ch && ch <= 'Z') { // 'A'..'Z' : as it was
??????? sbuf.append((char) ch);
??????? } else if ('a' <= ch && ch <= 'z') { // 'a'..'z' : as it was
??????? sbuf.append((char) ch);
??????? } else if ('0' <= ch && ch <= '9') { // '0'..'9' : as it was
??????? sbuf.append((char) ch);
??????? } else if (ch == '-' || ch == '_' // unreserved : as it was
??????? || ch == '.' || ch == '!' || ch == '~' || ch == '*'
??????? || ch == '\'' || ch == '(' || ch == ')') {
??????? sbuf.append((char) ch);
??????? } else if (ch <= 0x007F) { // other ASCII : map to %XX
??????? sbuf.append('%');
??????? sbuf.append(hex[ch]);
??????? } else { // unicode : map to %uXXXX
??????? sbuf.append('%');
??????? sbuf.append('u');
??????? sbuf.append(hex[(ch >>> 8)]);
??????? sbuf.append(hex[(0x00FF & ch)]);
??????? }
??????? }
??????? return sbuf.toString();
??????? }
??????? /**
??????? * 解碼 說明:本方法保證 不論參數s是否經過escape()編碼,均能得到正確的“解碼”結果
??????? *
??????? * @param s
??????? * @return
??????? */
??????? public static String unescape(String s) {
??????? StringBuffer sbuf = new StringBuffer();
??????? int i = 0;
??????? int len = s.length();
??????? while (i < len) {
??????? int ch = s.charAt(i);
??????? if ('A' <= ch && ch <= 'Z') { // 'A'..'Z' : as it was
??????? sbuf.append((char) ch);
??????? } else if ('a' <= ch && ch <= 'z') { // 'a'..'z' : as it was
??????? sbuf.append((char) ch);
??????? } else if ('0' <= ch && ch <= '9') { // '0'..'9' : as it was
??????? sbuf.append((char) ch);
??????? } else if (ch == '-' || ch == '_' // unreserved : as it was
??????? || ch == '.' || ch == '!' || ch == '~' || ch == '*'
??????? || ch == '\'' || ch == '(' || ch == ')') {
??????? sbuf.append((char) ch);
??????? } else if (ch == '%') {
??????? int cint = 0;
??????? if ('u' != s.charAt(i + 1)) { // %XX : map to ascii(XX)
??????? cint = (cint << 4) | val[s.charAt(i + 1)];
??????? cint = (cint << 4) | val[s.charAt(i + 2)];
??????? i += 2;
??????? } else { // %uXXXX : map to unicode(XXXX)
??????? cint = (cint << 4) | val[s.charAt(i + 2)];
??????? cint = (cint << 4) | val[s.charAt(i + 3)];
??????? cint = (cint << 4) | val[s.charAt(i + 4)];
??????? cint = (cint << 4) | val[s.charAt(i + 5)];
??????? i += 5;
??????? }
??????? sbuf.append((char) cint);
??????? } else { // 對應的字符未經過編碼
??????? sbuf.append((char) ch);
??????? }
??????? i++;
??????? }
??????? return sbuf.toString();
??????? }
??????? public static void main(String[] args) {
??????? String stest = "中文1234 abcd[]()<+>,.~\\";
??????? System.out.println(stest);
??????? System.out.println(escape(stest));
??????? System.out.println(unescape(escape(stest)));
??????? }
??????? }
?