Unicode補完計畫

Unicode補完計畫(Unicode-At-On)是台灣民間使用者針對Big-5編碼長久以來的缺字問題所提出的解決方案之一。其原理在於將Big-5造字區的一部份和Unicode的部分字元作雙向對應，以達到不藉助外字集，而使Big-5文件或檔名能使用原先僅在Unicode中存在的文字之目的。

「Unicode補完計畫」不是用來解決軟體顯示亂碼的問題。這是南極星、譯典通多語瀏覽功能、Microsoft Applocale內碼轉換器等程式的功能。

「Unicode補完計畫」不等於Unicode。當你看見有人說「我安裝了Unicode」，通常是他把「Unicode補完計畫」和Unicode搞混了。

原理

Big-5僅收錄了13,053個中文字，這對某些使用者而言確實是不足：例如日文假名，人名、科學用的特殊字等等。長久以來解決這種問題的方式都是加裝各種外字集，例如櫻花輸入法、中國海字集等等；但目前世界的潮流是以全面Unicode化為目標，以外字集根本難以作為資料交換之用，除非對方也安裝了該外字集。

Unicode補完計畫試著以修改字碼表的方式解決這個問題。在作業系統中內定有數份字碼表，處理Unicode和非Unicode字碼的對應。在預設狀態下，Big-5的造字區是和Unicode的造字區作雙向對應的，也就是說當電腦讀取到某個原先是落在造字區的內碼時，電腦會去讀取與其相對應的Unicode字元；而換上Unicode補完計畫修改過的字碼表後，Big-5的造字區改成和Unicode的特定字元作雙向對應。結果是，在補完前這個字是空白的(Unicode的造字區)，所以使用者會看到空白的字；補完後這個字則是Unicode的某字元，所以使用者看到的就是那個字元。

和造字不同的是，Unicode補完計畫讓這些字元保持了流通性：在補完後的電腦上，當這些字元從Big-5轉移到Unicode時，它們全都會被對應回正確的Unicode位置，之後即使是未補完電腦的使用者，只要他的系統與程式支援Unicode，在讀取這些文字時，就完全沒有問題。

作業平台

Unicode補完計畫主要是開發在核心為Unicode架構的Windows作業系統上，之後又支援ANSI架構的Windows。

Linux上也有另外的使用者，開發Linux版的補完計畫[1]。

Unicode架構的Windows

包括Windows 2000、Windows XP、Windows Server 2003，與未來的Windows系列。

修改的檔案：

$SYSDIR\C_950.nls Unicode<=>Big-5對照表
如果使用者有安裝Microsoft Applocale，安裝程式會將$WINDIR\AppPatch\AppLoc.tmp以一個同名的空白唯讀檔案取代。
如果使用者沒有安裝Microsoft Applocale，安裝程式會直接產生一個空白的唯讀檔案: $WINDIR\AppPatch\AppLoc.tmp。

ANSI架構的Windows

包括Windows 98、Windows ME。

修改的檔案：

$SYSDIR\Cp_950.nls 檔案總管顯示檔案時用的轉碼表
$SYSDIR\unicode.bin 負責輸出/輸入的轉碼表
$SYSDIR\GDI.exe 在顯示字型時，取得字型的檔案

註：$SYSDIR是代表某路徑的一個變數，在WinXP預設是C:\WINDOWS\system32，在Win98預設是C:\WINDOWS\system。

$WINDIR也是一個路徑變數，在WinXP預設是C:\WINDOWS。

完成度

Unicode補完計畫的基本對應參考是「中國海字集」，加上部分「香港增補字符集」的字元而成。

目前完成對應的字元(2.40 Alpha 3)共約5300個，茲摘錄重點如下：

日文假名字(使得Unicode補完計畫可以替代櫻花輸入法)；
所有出現於GB2312的漢字；
所有出現於Shift JIS的漢字；
「香港增補字符集」中，Unicode碼落在U+4E00～U+9FFF內的所有漢字。

使用上的問題

「Unicode補完計畫」原先的立意是避免利用造字，以達成擴充Big-5的目的：但由於Unicode環境尚未成熟，以及使用者的誤用，Unicode補完計畫有時反而為使用者本身--甚至其他使用者--帶來了其他的麻煩。

網頁交換

這是Unicode補完計畫使用者可能會影響到其他使用者的最大問題。

一般的網頁瀏覽器或電子郵件客戶端，在使用者打出了非該軟體顯示畫面預設編碼(例如寫一封用Big-5編碼的信件)的字元時，軟體會自動將這些字元轉換成Unicode參照碼，例如「堃」會被轉換成「堃」；然而在補完後的電腦，由於即使打出的是非原Big-5預設的字元，也會被認為是Big-5的字元(電腦參考補完後的Big-5字碼表，發現其中有這個字)，因此就不會被轉換了。這也就是說，其他使用者不一定能看見該使用者所打的字--除非他們也有裝Unicode補完計畫。於是這反而與Unicode補完計畫的創立宗旨背道而馳：原先避免以外字集解決缺字的Unicode補完計畫，反而變成了另一套外字集。

解決方案：當使用者安裝「Unicode補完計畫」時，會獲得一份「HTML外字相容轉換器」，可以直接將原本不屬於Big-5的字元轉換為參照碼；接下來只要使用這份參雜著參照碼的文件，就能讓其他使用者也能見到這些字元。另一種作法是，像推廣櫻花輸入法一樣推廣「Unicode補完計畫」，使其也能變成一種非官方的標準。然而最終的解決方案是放棄Big-5，將網頁或信件直接改用Unicode編碼。

註：但是在原本就只有ANSI的網路環境下--例如Telnet BBS--Unicode補完計畫還是只能當外字集用。

此時使用者可以選擇有內建特殊字碼表的Telnet程式，如PieTTY，即不需安裝Unicode補完計畫。

新舊檔名

這是原櫻花輸入法使用者會面臨的問題。

在補完前的電腦，當使用者使用櫻花輸入法為檔案命名時，儲存在電腦內的檔名雖然是Unicode編碼，卻是在「Unicode造字區」內的字碼；而補完後的電腦，由於字碼表已被修改，這些檔案名稱在Unicode架構的程式的檢視下，就會變成空白；而對於ANSI架構的程式(例如ACDSee、Winamp等等)，甚至會變成無法存取的亂碼。這就表示甚至連ANSI架構的作業系統(例如整個Windows 98)都無法存取該檔案。另外還有一個問題：若電腦是未補完版的ANSI架構作業系統，以上的狀況就會剛好相反(Unicode架構的作業系統則無此問題)。

解決方案：Unicode補完計畫內附一個檔名轉換程式，可以將造字區檔名和Unicode檔名互轉，但僅能在Unicode架構的作業系統下使用；ANSI架構作業系統的使用者必須要手動改檔名。另一個比較有效率的作法：如果是雙系統的使用者，可以直接在Unicode架構的作業系統下使用改檔名程式，讓ANSI架構的作業系統使用。

其他問題

Unicode補完計畫不相容於香港增補字符集，兩者只能擇一。
Unicode補完計畫會使用到使用者造字區；也就是說如果使用者有自造字，這些字可能會不見。
有人表示補完計畫會讓Internet Explorer的自動選擇網頁編碼準確度下降，但是無法證實。
在安裝補完計畫後，Microsoft FrontPage會運作不正常；但是如果FrontPage是以Unicode儲存網頁，就能正常運作。
對於不是使用系統字碼表的軟體--例如Mozilla Firefox等跨平台瀏覽器--補完計畫會無效，這些軟體需要「個別補完」(例如有些私編版的Firefox，就有將補完後的字碼表編譯進去)。
Windows98/ME的細明體字型(mingliu.ttc)比起Windows2000/XP的版本來得舊，這些舊版字型有不少缺字情形；使用者必須自行更新這些字型。
Windows98/ME的使用者需要再安裝「中國海字集」，才能正常顯示純文字檔案。
由於Windows XP Service Pack2改進了系統檔案保護的能力，而補完計畫需要變更一個系統檔案，故必須要在「安全模式」下，才能安裝成功。

參考文件

Unicode補完計畫讀我檔案(附於安裝程式中)

外部連結

「Unicode補完計畫」官方網站(目前停止運作中)