utf8中文編碼範圍

UTF-8有點類似於Haffman編碼，它將Unicode編碼為：00000000-0000007F的字元，用單個位元組來表示；00000080-000007FF的字元用兩個位元組表示 （中文的編碼範圍）00000800-0000FFFF的字元用3位元組表示編碼轉換：iconv -f “檔案目前編碼” -t “檔案轉換後的編碼” -o “轉換後產生的新檔案名稱” “源檔案名稱”temp = Iconv.conv(“UTF-8″,“gb2312″,a)因為目前為止Unicode-16規範沒有指定FFFF以上的字元，所以UTF-8最多是使用3個位元組來表示一個字元。但理論上來說，UTF-8最多需要用6位元組表示一個字元。在UTF-8裡，英文字元仍然跟ASCII編碼一樣，因此原先的函數庫可以繼續使用。而中文的編碼範圍是在0080-07FF之間，因此是2個位元組表示（但這兩個位元組和GB編碼的兩個位元組是不同的）。0、big endian和little endianbig endian和littleendian是CPU處理多位元組數的不同方式。例如“漢”字的Unicode編碼是6C49。那麼寫到檔案裡時，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是bigendian。還是將49寫在前面，就是little endian。“endian”這個詞出自《格列佛遊記》。小人國的內戰就源於吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，其中一個皇帝送了命，另一個丟了王位。我們一般將endian翻譯成“位元組序”，將big endian和littleendian稱作“大尾”和“小尾”。4、UTF編碼UTF-8就是以8位為單元對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下：UCS-2編碼(16進位) UTF-8 位元組流(二進位)0000 – 007F 0xxxxxxx0080 – 07FF 110xxxxx 10xxxxxx0800 – FFFF 1110xxxx 10xxxxxx 10xxxxxx例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以肯定要用3位元組模板了：1110xxxx10xxxxxx 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的位元組序和BOMUTF-8以位元組為編碼單元，沒有位元組序的問題。UTF-16以兩個位元組為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的位元組序。 例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16位元組流“594E”，那麼這是“奎 ”還是“乙”？Unicode規範中推薦的標記位元組順序的方法是BOM。BOM不是“Bill OfMaterial”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：在UCS編碼中有一個叫做”ZERO WIDTH NO-BREAKSPACE”的字元，它的編碼是FEFF。而FFFE在UCS中是不存在的字元，所以不應該出現在實際傳輸中。UCS規範建議我們在傳輸位元組流前，先傳輸字元”ZEROWIDTH NO-BREAK SPACE”。這樣如果接收者收到FEFF，就表明這個位元組流是Big-Endian的；如果收到FFFE，就表明這個位元組流是Little-Endian的。因此字元”ZEROWIDTH NO-BREAK SPACE”又被稱作BOM。UTF-8不需要BOM來表明位元組順序，但可以用BOM來表明編碼方式。字元”ZEROWIDTH NO-BREAK SPACE”的UTF-8編碼是EF BBBF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BBBF開頭的位元組流，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文字檔的編碼方式的。