IT中文環境的血淚史(1)作業系統、編程語言、應用亂碼

身為一個中文電腦使用者，我有過太多的無奈，這些無奈是西方人無法體會的。大多數知名的編程語言、作業系統、應用軟體，都是西方人開發的，他們往往一開始的時候不會把中日韓（CJK）的語言需求當一回事。

作業系統
二十多年前，為了要讓電腦具有快速的「正體」中文環境，每次開機後都必須插入中文磁片，花一段時間安裝倚天中文（或大千、零壹、天龍中文），而且都是16或24的點陣字型（bitmap font），只要把字放大，就其醜無比。為了要加速中文的載入與顯示，必須安裝超貴的倚天中文卡，而早期的倚天中文卡只能使用在單色模式。當時，歐美的電腦使用者，根本不需要這麼麻煩，人家開機後就可以直接用電腦了，令我們感到羨慕。

後來Windows 3.x時代，可以方便地使用中文，但是檔案名稱不能使用中文，進入Windows 95之後才解除此限制，微軟平臺上的中文問題也漸漸變得比較少了。但其他平臺還是存在這個問題，Linux一開始不支援雙位元語言，BeOS也不支援中文，我們必須用一些奇門遁甲的方式，辛苦地讓這些OS上面顯示中文。當中文顯示出來的剎那，感動得都快掉淚了。

正體中文的編碼最常用的是Big-5，這是一種雙位元組字元集（Double-Byte Character Set，DBCS），但是不同平臺的Big-5字集還不太一樣。當我把在Windows平臺上寫好的文章交給MacOS的排版人員，最後一定要仔細校對排版後的輸出。因為兩者的Big-5字集有些小差異，所以有些中文字可能會不一樣。

編程語言
經過這段時間大家的努力，現在，至少主流的OS都不會有中文的問題了。但是程式環境可不見得如此，正體中文版Windows上使用CP950編碼，這是混合Big-5和ASCII的變動長度編碼方式。對於這種變動長度的編碼方式，如果程式環境沒有特別處理，常常會發生問題。著名的「許、功、蓋」問題就是如此，這幾個中文字的第二個位元組都是ASCII的反斜線（\），剛好是某些程式語言的特殊字元，或者脫字序列（Escape Sequence）字元，所以會出現問題，根據這樣來推估，還有相當多字都會出問題，包括「廄、琵、崤、淚、豹」。

不同的程式環境可能會有不同的特殊字元。甲語言出問題的可能是「許、功、蓋」，乙語言出問題的可能是「扁、夏、抬」，所以每個語言必須用不同的方式處理特殊字元的問題。

幸好我們開始有Unicode，早期的Unicode是16位元的，後來又擴充到32位元。許多號稱支援Unicode的平臺，其實並沒有100%支援Unicode。至少在Windows上，當我測試Unicode的中文組字功能時，發現是行不通的。例如：「2FF1 4E95 86D9」無法呈現正確組合出來的1個中文字，而是3個中文字。這是因為Windows API的TextOut() 函式與DrawText() 函式（以及相關函式）沒有處理中文組字。
Java雖然一開始就支援Unicode，但是前幾年在AWT/Swing上顯示的中文很不美觀，程式設計上也會遇到一些問題。我就常常收到讀者的E-mail，詢問如何在Java上解決特定的中文問題。這幾年下來，這些問題似乎在Java上都已經漸漸消失了。.NET平臺上的語言對於DBCS與Unicode的支援也不錯。但是Java和.NET畢竟都是跨國大公司的產品，所以有考慮到DBCS與Unicode，是很自然的。Ruby就比較特別了，由於Ruby是日本人設計的編程語言，所以Ruby一開始就有考慮到東亞的語言。

應用軟體與中文亂碼
平臺有支援中文，編程語言相容於中文，但開發出來的應用程式卻不見得如此，所以有的應用程式只要遇到中文，一律變成亂碼，但是這樣的例子已經越來越少了。

之所以會看到亂碼，就是「編碼」和「解碼」的方式不同所造成的。比方說，用DBCS的中文編碼，卻用ASCII解碼，把每個中文字當作兩個「擴充ASCII」字元顯示；或者，把簡體中文GB2312編碼的內容，當作正體中文Big-5解碼顯示，當然會看到不知所云的內容。

就算程式支援多種編碼，也會因為收到的內容沒有標示編碼，而造成解碼錯誤。我的Office 2003收件匣，只要收到簡體中文標題的郵件，標題就會呈現亂碼。沒想到幾個月後，我養成一種功力，我可以從郵件標題的中文亂碼解讀出簡體中文一些常用詞彙。比方說，當我看到郵件標題為「絆珂汜斕疑」，我就知道其實這幾個正體中文字編碼對應到簡體中文是「蔡先生你好」。我考慮把這項了不起的「閱讀亂碼」才華加入我的履歷表中。

蔡學鏞－專職作家
清華大學資訊工程碩士，曾任華碩集團軟體工程師、元智大學資訊系講師、美商歐萊禮出版社技術編輯、臺灣微軟特約專欄作家。