• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            天下

            記錄修行的印記

            AscII,Unicode,utf-8 utf-16,utf-32,BOM 的解說(三)

            基本知識

            介紹Unicode之前,首先要講解一些基礎知識。雖然跟Unicode沒有直接的關系,但想弄明白Unicode,沒這些還真不行。

            字節和字符的區別

            咦,字節和字符能有什么區別啊?不都是一樣的嗎?完全正確,但只是在古老的DOS時代。當Unicode出現后,字節和字符就不一樣了。

            字節(octet)是一個八位的存儲單元,取值范圍一定是0~255。而字符(character,或者word)為語言意義上的符號,范圍就不一定了。例如在UCS-2中定義的字符范圍為0~65535,它的一個字符占用兩個字節。

            Big Endian和Little Endian

            上面提到了一個字符可能占用多個字節,那么這多個字節在計算機中如何存儲呢?比如字符0xabcd,它的存儲格式到底是 AB CD,還是 CD AB 呢?

            實際上兩者都有可能,并分別有不同的名字。如果存儲為 AB CD,則稱為Big Endian;如果存儲為 CD AB,則稱為Little Endian。

            具體來說,以下這種存儲格式為Big Endian,因為值(0xabcd)的高位(0xab)存儲在前面:

            地址
             值
             
            0x00000000
             AB
             
            0x00000001
             CD
             

            相反,以下這種存儲格式為Little Endian:

            地址
             值
             
            0x00000000
             CD
             
            0x00000001
             AB
             

            UCS-2和UCS-4

            Unicode是為整合全世界的所有語言文字而誕生的。任何文字在Unicode中都對應一個值,這個值稱為代碼點(code point)。代碼點的值通常寫成 U+ABCD 的格式。而文字和代碼點之間的對應關系就是UCS-2(Universal Character Set coded in 2 octets)。顧名思義,UCS-2是用兩個字節來表示代碼點,其取值范圍為 U+0000~U+FFFF。

            為了能表示更多的文字,人們又提出了UCS-4,即用四個字節表示代碼點。它的范圍為 U+00000000~U+7FFFFFFF,其中 U+00000000~U+0000FFFF和UCS-2是一樣的。

            要注意,UCS-2和UCS-4只規定了代碼點和文字之間的對應關系,并沒有規定代碼點在計算機中如何存儲。規定存儲方式的稱為UTF(Unicode Transformation Format),其中應用較多的就是UTF-16和UTF-8了。

            UTF-16和UTF-32

            UTF-16

            UTF-16由 RFC2781規定,它使用兩個字節來表示一個代碼點。

            不難猜到,UTF-16是完全對應于UCS-2的,即把UCS-2規定的代碼點通過Big Endian或Little Endian方式直接保存下來。UTF-16包括三種:UTF-16,UTF-16BE(Big Endian),UTF-16LE(Little Endian)。

            UTF-16BE和UTF-16LE不難理解,而UTF-16就需要通過在文件開頭以名為BOM(Byte Order Mark)的字符來表明文件是Big Endian還是Little Endian。BOM為U+FEFF這個字符。

            其實BOM是個小聰明的想法。由于UCS-2沒有定義U+FFFE,因此只要出現 FF FE 或者 FE FF 這樣的字節序列,就可以認為它是U+FEFF,并且可以判斷出是Big Endian還是Little Endian。

            舉個例子。"ABC"這三個字符用各種方式編碼后的結果如下:

            UTF-16BE
             00 41 00 42 00 43
             
            UTF-16LE
             41 00 42 00 43 00
             
            UTF-16(Big Endian)
             FE FF 00 41 00 42 00 43
             
            UTF-16(Little Endian)
             FF FE 41 00 42 00 43 00
             
            UTF-16(不帶BOM)
             00 41 00 42 00 43
             

            Windows平臺下默認的Unicode編碼為Little Endian的UTF-16(即上述的 FF FE 41 00 42 00 43 00)。你可以打開記事本,寫上ABC,然后保存,再用二進制編輯器看看它的編碼結果

             

            另外,UTF-16還能表示一部分的UCS-4代碼點——U+10000~U+10FFFF。表示算法比較復雜,簡單說明如下:

            從代碼點U中減去0x10000,得到U'。這樣U+10000~U+10FFFF就變成了 0x00000~0xFFFFF。
            用20位二進制數表示U'。 U'=yyyyyyyyyyxxxxxxxxxx
            將前10位和后10位用W1和W2表示,W1=110110yyyyyyyyyy,W2=110111xxxxxxxxxx,則 W1 = D800~DBFF,W2 = DC00~DFFF。
            例如,U+12345表示為 D8 08 DF 45(UTF-16BE),或者08 D8 45 DF(UTF-16LE)。

            但是由于這種算法的存在,造成UCS-2中的 U+D800~U+DFFF 變成了無定義的字符。

            UTF-32

            UTF-32用四個字節表示代碼點,這樣就可以完全表示UCS-4的所有代碼點,而無需像UTF-16那樣使用復雜的算法。與UTF-16類似,UTF-32也包括UTF-32、UTF-32BE、UTF-32LE三種編碼,UTF-32也同樣需要BOM字符。僅用'ABC'舉例:

            UTF-32BE
             00 00 00 41 00 00 00 42 00 00 00 43
             
            UTF-32LE
             41 00 00 00 42 00 00 00 43 00 00 00
             
            UTF-32(Big Endian)
             00 00 FE FF 00 00 00 41 00 00 00 42 00 00 00 43
             
            UTF-32(Little Endian)
             FF FE 00 00 41 00 00 00 42 00 00 00 43 00 00 00
             
            UTF-32(不帶BOM)
             00 00 00 41 00 00 00 42 00 00 00 43
             

            UTF-8

            UTF-16和UTF-32的一個缺點就是它們固定使用兩個或四個字節,這樣在表示純ASCII文件時會有很多00字節,造成浪費。而RFC3629定義的UTF-8則解決了這個問題。

            UTF-8用1~4個字節來表示代碼點。表示方式如下:

            UCS-2 (UCS-4)
             位序列
             第一字節
             第二字節
             第三字節
             第四字節
             
            U+0000 .. U+007F
             00000000-0xxxxxxx
             0xxxxxxx
              
              
              
             
            U+0080 .. U+07FF
             00000xxx-xxyyyyyy
             110xxxxx
             10yyyyyy
              
              
             
            U+0800 .. U+FFFF
             xxxxyyyy-yyzzzzzz
             1110xxxx
             10yyyyyy
             10zzzzzz
              
             
            U+10000..U+1FFFFF
             00000000-000wwwxx-

            xxxxyyyy-yyzzzzzzz
             11110www
             10xxxxxx
             10yyyyyy
             10zzzzzz
             

            可見,ASCII字符(U+0000~U+007F)部分完全使用一個字節,避免了存儲空間的浪費。而且UTF-8不再需要BOM字節。

            另外,從上表中可以看出,單字節編碼的第一字節為[00-7F],雙字節編碼的第一字節為[C2-DF],三字節編碼的第一字節為[E0-EF]。這樣只要看到第一個字節的范圍就可以知道編碼的字節數。這樣也可以大大簡化算法。

             

            本文來自CSDN博客,轉載請標明出處:http://blog.csdn.net/fan158/archive/2009/01/16/3796857.aspx

            posted on 2010-10-25 11:02 天下 閱讀(517) 評論(0)  編輯 收藏 引用

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            導航

            統計

            常用鏈接

            留言簿(4)

            隨筆分類(378)

            隨筆檔案(329)

            鏈接

            最新隨筆

            搜索

            最新評論

            国产精品一区二区久久精品涩爱| 奇米影视7777久久精品| 亚洲国产精品无码久久98| 性欧美大战久久久久久久| 久久91精品综合国产首页| 久久精品一区二区三区不卡| 国产精品对白刺激久久久| 久久人人妻人人爽人人爽| 亚洲欧美精品一区久久中文字幕| 久久www免费人成精品香蕉| 国产精品热久久毛片| 精品久久久久久无码免费| 久久99国产一区二区三区| 久久久WWW成人免费毛片| 人妻中文久久久久| 亚洲一区精品伊人久久伊人| 久久天天躁狠狠躁夜夜2020一| 精品久久久一二三区| 亚洲va久久久噜噜噜久久| 久久精品人人做人人爽电影蜜月| 久久综合九色综合97_久久久| 99久久综合狠狠综合久久| 久久涩综合| 久久夜色精品国产网站| 成人亚洲欧美久久久久 | 欧美久久久久久精选9999| 无码乱码观看精品久久| 性做久久久久久久| 国产成人精品久久一区二区三区av | 欧美亚洲国产精品久久高清| 综合网日日天干夜夜久久 | 久久亚洲精品成人无码网站| 日韩AV无码久久一区二区| 97精品伊人久久大香线蕉app| 狠狠人妻久久久久久综合蜜桃| 少妇无套内谢久久久久| 99精品国产在热久久无毒不卡 | 久久综合久久综合亚洲| 国产亚洲色婷婷久久99精品| 久久免费视频6| 成人久久精品一区二区三区|