計算機中的字是如何處理的？
如果你用放大鏡看一下，可以看出屏幕上的字是由一個一個的像素點組成的，每一個字符用一組像素點拼接出來，這些像素點組成一幅圖像，變成了我們的文字，計算機又是如何將我們的文字保存起來的呢？是用一個個的點組成的圖像將文字保存起來的嗎？當(dāng)然不是，讓我們從英文開始，由于英文是拼音文字，實際上所有的英文字符和符號加起來也不超過 100 個，在我們的文字中存在著如此大量的重復(fù)符號，這就意味著保存每個字符的圖像會有大量的重復(fù)，比如 e 就是出現(xiàn)最多的符號等等。所以在計算機中，實際上不會保存字符的圖像。
什么是字符編碼？
由于我們的文字中存在著大量的重復(fù)字符，而計算機天生就是用來處理數(shù)字的 , 為了減少我們需要保存的信息量，我們可以使用一個數(shù)字編碼來表示每一個字符，通過對每一個字符規(guī)定一個唯一的數(shù)字代號，然后，對應(yīng)每一個代號，建立其相對應(yīng)的圖形，這樣，在每一個文件中，我們只需要保存每一個字符的編碼就相當(dāng)于保存了文字，在需要顯示出來的時候，先取得保存起來的編碼，然后通過編碼表，我們可以查到字符對應(yīng)的圖形，然后將這個圖形顯示出來，這樣我們就可以看到文字了，這些用來規(guī)定每一個字符所使用的代碼的表格，就稱為編碼表。編碼就是對我們?nèi)粘Ｊ褂米址囊环N數(shù)字編號。
第一個編碼表 ASCII
在最初的時候，美國人制定了第一張編碼表《美國標(biāo)準(zhǔn)信息交換碼》，簡稱 ASCII ，它總共規(guī)定了 128 個符號所對應(yīng)的數(shù)字代號，使用了 7 位二進(jìn)制的位來表示這些數(shù)字。其中包含了英文的大小寫字母、數(shù)字、標(biāo)點符號等常用的字符，數(shù)字代號從 0 至 127 ， ASCII 的表示內(nèi)容如下：
0 – 31 控制符號
32 空格
33-47 常用符號
48-57 數(shù)字
58-64 符號
65-90 大寫字母
91-96 符號
97-127 小寫字母
注意， 32 表示空格，雖然我們再紙上寫字時，只要手腕動一下，就可以流出一個空格，但是，在計算機上，空格與普通得字符一樣也需要用一個編碼來表示， 33-127 共 95 個編碼用來表示符號，數(shù)字和英文的大寫和小寫字母。比如數(shù)字 1 所對應(yīng)的數(shù)字代號為 49 ，大寫字母 A 對應(yīng)的代號為 65, 小寫字母 a 對應(yīng)的代號為 97 。所以，我們所寫的代碼 hello, world 保存在文件中時，實際上是保存了一組數(shù)字 104 101 108 108 111 44 32 119 111 114 108 100 。我們再程序中比較英文字符串的大小時，實際上也是比較字符對應(yīng)的 ASCII 的編碼大小。
由于 ASCII 出現(xiàn)最早，因此各種編碼實際上都受到了它的影響，并盡量與其相兼容。
擴展 ASCII 編碼 ISO8859
美國人順利解決了字符的問題，可是歐洲的各個國家還沒有，比如法語中就有許多英語中沒有的字符，因此 ASCII 不能幫助歐洲人解決編碼問題。
為了解決這個問題，人們借鑒 ASCII 的設(shè)計思想，創(chuàng)造了許多使用 8 位二進(jìn)制數(shù)來表示字符的擴充字符集，這樣我們就可以使用 256 種數(shù)字代號了，表示更多的字符了。在這些字符集中，從 0 - 127 的代碼與 ASCII 保持兼容，從 128 到 255 用于其它的字符和符號，由于有很多的語言，有著各自不同的字符，于是人們?yōu)椴煌恼Z言制定了大量不同的編碼表，在這些碼表中，從 128 - 255 表示各自不同的字符，其中，國際標(biāo)準(zhǔn)化組織的 ISO8859 標(biāo)準(zhǔn)得到了廣泛的使用。
在 ISO8859 的編碼表中，編號 0 – 127 與 ASCII 保持兼容，編號 128 – 159 共 32 個編碼保留給擴充定義的 32 個擴充控制碼， 160 為空格， 161 -255 的 95 個數(shù)字用于新增加的字符代碼。編碼的布局與 ASCII 的設(shè)計思想如出一轍，由于在一張碼表中只能增加 95 種字符的代碼，所以 ISO8859 實際上不是一張碼表，而是一系列標(biāo)準(zhǔn)，包括 14 個字符碼表。例如，西歐的常用字符就包含在 ISO8859-1 字符表中。在 ISO8859-7 種則包含了 ASCII 和現(xiàn)代希臘語字符。
問題出現(xiàn)了！
ISO 的 8859 標(biāo)準(zhǔn)解決了大量的字符編碼問題，但也帶來了新的問題，比如說，沒有辦法在一篇文章中同時使用 ISO8859-1 和 ISO8859-7 ，也就是說，在同一篇文章中不能同時出現(xiàn)希臘文和法文，因為他們的編碼范圍是重合的。例如：在 ISO8859-1 中 217 號編碼表示字符 ù ，而在 ISO8859-7 中則表示希臘字符 Ω ，這樣一篇使用 ISO8859-1 保存的文件，在使用 ISO8859-7 編碼的計算機上打開時，將看到錯誤的內(nèi)容。為了同時處理一種以上的文字，甚至還出現(xiàn)了一些同時包含原來不屬于同一張碼表的字符的新碼表。
大字符集的煩惱
不管如何，歐洲的拼音文字都還可以用一個字節(jié)來保存，一個字節(jié)由 8 個二進(jìn)制的位組成，用來表示無符號的整數(shù)的話，范圍正好是 0 – 255 。
但是，更嚴(yán)重的問題出現(xiàn)在東方，中國，朝鮮和日本的文字包含大量的符號。例如，中國的文字不是拼音文字，漢字的個數(shù)有數(shù)萬之多，遠(yuǎn)遠(yuǎn)超過區(qū)區(qū) 256 個字符，因此 ISO 的 8859 標(biāo)準(zhǔn)實際上不能處理中文的字符。
通過借鑒 ISO8859 的編碼思想，中國的專家靈巧的解決了中文的編碼問題。
既然一個字節(jié)的 256 種字符不能表示中文，那么，我們就使用兩個字節(jié)來表示一個中文，在每個字符的 256 種可能中，低于 128 的為了與 ASCII 保持兼容，我們不使用，借鑒 ISO8859 的設(shè)計方案，只使用從 160 以后的 96 個數(shù)字，兩個字節(jié)分成高位和低位，高位的取值范圍從 176-247 共 72 個，低位從 161 – 254 共 94 這樣，兩個字節(jié)就有 72 * 94 = 6768 種可能，也就是可以表示 6768 種漢字，這個標(biāo)準(zhǔn)我們稱為 GB2312-80 。
6768 個漢字顯然不能表示全部的漢字，但是這個標(biāo)準(zhǔn)是在 1980 年制定的，那時候，計算機的處理能力，存儲能力都還很有限，所以在制定這個標(biāo)準(zhǔn)的時候，實際上只包含了常用的漢字，這些漢字是通過對日常生活中的報紙，電視，電影等使用的漢字進(jìn)行統(tǒng)計得出的，大概占常用漢字的 99% 。因此，我們時常會碰到一些名字中的特殊漢字無法輸入到計算機中的問題，就是由于這些生僻的漢字不在 GB2312 的常用漢字之中的緣故。
由于 GB2312 規(guī)定的字符編碼實際上與 ISO8859 是沖突的，所以，當(dāng)我們在中文環(huán)境下看一些西文的文章，使用一些西文的軟件的時候，時常就會發(fā)現(xiàn)許多古怪的漢字出現(xiàn)在屏幕上，實際上就是因為西文中使用了與漢字編碼沖突的字符，被我們的系統(tǒng)生硬的翻譯成中文造成的。
不過， GB2312 統(tǒng)一了中文字符編碼的使用，我們現(xiàn)在所使用的各種電子產(chǎn)品實際上都是基于 GB2312 來處理中文的。
GB2312-80 僅收漢字 6763 個，這大大少于現(xiàn)有漢字，隨著時間推移及漢字文化的不斷延伸推廣，有些原來很少用的字，現(xiàn)在變成了常用字，例如：朱镕基的 “ 镕 ” 字，未收入 GB2312-80 ，現(xiàn)在大陸的報業(yè)出刊只得使用（金 + 容）、（金容）、（左金右容）等來表示，形式不一而同，這使得表示、存儲、輸入、處理都非常不方便，而且這種表示沒有統(tǒng)一標(biāo)準(zhǔn)。
為了解決這些問題，全國信息技術(shù)化技術(shù)委員會于 1995 年 12 月 1 日 《漢字內(nèi)碼擴展規(guī)范》。 GBK 向下與 GB2312 完全兼容，向上支持 ISO 10646 國際標(biāo)準(zhǔn)，在前者向后者過渡過程中起到的承上啟下的作用。 GBK 亦采用雙字節(jié)表示，總體編碼范圍為 8140-FEFE 之間，高字節(jié)在 81-FE 之間，低字節(jié)在 40-FE 之間，不包括 7F 。在 GBK 1.0 中共收錄了 21886 個符號，漢字有 21003 個。
GBK 共收入 21886 個漢字和圖形符號，包括：
* GB2312 中的全部漢字、非漢字符號。
* BIG5 中的全部漢字。
* 與 ISO 10646 相應(yīng)的國家標(biāo)準(zhǔn) GB13000 中的其它 CJK 漢字，以上合計 20902 個漢字。
* 其它漢字、部首、符號，共計 984 個。
微軟公司自 Windows 95 簡體中文版開始支持 GBK 代碼，但目前的許多軟件都不能很好地支持 GBK 漢字。
GBK 編碼區(qū)分三部分：
* 漢字區(qū) 包括
GBK/2 ： OXBOA1-F7FE, 收錄 GB2312 漢字 6763 個，按原序排列；
GBK/3 ： OX8140-AOFE ，收錄 CJK 漢字 6080 個；
GBK/4 ： OXAA40-FEAO ，收錄 CJK 漢字和增補的漢字 8160 個。
* 圖形符號區(qū) 包括
GBK/1 ： OXA1A1-A9FE ，除 GB2312 的符號外，還增補了其它符號
GBK/5 ： OXA840-A9AO ，擴除非漢字區(qū)。
* 用戶自定義區(qū)
即 GBK 區(qū)域中的空白區(qū)，用戶可以自己定義字符。
GB18030 是最新的漢字編碼字符集國家標(biāo)準(zhǔn) , 向下兼容 GBK 和 GB2312 標(biāo)準(zhǔn)。 GB18030 編碼是一二四字節(jié)變長編碼。一字節(jié)部分從 0x0~0x7F 與 ASCII 編碼兼容。二字節(jié)部分 , 首字節(jié)從 0x81~0xFE, 尾字節(jié)從 0x40~0x7E 以及 0x80~0xFE, 與 GBK 標(biāo)準(zhǔn)基本兼容。四字節(jié)部分 , 第一字節(jié)從 0x81~0xFE, 第二字節(jié)從 0x30~0x39, 第三和第四字節(jié)的范圍和前兩個字節(jié)分別相同。
不一樣的中文
中文的問題好像也解決了，且慢，新的問題又來了。
中國的臺灣省也在使用中文，但是由于歷史的原因，那里沒有使用大陸的簡體中文，還在使用著繁體的中文，并且他們自己也制定了一套表示繁體中文的字符編碼，稱為 BIG5, 不幸的是，雖然他們的也使用兩個字節(jié)來表示一個漢字，但他們沒有象我們兼容 ASCII 一樣兼容大陸的簡體中文，他們使用了大致相同的編碼范圍來表示繁體的漢字。天哪 ! ISO8859 的悲劇又出現(xiàn)在同樣使用漢字的中國人身上了，同樣的編碼在大陸和臺灣的編碼中實際上表示不同的字符，大陸的玩家在玩臺灣的游戲時，經(jīng)常會遇到亂碼的問題，問題根源就在于，大陸的計算機默認(rèn)字符的編碼就是 GB2312, 當(dāng)碰到臺灣使用 BIG5 編碼的文字時，就會作出錯誤的轉(zhuǎn)換。
由于歷史和文化的原因，日文和韓文中也包含許多的漢字，象漢字一樣擁有大量的字符，不幸的是，他們的字符編碼也同樣與中文編碼有著沖突，日文的游戲在大陸上一樣也會出現(xiàn)無法理解的亂碼?！吨形闹恰罚赌蠘O星》，《四通利方》就是用于在這些編碼中進(jìn)行識別和轉(zhuǎn)換的專用軟件。
互聯(lián)的時代
在二十世紀(jì)八十年代后期，互聯(lián)網(wǎng)出現(xiàn)了，一夜之間，地球村上的人們可以直接訪問遠(yuǎn)在天邊的服務(wù)器，電子文件在全世界傳播，在一切都在數(shù)字化的今天，文件中的數(shù)字到底代表什么字？這可真是一個問題。
UNICODE
實際上問題的根源在于我們有太多的編碼表。
如果整個地球村都使用一張統(tǒng)一的編碼表，那么每一個編碼就會有一個確定的含義，就不會有亂碼的問題出現(xiàn)了。
實際上，在 80 年代就有了一個稱為 UNICODE 的組織，這個組織制定了一個能夠覆蓋幾乎任何語言的編碼表，在 Unicode3.0.1 中就包含了 49194 個字符，將來， Unicode 中還會增加更多的字符。 Unicode 的全稱是 Universal Multiple-Octet Coded Character Set ，簡稱為 UCS 。
由于要表示的字符如此之多，所以一開始的 Unicode1.0 編碼就使用連續(xù)的兩個字節(jié)也就是一個 WORD 來表示編碼，比如 “ 漢 ” 的 UCS 編碼就是 6C49 。這樣在 Unicode 的編碼中就可以表示 256*256 = 65536 種符號了。
直接使用一個 WORD 相當(dāng)于兩個字節(jié)來保存編碼可能是最為自然的 Unicode 編碼的方式，這種方式被稱為 UCS-2 ，也被稱為 ISO 10646 ，，在這種編碼中，每一個字符使用兩個字節(jié)來進(jìn)行表示，例如， “ 中 ” 使用 11598 來編碼，而大寫字母 A 仍然使用 65 表示，但它占用了兩個字節(jié)，高位用 0 來進(jìn)行補齊。
由于每個 WORD 表示一個字符，但是在不同的計算機上，實際上對 WORD 有兩種不同的處理方式，高字節(jié)在前，或者低字節(jié)在前，為了在 UCS-2 編碼的文檔中，能夠區(qū)分到底是高字節(jié)在前，還是低字節(jié)在前，使用 UCS-2 的文檔使用了一組不可能在 UCS-2 種出現(xiàn)的組合來進(jìn)行區(qū)分，通常情況下，低字節(jié)在前，高字節(jié)在后，通過在文檔的開頭增加 FFFE 來進(jìn)行表示。高字節(jié)在前，低字節(jié)在后，稱為大頭在前，即 Big Endian ，使用 FFFE 來進(jìn)行表示。這樣，程序可以通過文檔的前兩個字節(jié)，立即判斷出該文檔是否高字節(jié)在前。
Endian 這個詞出自《格列佛游記》，小人國的內(nèi)戰(zhàn)就源于吃雞蛋時要先吃大頭 big endian 還是小頭 little-endian ，并由此發(fā)生了內(nèi)戰(zhàn)。
理想與現(xiàn)實
UCS-2 雖然理論上可以統(tǒng)一編碼，但仍然面臨著現(xiàn)實的困難。
首先， UCS-2 不能與現(xiàn)有的所有編碼兼容，現(xiàn)有的文檔和軟件必須針對 Unicode 進(jìn)行轉(zhuǎn)換才能使用。即使是英文也面臨著單字節(jié)到雙字節(jié)的轉(zhuǎn)換問題。
其次，許多國家和地區(qū)已經(jīng)以法律的形式規(guī)定了其所使用的編碼，更換為一種新的編碼不現(xiàn)實。比如在中國大陸，就規(guī)定 GB2312 是大陸軟件、硬件編碼的基礎(chǔ)。
第三，現(xiàn)在還有使用中的大量的軟件和硬件是基于單字節(jié)的編碼實現(xiàn)的， UCS-2 的雙字節(jié)表示的字符不能可靠的在其上工作。
新希望 UTF-8
為了盡可能與現(xiàn)有的軟件和硬件相適應(yīng)，美國人又制定了一系列用于傳輸和保存 Unicode 的編碼標(biāo)準(zhǔn) UTF ，這些編碼稱為 UCS 傳輸格式碼，也就是將 UCS 的編碼通過一定的轉(zhuǎn)換，來達(dá)到使用的目的。常見的有 UTF-7 ， UTF-8 ， UTF-16 等。
其中 UTF-8 編碼得到了廣泛的應(yīng)用， UTF-8 的全名是 UCS Transformation Format 8, 即 UCS 編碼的 8 位傳輸格式，就是使用單字節(jié)的方式對 UCS 進(jìn)行編碼，使 Unicode 編碼能夠在單字節(jié)的設(shè)備上正常進(jìn)行處理。
UTF-8 編碼是變長的編碼，對不同的 Unicode 可能編成不同的長度
UCS-2 UTF-8
0000-007F 0- 127 0xxxxxxx
0080-07FF 128- 2047 110xxxxx 10xxxxxx
0800-FFFF 2048-65535 1110xxxx 10xxxxxx 10xxxxxx
例如 1 的 Unicode 編碼是 31 00, 在 0-127 之間，所以轉(zhuǎn)換后即為 31 ，而 “ 中 ” 字的 UTF-8 Unicode 編碼為 11598 ，轉(zhuǎn)換成 UTF-8 則為 e4 b8 ad 。
實際上， ASCII 字符用 UTF-8 來表示后，與 ASCII 是完全一樣的，美國人又近水樓臺的把自己的問題解決了。但其他的編碼就沒有這么幸運了。
突破障礙 - Unicode 與本地編碼的轉(zhuǎn)換
UTF-8 編碼解決了字符的編碼問題，又可以在現(xiàn)有的設(shè)備上通行，因此，得到了廣泛的使用，
XML 中的問題
XML 的設(shè)計目標(biāo)是實現(xiàn)跨網(wǎng)絡(luò)，跨國界的信息表示，所以，在 XML 設(shè)計之初，就規(guī)定 XML 文件的默認(rèn)編碼格式就是 UTF-8 ，也就是說，如果沒有特殊的說明， XML 文件將被視為 UTF-8 編碼。
然而，大部分的中文編輯軟件，是根據(jù)操作系統(tǒng)來決定編碼的方式的，所以，在寫字板中直接輸入并保存的文件，將被保存為 GB2312 編碼，所以，在讀出 XML 文件內(nèi)容時，往往就會出現(xiàn)文件錯誤的提示了。這種情況會出現(xiàn)在文件中有中文出現(xiàn)的時候，如果沒有中文，只有英文信息，就不會出現(xiàn)問題。原因很簡單，有中文時，因為中文的編碼并不是 UTF-8 編碼，所以會造成沖突，沒有中文時，英文的編碼在 GB2312 中與 ASCII 是兼容的，而 ASCII 與 UTF-8 是完全一致的，所以不會出現(xiàn)問題。這種情況也包括 UltraEdit 軟件。
但時，專業(yè)的 XML 編輯軟件會自動將內(nèi)容保存為 UTF-8 編碼，不會有問題。
在通過 DOM 或 XSLT 保存 XML 文件時也有著同樣的問題。
默認(rèn)情況下， XML 的處理程序一般會將內(nèi)容作為 UTF-8 編碼進(jìn)行處理，所以保存下來的 XML 文件必須要用可以識別 UTF-8 的軟件來進(jìn)行查看，如 Windows 的記事本。
Java 的處理
Java 的設(shè)計目標(biāo)是一次編寫，到處運行，所以在 Java 的內(nèi)部對字符的處理采用了 UCS 來處理，因此 Java 的字符類型不再是 C++ 中的一個字節(jié)，而使用兩個字節(jié)來保存一個字符。
但是，我們會發(fā)現(xiàn)，在 Java 的文件流中保存為文件后，我們可以直接使用記事本或 UltraEdit 打開察看。
在這里， Java 采用了一個靈巧的默認(rèn)轉(zhuǎn)換機制，當(dāng)需要將內(nèi)容中的字符保存到文件中時， Java 會自動的查看一下系統(tǒng)的本地編碼，系統(tǒng)的本地編碼可以在控制面板中查到，然后，自動將 UCS 編碼的字符轉(zhuǎn)換為本地編碼，并進(jìn)行保存。當(dāng)需要從系統(tǒng)的文件系統(tǒng)中讀入一個文件時， Java 通過查看系統(tǒng)的本地編碼來決定如何識別文件的內(nèi)容。這樣， Java 就可以在內(nèi)部使用 UCS ，但用戶可以直接使用本地編碼的文件了。
Java 在相應(yīng)的方法中，提供了額外的參數(shù)，可以讓用戶自己來指定文件的編碼。
.Net 的處理
在微軟的 .Net 內(nèi)部，同樣使用 UCS 編碼，但是，在對文件進(jìn)行處理的時候，與 Java 有一些區(qū)別， .Net 不查詢系統(tǒng)的本地編碼，而是直接使用磨人的 UTF-8 編碼進(jìn)行文件的處理，所以，你保存的中文內(nèi)容，在 UltraEdit 中可能就是亂碼，但是，如果你使用記事本打開的話，就不會有問題，因為 Windows 的記事本可以識別 UTF-8 的編碼。
.Net 軟件的配置文件使用 XML 格式，默認(rèn)的編碼一樣是 UTF-8 ，所以，必須使用可以識別 UTF-8 的軟件進(jìn)行處理，如： vs.net ，記事本等。
在 .Net 中，網(wǎng)頁默認(rèn)處理編碼就是 UTF-8 。
Web 中的問題
網(wǎng)頁的編碼問題主要有兩點，一是網(wǎng)頁是如何編碼的，二是如何告訴瀏覽器如何編碼的。
第一個問題，又可以分成靜態(tài)頁面和動態(tài)頁面兩個問題。
對靜態(tài)頁面，網(wǎng)頁的編碼要看你保存文件時的編碼選項，多數(shù)的網(wǎng)頁編輯軟件可以讓你選擇編碼的類型，默認(rèn)為本地編碼，為了使網(wǎng)頁減少編碼的問題，最好保存為 UTF-8 編碼格式。
對動態(tài)頁面，如 Servlet 生成的頁面，在 HttpServletResponse 類中有一個方法 setContentType ，可以通過參數(shù)來指定生成的頁面的類型和編碼，例如： response.setContentType("text/html; charset=utf-8"); 來指定生成的頁面的編碼類型。
對 jsp 頁面可以通過 <%@ page contentType="text/html;charset=gb2312" %> 來指定生成的頁面的編碼及類型。
第二個問題，如何通知瀏覽器網(wǎng)頁的編碼類型。
瀏覽器收到只是一個字節(jié)流，它并不知道頁面是如何編碼的，因此，需要一個機制來告訴瀏覽器頁面的編碼類型，標(biāo)準(zhǔn)的機制是使用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 來指定頁面的編碼，當(dāng)瀏覽器讀取頁面遇到這樣的指示時，將使用這里制定的編碼方式重新加載頁面。
否則的話，瀏覽器將會試圖猜出頁面的編碼類型。
Tomcat 中的中文問題
在 Tomcat 中，經(jīng)常遇到取回客戶端提交的信息是亂碼的問題。
當(dāng)提交表單的時候， HTML 頁面的 Form 標(biāo)簽會使情況變得更為復(fù)雜。瀏覽器的編碼方式取決于當(dāng)前頁面的編碼設(shè)定，對 Form 標(biāo)簽也照此處理。這意味著如果 ASCII 格式的 HTML 頁面用 ISO-8859-1 編碼，那么用戶在此頁面中將不能提交中文字符。所以，如果你的頁面使用的是 utf-8 ，那么 POST 的時候，也將使用 utf-8 。
由于 Tomcat 是美國人設(shè)計的， Tomcat 默認(rèn)使用 ISO8859-1 編碼隊客戶端返回的內(nèi)容進(jìn)行解碼，由于編碼與內(nèi)容不一致，就會出現(xiàn)亂碼的 ??? 出現(xiàn)，根據(jù)以上的分析，在服務(wù)器端讀取客戶端回送的內(nèi)容時，需要首先設(shè)定回送內(nèi)容的編碼，然后再進(jìn)行信息的讀取，通過使用 HttpServletRequest 的方法 setCharacterEncoding("utf-8") 先行設(shè)定信息的編碼類型。然后，就可以正確讀取內(nèi)容了。
總結(jié)
編碼問題是信息處理的基本問題，但是由于歷史和政治的問題，事實上存在著大量不統(tǒng)一的編碼方式，造成在信息處理過程中的信息丟失，轉(zhuǎn)換錯誤等問題， UCS 為問題的解決提供了一個很好的方向，但是，在現(xiàn)在的軟件環(huán)境中，還沒有達(dá)到全面地使用。在實際中工作中應(yīng)盡量采用統(tǒng)一的編碼格式，減少編碼問題的發(fā)生