總結起來為啥需要Unicodey就是為了適應全球化的發展,便於不同語言之間的兼容交互,而ASCII不再能勝任此任務了
為啥需要Unicode
我們知道計算機其實挺笨的,它只認識0101這樣的字符串,當然了我們看這樣的01串時肯定會比較頭暈的,所以很多時候為了描述簡單都用十進制,十六進制,八進制表示.實際上都是等價的,沒啥太多不一樣.其他啥文字圖片之類的其他東東計算機不認識.那為了在計算機上表示這些信息就必須轉換成一些數字.你肯定不能想怎么轉換就怎么轉,必須得有定些規則.於是剛開始的時候就有ASCII字符集(American Standard Code for Information Interchange， "美國信息交換標准碼),它使用7 bits來表示一個字符,總共表示128個字符,我們一般都是用字節(byte,即8個01串)來作為基本單位.那么怎么當用一個字節來表示字符時第一個bit總是0,剩下的七個字節就來表示實際內容.后來IBM公司在此基礎上進行了擴展，用8bit來表示一個字符，總共可以表示256個字符.也就是當第一個bit是0時仍表示之前那些常用的字符.當為1時就表示其他補充的字符.
英文字母再加一些其他標點字符之類的也不會超過256個.一個字節表示主足夠了.但其他一些文字不止這么多 ,像漢字就上萬個.於是又出現了其他各種字符集.這樣不同的字符集交換數據時就有問題了.可能你用某個數字表示字符A,但另外的字符集又是用另外一個數字表示A.這樣交互起來就麻煩了.於是就出現了Unicode和ISO這樣的組織來統一制定一個標准,任何一個字符只對應一個確定的數字.ISO取的名字叫UCS(Universal Character Set),Unicode取的名字就叫unicode了.
總結起來為啥需要Unicodey就是為了適應全球化的發展,便於不同語言之間的兼容交互,而ASCII不再能勝任此任務了.
Unicode詳細介紹
1.容易產生后歧義的兩字節
unicode的第一個版本是用兩個字節(16bit)來表示所有字符
.實際上這么說容易讓人產生歧義,我們總覺得兩個字節就代表保存在計算機中時是兩個字節.於是任何字符如果用unicode表示的話保存下來都占兩個字節.其實這種說法是錯誤的.
其實Unicode涉及到兩個步驟,首先是定義一個規范,給所有的字符指定一個唯一對應的數字,這完全是數學問題,可以跟計算機沒半毛錢關系.第二步才是怎么把字符對應的數字保存在計算機中,這才涉及到實際在計算機中占多少字節空間.
所以我們也可以這樣理解,Unicode是用0至65535之間的數字來表示所有字符.其中0至127這128個數字表示的字符仍然跟ASCII完全一樣.65536是2的16次方.這是第一步.第二步就是怎么把0至65535這些數字轉化成01串保存到計算機中.這肯定就有不同的保存方式了.於是出現了UTF(unicode transformation format),有UTF-8,UTF-16.
UTF-16比較好理解,就是任何字符對應的數字都用兩個字節來保存.我們通常對Unicode的誤解就是把Unicode與UTF-16等同了.但是很顯然如果都是英文字母這做有點浪費.明明用一個字節能表示一個字符為啥整兩個啊.
於是又有個UTF-8,這里的8非常容易誤導人,8不是指一個字節,難道一個字節表示一個字符?實際上不是.當用UTF-8時表示一個字符是可變的,有可能是用一個字節表示一個字符,也可能是兩個,三個..反正是根據字符對應的數字大小來確定.
於是UTF-8和UTF-16的優劣很容易就看出來了.如果全部英文或英文與其他文字混合,但英文占絕大部分,用UTF-8就比UTF-16節省了很多空間.而如果全部是中文這樣類似的字符或者混合字符中中文占絕大多數.UTF-16就占優勢了,可以節省很多空間.另外還有個容錯問題,等會再講
看的有點暈了吧,舉個例子.假如中文字"漢"對應的unicode是6C49(這是用十六進制表示,用十進制表示是27721為啥不用十進制表示呢?很明顯用十六進制表示要短點.其實都是等價的沒啥不一樣.就跟你說60分鍾和1小時一樣.).你可能會問當用程序打開一個文件時我們怎么知道那是用的UTF-8還是UTF-16啊.自然會有點啥標志,在文件的開頭幾個字節就是標志.
EF BB BF 表示UTF-8
FE FF 或者 FF FE 表示UTF-16.
用UTF-16表示"漢"
假如用UTF-16表示的話就是01101100 01001001(共16 bit,兩個字節).程序解析的時候知道是UTF-16就把兩個字節當成一個單元來解析.這個很簡單.
用UTF-8表示"漢"
用UTF-8就有復雜點.因為此時程序是把一個字節一個字節的來讀取,然后再根據字節中開頭的bit標志來識別是該把1個還是兩個或三個字節做為一個單元來處理.
0xxxxxxx,如果是這樣的01串,也就是以0開頭后面是啥就不用管了XX代表任意bit.就表示把一個字節做為一個單元.就跟ASCII完全一樣.
110xxxxx 10xxxxxx.如果是這樣的格式,則把兩個字節當一個單元
1110xxxx 10xxxxxx 10xxxxxx 如果是這種格式則是三個字節當一個單元.
這是約定的規則.你用UTF-8來表示時必須遵守這樣的規則.我們知道UTF-16不需要用啥字符來做標志,所以兩字節也就是2的16次能表示65536個字符.
而UTF-8由於里面有額外的標志信息,所有一個字節只能表示2的7次方128個字符,兩個字節只能表示2的11次方2048個字符.而三個字節能表示2的16次方,65536個字符.
由於"漢"的編碼27721大於2048了所有兩個字節還不夠,只能用三個字節來表示.
所有要用1110xxxx 10xxxxxx 10xxxxxx這種格式.把27721對應的二進制從左到右填充XXX符號(實際上不一定從左到右,也可以從右到左,這是涉及到另外一個問題.等會說.
剛說到填充方式可以不一樣,於是就出現了Big-Endian,Little-Endian的術語.Big-Endian就是從左到右,Little-Endian是從右到左.
由上面我們可以看出UTF-8在局部的字節錯誤（丟失、增加、改變）不會導致連鎖性的錯誤，因為 UTF-8 的字符邊界很容易檢測出來，所以容錯性較高。
Unicode版本2
前面說的都是unicode的第一個版本.但65536顯然不算太多的數字,用它來表示常用的字符是沒一點問題.足夠了,但如果加上很多特殊的就也不夠了.於是從1996年開始又來了第二個版本.用四個字節表示所有字符.這樣就出現了UTF-8,UTF16,UTF-32.原理和之前肯定是完全一樣的,UTF-32就是把所有的字符都用32bit也就是4個字節來表示.然后UTF-8,UTF-16就視情況而定了.UTF-8可以選擇1至8個字節中的任一個來表示.而UTF-16只能是選兩字節或四字節..由於unicode版本2的原理完全是一樣的,就不多說了.
前面說了要知道具體是哪種編碼方式,需要判斷文本開頭的標志,下面是所有編碼對應的開頭標志
EF BB BF UTF-8
FE FF UTF-16/UCS-2, big endian
FF FE UTF-16/UCS-2, little endian
FF FE 00 00 UTF-32/UCS-4, little endian.
00 00 FE FF UTF-32/UCS-4, big-endian.
其中的UCS就是前面說的ISO制定的標准,和Unicode是完全一樣的,只不過名字不一樣.ucs-2對應utf-16,ucs-4對應UTF-32.UTF-8是沒有對應的UCS
UTF-16 並不是一個完美的選擇，它存在幾個方面的問題：
- UTF-16 能表示的字符數有 6 萬多，看起來很多，但是實際上目前 Unicode 5.0 收錄的字符已經達到 99024 個字符，早已超過 UTF-16 的存儲范圍；這直接導致 UTF-16 地位頗為尷尬——如果誰還在想着只要使用 UTF-16 就可以高枕無憂的話，恐怕要失望了
- UTF-16 存在大小端字節序問題，這個問題在進行信息交換時特別突出——如果字節序未協商好，將導致亂碼；如果協商好，但是雙方一個采用大端一個采用小端，則必然有一方要進行大小端轉換，性能損失不可避免（大小端問題其實不像看起來那么簡單，有時會涉及硬件、操作系統、上層軟件多個層次，可能會進行多次轉換）
- 另外，容錯性低有時候也是一大問題——局部的字節錯誤，特別是丟失或增加可能導致所有后續字符全部錯亂，錯亂后要想恢復，可能很簡單，也可能會非常困難。（這一點在日常生活里大家感覺似乎無關緊要，但是在很多特殊環境下卻是巨大的缺陷）
反過來 UTF-8 也不完美，也存在一些問題：
- 文化上的不平衡——對於歐美地區一些以英語為母語的國家 UTF-8 簡直是太棒了，因為它和 ASCII 一樣，一個字符只占一個字節，沒有任何額外的存儲負擔；但是對於中日韓等國家來說，UTF-8 實在是太冗余，一個字符竟然要占用 3多個字節，存儲和傳輸的效率不但沒有提升，反而下降了。所以歐美人民常常毫不猶豫的采用 UTF-8，而我們卻老是要猶豫一會兒
- 變長字節表示帶來的效率問題——大家對 UTF-8 疑慮重重的一個問題就是在於其因為是變長字節表示，因此無論是計算字符數，還是執行索引操作效率都不高。為了解決這個問題，常常會考慮把 UTF-8 先轉換為 UTF-16 或者 UTF-32 后再操作，操作完畢后再轉換回去。而這顯然是一種性能負擔。
當然，UTF-8 的優點也不能忘了：
- 字符空間足夠大，未來 Unicode 新標准收錄更多字符，UTF-8 也能妥妥的兼容，因此不會再出現 UTF-16 那樣的尷尬
- 不存在大小端字節序問題，信息交換時非常便捷
- 容錯性高，局部的字節錯誤（丟失、增加、改變）不會導致連鎖性的錯誤，因為 UTF-8 的字符邊界很容易檢測出來，這是一個巨大的優點（正是為了實現這一點，咱們中日韓人民不得不忍受 3 字節 1 個字符的苦日子）
那么到底該如何選擇呢？
因為無論是 UTF-8 和 UTF-16/32 都各有優缺點，因此選擇的時候應當立足於實際的應用場景。例如在我的習慣中，存儲在磁盤上或進行網絡交換時都會采用 UTF-8，而在程序內部進行處理時則轉換為 UTF-16/32。對於大多數簡單的程序來說，這樣做既可以保證信息交換時容易實現相互兼容，同時在內部處理時會比較簡單，性能也還算不錯。（基本上只要你的程序不是 I/O 密集型的都可以這么干，當然這只是我粗淺的認識范圍內的經驗，很可能會被無情的反駁）
稍微再展開那么一點點……
在一些特殊的領域，字符編碼的選擇會成為一個很關鍵的問題。特別是一些高性能網絡處理程序里更是如此。這時采用一些特殊的設計技巧，可以緩解性能和字符集選擇之間的矛盾。例如對於內容檢測/過濾系統，需要面對任何可能的字符編碼，這時如果還采用把各種不同的編碼都轉換為同一種編碼后再處理的方案，那么性能下降將會很顯著。而如果采用多字符編碼支持的有限狀態機方案，則既能夠無需轉換編碼，同時又能夠以極高的性能進行處理。當然如何從規則列表生成有限狀態機，如何使得有限狀態機支持多編碼，以及這將帶來哪些限制，已經又成了另外的問題了。