其實這個問題答起來就那麼幾個眾所周知的點，大家都提到了。我狗尾續貂稍微展開一點。
UTF-16 並不是一個完美的選擇，它存在幾個方面的問題：
- UTF-16 能表示的字符數有6 萬多，看起來很多，但是實際上目前Unicode 5.0 收錄的字符已經達到99024 個字符，早已超過UTF-16 的存儲範圍；這直接導致UTF-16 地位頗為尷尬——如果誰還在想著只要使用UTF-16 就可以高枕無憂的話，恐怕要失望了
- UTF-16 存在大小端字節序問題，這個問題在進行信息交換時特別突出——如果字節序未協商好，將導致亂碼；如果協商好，但是雙方一個採用大端一個採用小端，則必然有一方要進行大小端轉換，性能損失不可避免（大小端問題其實不像看起來那麼簡單，有時會涉及硬件、操作系統、上層軟件多個層次，可能會進行多次轉換）
- 另外，容錯性低有時候也是一大問題——局部的字節錯誤，特別是丟失或增加可能導致所有後續字符全部錯亂，錯亂後要想恢復，可能很簡單，也可能會非常困難。 （這一點在日常生活里大家感覺似乎無關緊要，但是在很多特殊環境下卻是巨大的缺陷）
目前支撐我們繼續使用UTF-16 的理由主要是考慮到它是雙字節的，在計算字符串長度、執行索引操作時速度很快。當然這些優點UTF-32 都具有，但很多人畢竟還是覺得UTF-32 太佔空間了。
反過來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 密集型的都可以這麼幹，當然這只是我粗淺的認識範圍內的經驗，很可能會被無情的反駁）
稍微再展開那麼一點點……
在一些特殊的領域，字符編碼的選擇會成為一個很關鍵的問題。特別是一些高性能網絡處理程序裡更是如此。這時採用一些特殊的設計技巧，可以緩解性能和字符集選擇之間的矛盾。例如對於內容檢測/過濾系統，需要面對任何可能的字符編碼，這時如果還採用把各種不同的編碼都轉換為同一種編碼後再處理的方案，那麼性能下降將會很顯著。而如果採用多字符編碼支持的有限狀態機方案，則既能夠無需轉換編碼，同時又能夠以極高的性能進行處理。當然如何從規則列表生成有限狀態機，如何使得有限狀態機支持多編碼，以及這將帶來哪些限制，已經又成了另外的問題了。
我就是隨便這麼一展開而已
沒有留言:
發佈留言