轉換字符的大小寫是一個很常用的功能,例如 char.ToUpper、char.ToLower 或者 TextInfo.ToUpper 和 TextInfo.ToLower,這些 API 都只操作單個字符,如果遇到了一個字符范圍,是需要遍歷范圍內的每個字符并依次執行轉換,
以從大寫字符轉換為小寫字符為例,對于一個字符范圍 A-Z,可以很容易的分辨出相應的小寫字符范圍為 a-z,這里有幾個條件:
- 從
A-Z到a-z的轉換,可以通過字符值 + 32 計算得到, A-Z是連續的大寫字符范圍,
類似的,對于任意字符范圍,只要確認其中連續的大寫字符范圍,再將其起始和結束字符轉換為相應的小寫字符,就完成了轉換,
接下來,就是如何確認其中連續的大寫字符范圍了,系統正則運算式庫中的一個內部類 RegexCharClass 提供了一個方案,這里定義了一個 LowerCaseMapping 陣列,里面按順序定義了所有大寫字符范圍和從大寫字符到小寫字符的轉換方式,部分示例如下所示:
new LowerCaseMapping('\u0041', '\u005A', LowercaseAdd, 32),
new LowerCaseMapping('\u00C0', '\u00DE', LowercaseAdd, 32),
new LowerCaseMapping('\u0100', '\u012E', LowercaseBor, 0),
new LowerCaseMapping('\u0130', '\u0130', LowercaseSet, 0x0069),
字符范圍可以直接在這個陣列內二分得到,比較特別的就是如何從大寫字符轉換到相應的小寫字符,直接呼叫系統方法當然是一個方案,不過 RegexCharClass 的實作更為優化些,
根據統計,大小寫字符間的關系只有兩種:
- 將大寫字符加上/減去一個字符得到相應的小寫字符,例如
'A' + 32 = 'a',這種場景下大寫字符和小寫字符一般是互不覆寫的, - 將大寫字符加 1 得到相應的小寫字符,例如
'ā' + 1 = 'ā',這種場景下大寫字符和小寫字符會依次出現,基本處于同一個范圍,
第一類關系很容易處理,LowercaseAdd 操作就是為當前字符加上一個固定的偏移量,只是會有一些特例,有時兩個連續大寫字符會對應同一個小寫字符,例如 ? (\u01C4) 和 ? (\u01C5) 對應的小寫字符都是 ? (\u01C6),此時使用 LowercaseSet 操作來直接設定為指定的字符,
第二類操作會略微復雜,如果將每個大寫字符分別當作獨立的字符范圍,就會產生過多的零碎的字符范圍,非常不利于性能優化,而如果將大寫和小寫字符混合為同一個范圍,[ā-?],由于 ? + 1 = ?,這樣的字符范圍就會被轉換為 [ā-?] 從而導致錯誤,
這時就需要一種“對小寫字符無效”的轉換方式了,將大寫字符按照奇偶分為兩類:
- 如果大寫字符為偶數(例如上面的
ā (\u0100)),就選擇LowercaseBor操作,$lower = upper | 1$,這時大寫字符(偶數)或 1 后會變成小寫字符(奇數);而小寫字符或 1 后仍然是原值, - 如果大寫字符為奇數(例如
? (\u0139)),就選擇LowercaseBad操作,$lower = upper + (upper & 1)$,這時大寫字符(奇數)加上其最低位后會變成小寫字符(偶數);而小寫字符最低為是 0,加上之后仍然是原值,
RegexCharClass 只包含了將大寫字符轉換為小寫字符的能力,需要自己擴展從小寫字符轉換為大寫字符的操作,
第一類操作也是類似的,同樣利用 Add 和 Set 就可以實作小寫字符到大寫字符的轉換,第二類操作也同樣需要區分奇偶,只是操作方式不太相同:
- 如果小寫字符為奇數(例如上面的
ā (\u0101)),就使用 $upper = lower & 0xFFFE$,這時小寫字符(奇數)的最后一位會被置 0,變成大寫字符(偶數);而大寫字符最后一位置 0 后仍然是原值, - 如果小寫字符為偶數(例如
? (\u0140)),就使用 $upper = lower - (~lower & 1)$,這時小寫字符(偶數)最低為取反后是 1,減去就會會變成大寫字符(奇數);而大寫字符最低為是 1,取反后仍然是 0,減去后會保持原值不變,
操作已經有了,就要計算所有小寫字符的范圍,這時我發現 RegexCharClass 內置的字符范圍只包含了部分 InvariantCulture 中的小寫字符,不太好確認正則運算式庫是受限于歷史問題還是使用了舊版 Unicode 標準,
同時,不同區域的大小寫范圍并不完全一致,要實作兼容其它區域性的范圍大小寫轉換,就需要在運行時產出映射表,而非依靠提前計算,
我在這里實作了一個運行時計算方案,實測下來在 InvariantCulture 區域性下得到了 169 個大寫字符范圍和 189 個小寫字符范圍,在 zh-CN 區域性下得到了 170 個大寫字符范圍和 190 個小寫字符范圍,其中的差異就是在 zh-CN 區域性下,? 會對應的小寫字符 i,
完整的字符范圍大小寫轉換可以在這里找到,
作者:CYJB
出處:http://www.cnblogs.com/cyjb/
GitHub:https://github.com/CYJB/
本文著作權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段宣告,且在文章頁面明顯位置給出原文連接,否則保留追究法律責任的權利,
轉載請註明出處,本文鏈接:https://www.uj5u.com/net/465908.html
標籤:C#
