字元編碼與程式設計(六)：Unicode的發展－伊蜜澤瑞

雖然Unicode在1991年就已問世，但由於一般人不能體會Unicode的重要性，加上習慣與惰性以及一大堆以傳統編碼為基礎的軟體已經存在，因此Unicode的推動並不順利。

直到網際網路的快速發展，國際間出現大量訊息交換的需求，廣大的人民才開始體認到傳統編碼系統的侷限性。雖然世界上的個人電腦作業系統以Windows為大宗，而微軟又從1993年的Windows NT 3.1開始採用基於Unicode的核心，卻由於當時家用電腦以Windows 95/98為主流，以至於一般人民要到2001年的Windows XP問世後才開始真正接觸到Unicode的世界。此時雖然作業系統已支援Unicode，卻由於大量既有工具的存在，使得Unicode並未真正進入一般人的生活；加上程式人員必須學習新的Unicode程式設計方法，並使用新的架構寫作程式(Windows採用UTF-16)才能使其程式支援新的Unicode特性，因此許多的程式人又選擇徘徊在傳統編碼基礎下開發新程式。直到現在，仍然有很高的機率見到新發佈的程式軟體是架構在傳統編碼系統下開發的。總結從Unicode誕生到世人真正開始大量接觸，前後相差了約15年，Windows體系的使用者甚至現在仍可能活在半傳統編碼、半Unicode的世界。

由於歷史的因素，Windows系統及其系列軟體使用了UTF-16LE為其編碼系統(Windows投入Unicode技術時還沒有UTF-8)。因此，Windows體系下的程式人員常被教育並擁有以下認知(即使該認知可能並不正確)：

Unicode就是以兩個位元組編碼文字的編碼系統。
Unicode等於寬字元、寬字元等於Unicode。
要進入Unicode的世界需要學習並使用與現在全然不同的概念重新編寫軟體、以及與這個軟體相關的週邊軟體，工程浩大。
通常近代的Windows程式發佈都會有兩種版本：傳統字碼版(被稱為ANSI版，雖然和ANSI沒有什麼關係)、以及Unicode版(或寬字元版)。
凡是沒有發佈寬字元版本的軟體或程式庫都是不支援Unicode的軟體。
因為寫Unicode的程式比較麻煩，因此一些小專案、小軟體、或成本較低的軟體專案只建構在傳統字碼系統上是很正常也很合理的。

而在自由世界裡，其實我也不知道是什麼原因，是因為自由世界的人比較勤奮嗎？還是踏進Unicode的時間比較晚？總之自由世界的軟體普遍採用UTF-8做為Unicode的編碼方法，因此程式人不需要以新的觀念和方法重寫程式(除非你是負責寫字元顯示與分析相關模組或是文字編輯器的人)，甚至在程式碼內絕大部分對於字串的處理、分析、搜尋等等處理與原來並無任何不同。因此Unicode在自由世界的發展非常迅速而完整，自由世界的程式人員常常具有下列認知(雖然有些也不正確或過於誇大)：

Unicode就是用一個位元組為單位的編碼系統。
什麼寬字元窄字元？我從來不用寬字元的！
支援Unicode？我不清楚為什麼要特別提起這個規格，如果有軟體不支援Unicode的話才需要特別提起吧！
不，軟體發佈並不需要區分Unicode版或傳統編碼版，我們的軟體發佈只有一個版本，就是Unicode版(雖然Windows程式人可能會認為這是傳統編碼版)。
你不要再給我傳統多語系編碼檔案了！我的電腦裡已經沒有傳統編碼檔案，所有的軟體都使用Unicode，遇到傳統編碼檔案意味著需要特別轉換處理、意味著麻煩和低效。

上面的說明有些有點誇張，然而有些並不誇張。我不清楚自由世界踏入Unicode是否真的比較晚，但Unicode在自由世界的發展非常快速，在很短的時間內整個系統包含各方的應用軟體(有些根本就沒有影響)便能夠完善支援Unicode。以Red Hat為例(抱歉Linux版本太多，我只舉這個剛好查到資料的做例子)，從2002年發佈的Red Hat Linux 8.0開始，系統預設編碼更改為UTF-8。這個意思就是從此開始系統不再假設你的電腦裡可能存在各種不同語系的傳統編碼檔案，一律以UTF-8視之，而這可能就是自由世界之所以主張UTF-8不應該加BOM的最有力因素。

基本上目前在自由世界已經很難再見到傳統的多語系編碼文字，因此軟體程式們對於一份文字檔案通常不管三七二十一直接就把它當UTF-8來解析了，頂多有一些比較複雜的文字編輯器可能會檢查檔案開頭是否有BOM記號再決定解析方式。因此對於大部分的程式而言並不存在有「識別一份文字資料是不是具有UTF-8特徵」這樣的效率問題，若真的遇到屬於傳統文字編碼的「特例」，則由使用者以個案方式手動處理。

由於在網際網路的應用上，UTF-8擁有的諸多優點贏得了網路開發者的愛好，如不會像UTF-16在文字分析等場合容易被斷字的問題、以及節省網路傳輸流量的特性(雖然中文一字佔用3個位元組，但是網頁資料中比例不低的網頁標籤等訊息全都屬於ASCII的範圍)等，使得網際網路的應用成為UTF-8的天下。

綜和說明以上的情況，當前的狀況是UTF-8有著漸漸統一Unicode編碼世界的趨勢，和而部份基於歷史因素選用UTF-16的軟體(如Windows)成兩方對峙。至於UTF-32幾乎沒有應用的領域，作者我還沒有見到市面上有使用或是良好支援這種編碼的軟體。

然而不能因為這樣我們就輕易的下UTF-16會消失的結論，雖然UTF-16使用最凶最廣的就是Windows系列軟體，但是這些軟體卻也擁有為數不少的用戶，光Windows系統就佔了桌面用戶的八九成。基於上述的編碼競爭，加上在UTF-16和傳統編碼混合式環境下開發Unicode程式仍不容易，因此作者我判斷在可遇見的未來UTF-16和UTF-8將繼續互相競爭(雖然我覺得UTF-8更佔優勢)，而傳統多語系的編碼仍然會在兩大勢力夾擊的狹縫中在Windows下取得一塊不可被忽視的小空間。