<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    MDA/MDD/TDD/DDD/DDDDDDD
    posts - 536, comments - 111, trackbacks - 0, articles - 0
      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

    字符集和編碼方式(轉)

    Posted on 2009-10-08 17:55 leekiang 閱讀(530) 評論(1)  編輯  收藏 所屬分類: java數據結構,算法,基礎
    搞清常用編碼特性是解決字符集編碼問題的基礎。字符集編碼的識別與轉換、分析各種亂碼產生的原因、編程操作各種編碼字符串(例如字符數計算、截斷處理)等都需要弄清楚編碼的特性。
    了解一種字符集編碼主要是要了解該編碼的編碼范圍,編碼對應的字符集(都包含哪些字符),和其他字符集編碼之間的關系等。
    --------1. ASCII--------
    ASCII碼是7位編碼,編碼范圍是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯數字和標點符號等字符。其中0x00-0x20和0x7F共33個控制字符。
    只支持ASCII碼的系統會忽略每個字節的最高位,只認為低7位是有效位。HZ字符編碼就是早期為了在只支持7位ASCII系統中傳輸中文而設計的編碼。早期很多郵件系統也只支持ASCII編碼,為了傳輸中文郵件必須使用BASE64或者其他編碼方式。
    --------2. GB2312--------
    GB2312 是基于區位碼設計的,區位碼把編碼表分為94個區,每個區對應94個位,每個字符的區號和位號組合起來就是該漢字的區位碼。區位碼一般用10進制數來表 示,如1601就表示16區1位,對應的字符是"啊"。在區位碼的區號和位號上分別加上0xA0就得到了GB2312編碼。
    區位碼中 01-09區是符號、數字區,16-87區是漢字區,10-15和88-94是未定義的空白區。它將收錄的漢字分成兩級:第一級是常用漢字計3755個, 置于16-55區,按漢語拼音字母/筆形順序排列;第二級漢字是次常用漢字計3008個,置于56-87區,按部首/筆畫順序排列。一級漢字是按照拼音排 序的,這個就可以得到某個拼音在一級漢字區位中的范圍,很多根據漢字可以得到拼音的程序就是根據這個原理編寫的。
    GB2312字符集中除常用簡體漢字字符外還包括希臘字母、日文平假名及片假名字母、俄語西里爾字母等字符,未收錄繁體中文漢字和一些生僻字。可以用繁體漢字測試某些系統是不是只支持GB2312編碼。
    GB2312的編碼范圍是0xA1A1-0x7E7E,去掉未定義的區域之后可以理解為實際編碼范圍是0xA1A1-0xF7FE。
    EUC-CN可以理解為GB2312的別名,和GB2312完全相同。
    區 位碼更應該認為是字符集的定義,定義了所收錄的字符和字符位置,而GB2312及EUC-CN是實際計算機環境中支持這種字符集的編碼。HZ和ISO- 2022-CN是對應區位碼字符集的另外兩種編碼,都是用7位編碼空間來支持漢字。區位碼和GB2312編碼的關系有點像 Unicode和UTF-8。
    --------3. GBK--------
    GBK編碼是GB2312編碼的超集,向下完全兼容 GB2312,同時GBK收錄了Unicode基本多文種平面中的所有CJK漢字。同 GB2312一樣,GBK也支持希臘字母、日文假名字母、俄語字母等字符,但不支持韓語中的表音字符(非漢字字符)。GBK還收錄了GB2312不包含的 漢字部首符號、豎排標點符號等字符。
    GBK的整體編碼范圍是為0x8140-0xFEFE,不包括低字節是0×7F的組合。高字節范圍是0×81-0xFE,低字節范圍是0x40-7E和0x80-0xFE。
    低字節是0x40-0x7E的GBK字符有一定特殊性,因為這些字符占用了ASCII碼的位置,這樣會給一些系統帶來麻煩。
    有 些系統中用0x40-0x7E中的字符(如"|")做特殊符號,在定位這些符號時又沒有判斷這些符號是不是屬于某個 GBK字符的低字節,這樣就會造成錯誤判斷。在支持GB2312的環境下就不存在這個問題。需要注意的是支持GBK的環境中小于0x80的某個字節未必就 是ASCII符號;另外就是最好選用小于0×40的ASCII符號做一些特殊符號,這樣就可以快速定位,且不用擔心是某個漢字的另一半。Big5編碼中也 存在相應問題。
    CP936和GBK的有些許差別,絕大多數情況下可以把CP936當作GBK的別名。
    --------4. GB18030--------
    GB18030編碼向下兼容GBK和GB2312,兼容的含義是不僅字符兼容,而且相同字符的編碼也相同。GB18030收錄了所有Unicode3.1中的字符,包括中國少數民族字符,GBK不支持的韓文字符等等,也可以說是世界大多民族的文字符號都被收錄在內。
    GBK和GB2312都是雙字節等寬編碼,如果算上和ASCII兼容所支持的單字節,也可以理解為是單字節和雙字節混合的變長編碼。GB18030編碼是變長編碼,有單字節、雙字節和四字節三種方式。
    GB18030 的單字節編碼范圍是0x00-0x7F,完全等同與ASCII;雙字節編碼的范圍和GBK相同,高字節是0x81-0xFE,低字節的編碼范圍是 0x40-0x7E和0x80-FE;四字節編碼中第一、三字節的編碼范圍是0x81-0xFE,二、四字節是0x30-0x39。
    Windows 中CP936代碼頁使用0x80來表示歐元符號,而在GB18030編碼中沒有使用0x80編碼位,用其他位置來表示歐元符號。這可以理解為是 GB18030向下兼容性上的一點小問題;也可以理解為0x80是CP936對GBK的擴展,而GB18030只是和GBK兼容良好。
    --------5. BIG5--------
    Big5是雙字節編碼,高字節編碼范圍是0x81-0xFE,低字節編碼范圍是0x40-0x7E和0xA1-0xFE。和GBK相比,少了低字節是0x80-0xA0的組合。0x8140-0xA0FE是保留區域,用于用戶造字區。
    Big5 收錄的漢字只包括繁體漢字,不包括簡體漢字,一些生僻的漢字也沒有收錄。GBK收錄的日文假名字符、俄文字符Big5也沒有收錄。因為Big5當中收錄的 字符有限,因此有很多在Big5基礎上擴展的編碼,如倚天中文系統。Windows系統上使用的代碼頁CP950也可以理解為是對Big5的擴展,在 Big5的基礎上增加了7個漢字和一些符號。Big5編碼對應的字符集是GBK字符集的子集,也就是說Big5收錄的字符是GBK收錄字符的一部分,但相 同字符的編碼不同。
    因為Big5也占用了ASCII的編碼空間(低字節所使用的0x40-0x7E),所以Big5編碼在一些環境下存在和 GBK編碼相同的問題,即低字節范圍為0x40-0x7E的字符有可能會被誤處理,尤其是低字節是0x5C("/")和0x7C("|")的字符。可以參 考GBK一節相應說明。
    盡管有些區別,大多數情況下可以把CP950當作Big5的別名。
    --------6. ISO-8859-1--------
    ISO-8859-1編碼是單字節編碼,向下兼容ASCII,其編碼范圍是0x00-0xFF,0x00-0x7F之間完全和ASCII一致,0x80-0x9F之間是控制字符,0xA0-0xFF之間是文字符號。
    ISO-8859-1收錄的字符除ASCII收錄的字符外,還包括西歐語言、希臘語、泰語、阿拉伯語、希伯來語對應的文字符號。歐元符號出現的比較晚,沒有被收錄在ISO-8859-1當中。
    因 為ISO-8859-1編碼范圍使用了單字節內的所有空間,在支持ISO-8859-1的系統中傳輸和存儲其他任何編碼的字節流都不會被拋棄。換言之,把 其他任何編碼的字節流當作ISO-8859-1編碼看待都沒有問題。這是個很重要的特性,MySQL數據庫默認編碼是Latin1就是利用了這個特性。 ASCII編碼是一個7位的容器,ISO-8859-1編碼是一個8位的容器。
    Latin1是ISO-8859-1的別名,有些環境下寫作Latin-1。
    --------7. UCS-2和UTF-16--------
    Unicode 組織和ISO組織都試圖定義一個超大字符集,目的是要涵蓋所有語言使用的字符以及其他學科使用的一些特殊符號,這個字符集就是通用字符集 (UCS,Universal Character Set)。這兩個組織經過協調,雖然在各自發展,但定義的字符位置是完全一致的。ISO相應的標準是ISO 10646。Unicode和ISO 10646都在不斷的發展過程中,所以會有不同的版本號來標明不同的發展階段,每個Unicode版本號都能找到相對應的ISO 10646版本號。
    ISO 10646標準定義了一個31位的字符集。前兩個字節的位置(0x0000-0xFFFD)被稱為基本多語言面(Basic Multilingual Plane, BMP),超出兩個字節的范圍稱作輔助語言面。BMP基本包括了所有語言中絕大多數字符,所以只要支持BMP就可以支持絕大多數場合下的應用。 Unicode 3.0對應的字符集在BMP范圍內。
    UCS字符集為每個字符分配了一個位置,通常用"U"再加上某個字符在UCS中位置的16進制數作為這個字符的UCS表示,例如"U+0041"表示字符"A"。UCS字符U+0000到U+00FF與ISO-8859-1完全一致。
    UCS- 2、UTF-16是UCS字符集(或者說是Unicode字符集)實際應用中的具體編碼方式。UCS-2是兩個字節的等寬編碼,因為只是使用了兩個字節的 編碼空間,所以只能對BMP中的字符做編碼。UTF-16是變長編碼,用兩個字節對BMP內的字符編碼,用4個字節對超出BMP范圍的輔助平面內的字符作 編碼。
    UCS-2不同于GBK和Big5,它是真正的等寬編碼,每個字符都使用兩個字節,這個特性在字符串截斷和字符數計算時非常方便。
    UTF-16是UCS-2的超集,UTF-16編碼的兩字節編碼方式完全和UCS-2相同,也就是說在BMP的框架內UCS-2完全等同與UTF-16。實際情況當中常常把UTF-16當作UCS-2的別名。
    UCS- 2和UTF-16在存儲和傳輸時會使用兩種不同的字節序,分別是big endian和little endian(大尾和小尾)。例如"啊"(U+554A)用big endian表示就是0x554A,用little endian表示就是0x4A55。UCS-2和UTF-16默認的字節序是big endian方式。在傳輸過程中為了說明字節序需要在字節流前加上BOM(Byte order Mark),0xFEFF表示是big endian,0xFFFE表示是little endian。UCS-2BE、UCS-2LE是實際應用中使用的編碼名稱,對應著big endian和little endian,UTF-16BE、UTF-16LE也是如此。因為默認是BE字節序,所以可以把UCS-2當做是UCS-2BE的別名。
    在 UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字符,它的編碼是U+FEFF,是個沒有實際意義的字符。UCS規范建議我們在傳輸字節流前,先傳輸字符"ZERO WIDTH NO-BREAK SPACE",如果傳輸的ZERO WIDTH NO-BREAK SPACE是0xFEFF就說明是big endian,反之就是little endian。
    UCS-2和UTF-16也可以理解為和ASCII以及ISO-8859-1兼容,在ASCII編碼或者ISO-8859-1編碼的每個字節前加上0x00,就得到相應字符的UCS-2編碼。
    UCS-2和UTF-16中會使用0x00作為某個字符編碼的一部分,某些系統會把0x00當作字符串結束的標志,在處理UCS-2或UTF-16編碼時會出現問題。
    --------8. UTF-8--------
    UTF-8是UCS字符集的另一種編碼方式,UTF-16的每個單元是兩個字節(16位),而UTF-8的每個單元是一個字節(8位)。UTF-16中用一個或兩個雙字節表示一個字符,UTF-8中用一個或幾個單字節表示一個字符。
    可以認為UTF-8編碼是根據一定規律從UCS-2轉換得到的,從UCS-2到UTF-8之間有以下轉換關系:
    UCS-2 UTF-8
    U+0000 - U+007F 0xxxxxxx
    U+0080 - U+07FF 110xxxxx 10xxxxxx
    U+0800 - U+FFFF 1110xxxx 10xxxxxx 10xxxxxx
    例如"啊"字的UCS-2編碼是0x554A,對應的二進制是0101 0101 0100 1010,轉成UTF-8編碼之后的二進制是1110 0101 10 010101 10 001010,對應的十六進制是0xE5958A。
    UCS- 4也是一種UCS字符集的編碼方式,是使用4個字節的等寬編碼,可以用UCS-4來表示BMP之外的輔助面字符。UCS-2中每兩個字節前再加上 0x0000就得到了BMP字符的UCS-4編碼。從UCS-4到UTF-8也存在轉換關系,根據這種轉換關系,UTF-8最多可以使用六個字節來編碼 UCS-4。
    根據UTF-8的生成規律和UCS字符集的特性,可以看到UTF-8具有的特性:
    UTF-8完全和ASCII兼容,也就是說ASCII對應的字符在UTF-8中和ASCII編碼完全一致。范圍在0x00-0x7F之內的字符一定是ASCII字符,不可能是其他字符的一部分。GBK和Big5都存在的缺陷在UTF-8中是不存在的。
    大于U+007F的UCS字符,在UTF-8編碼中至少是兩個字節。
    UTF-8中的每個字符編碼的首字節總在0x00-0xFD之間(不考慮UCS-4支持的情況,首字節在0x00-0xEF之間)。根據首字節就可以判斷之后連續幾個字節。
    非首字節的其他字節都在0x80-0xBF之間;0xFE和0xFF在UTF-8中沒有被用到。
    GBK編碼中的漢字字符都在UCS-2中的范圍都在U+0800 - U+FFFF之間,所以每個GBK編碼中的漢字字符的UTF-8編碼都是3個字節。但GBK中包含的其他字符的UTF-8編碼就不一定是3個字節了,如GBK中的俄文字符。
    在UTF-8的編碼的傳輸過程中即使丟掉一個字節,根據編碼規律也很容易定位丟掉的位置,不會影響到其他字符。在其他雙字節編碼中,一旦損失一個字節,就會影響到此字節之后的所有字符。從這點可以看出UTF-8編碼非常適合作為傳輸編碼!
    出處:http://i.cn.yahoo.com/07609654986/blog/p_14/

    評論

    # re: 字符集和編碼方式(轉)  回復  更多評論   

    2009-10-08 18:36 by leekiang
    Windows 和 Java 的 "Unicode" 一開始是 UCS-2。UCS-2 是定長的,就是說固定兩個字節表示一個字符,后來兩個字節不夠用了,擴充到 UTF-16,UTF-16 同樣也以雙子節為編碼單元,但是存在四字節的字符。 直到 Java5,才把 UCS-2 改成 UTF-16,其中涉及的改動非常非常多,像 String.length() 的行為和實現已經不一樣了。
    主站蜘蛛池模板: 国产亚洲精品AAAA片APP| 免费黄色app网站| 最好免费观看韩国+日本| 在线观着免费观看国产黄| 亚洲av中文无码乱人伦在线播放| 亚洲精品综合一二三区在线 | 亚洲人成电影福利在线播放| 亚洲国产精品无码久久| a级片免费观看视频| 免费jjzz在在线播放国产| 亚洲国产精品久久久天堂 | 午夜亚洲www湿好大| 亚洲av日韩av永久在线观看| 亚欧免费一级毛片| 亚洲人成无码www久久久| 亚洲午夜精品久久久久久app| 午夜精品射精入后重之免费观看| 亚洲精品老司机在线观看| 亚洲精品无码中文久久字幕| 免费国产叼嘿视频大全网站| 免费国产成人高清视频网站| 精品久久亚洲中文无码| 1000部禁片黄的免费看| 亚洲高清在线视频| a毛片在线还看免费网站| 亚洲国产精品狼友中文久久久| 中文字幕亚洲码在线| 成人免费无码大片a毛片软件| 亚洲无成人网77777| 亚洲高清视频免费| 亚洲人成在线中文字幕| 久久免费看黄a级毛片| 亚洲免费视频播放| 天天看免费高清影视| 粉色视频成年免费人15次| 亚洲国产成人影院播放| a级在线观看免费| 亚洲欧洲尹人香蕉综合| 日本媚薬痉挛在线观看免费| 亚洲av中文无码字幕色不卡| 亚洲av无码成人精品区|