Unicode, UTF-8, UTF-16, UTF-32

Unicode是字符集,給每個字符一個唯一的編碼,目前的版本用4個字節(jié)表示所有的字符。
UTF是 unicode transformation format,是把字符保存到計算機上的格式。
UTF-8是變長的
UTF-16是2或4個字節(jié)
UTF-32是4個字節(jié)

要知道具體是哪種編碼方式,需要判斷文本開頭的標志,下面是所有編碼對應的開頭標志

EF BB BF    UTF-8
FE FF     UTF-16/UCS-2, little endian
FF FE     UTF-16/UCS-2, big 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-8的優(yōu)點:

  1. 字符空間足夠大,未來 Unicode 新標準收錄更多字符,UTF-8 也能妥妥的兼容,因此不會再出現(xiàn) UTF-16 那樣的尷尬
  2. 不存在大小端字節(jié)序問題,信息交換時非常便捷
  3. 容錯性高,局部的字節(jié)錯誤(丟失、增加、改變)不會導致連鎖性的錯誤,因為 UTF-8 的字符邊界很容易檢測出來,這是一個巨大的優(yōu)點(正是為了實現(xiàn)這一點,咱們中日韓人民不得不忍受 3 字節(jié) 1 個字符的苦日子)

UTF-8的缺點:

  1. 文化上的不平衡——對于歐美地區(qū)一些以英語為母語的國家 UTF-8 簡直是太棒了,因為它和 ASCII 一樣,一個字符只占一個字節(jié),沒有任何額外的存儲負擔;但是對于中日韓等國家來說,UTF-8 實在是太冗余,一個字符竟然要占用 3 個字節(jié),存儲和傳輸?shù)男什坏珱]有提升,反而下降了。所以歐美人民常常毫不猶豫的采用 UTF-8,而我們卻老是要猶豫一會兒
  2. 變長字節(jié)表示帶來的效率問題——大家對 UTF-8 疑慮重重的一個問題就是在于其因為是變長字節(jié)表示,因此無論是計算字符數(shù),還是執(zhí)行索引操作效率都不高。為了解決這個問題,常常會考慮把 UTF-8 先轉(zhuǎn)換為 UTF-16 或者 UTF-32 后再操作,操作完畢后再轉(zhuǎn)換回去。而這顯然是一種性能負擔。

UTF-16的缺點:

  1. UTF-16 能表示的字符數(shù)有 6 萬多,看起來很多,但是實際上目前 Unicode 5.0 收錄的字符已經(jīng)達到 99024 個字符,早已超過 UTF-16 的存儲范圍;這直接導致 UTF-16 地位頗為尷尬——如果誰還在想著只要使用 UTF-16 就可以高枕無憂的話,恐怕要失望了
  2. UTF-16 存在大小端字節(jié)序問題,這個問題在進行信息交換時特別突出——如果字節(jié)序未協(xié)商好,將導致亂碼;如果協(xié)商好,但是雙方一個采用大端一個采用小端,則必然有一方要進行大小端轉(zhuǎn)換,性能損失不可避免(大小端問題其實不像看起來那么簡單,有時會涉及硬件、操作系統(tǒng)、上層軟件多個層次,可能會進行多次轉(zhuǎn)換)
  3. 另外,容錯性低有時候也是一大問題——局部的字節(jié)錯誤,特別是丟失或增加可能導致所有后續(xù)字符全部錯亂,錯亂后要想恢復,可能很簡單,也可能會非常困難。(這一點在日常生活里大家感覺似乎無關緊要,但是在很多特殊環(huán)境下卻是巨大的缺陷)
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

友情鏈接更多精彩內(nèi)容