Unicode補完計畫
Unicode補完計畫 (Unicode-at-on) 是台灣電腦使用者針對大五碼 (Big-5) 自面世以來，字數不夠用的問題（又稱缺字問題）所採取的其中一種解決方案（參看大五碼#影響），使網民能從簡體中文或日語網站，複製網頁內的文字，原封不動的貼在裝了「Unicode補完計畫」的電腦內（具體字元請參看字元的來源）。它是一個自由軟體。
要留意的是「Unicode補完計畫」不等於 Unicode。當你看見有人說「我安裝了Unicode」，通常是他把「Unicode補完計畫」和 Unicode 搞混了。
「Unicode補完計畫」也不是用來解決軟體顯示亂碼的問題。電腦內要有相關的字形 (例如支援整個 Unicode 漢字的字形) ，才能在電腦顯示器看到。因為「Unicode補完計畫」只包含了編碼轉換表，並不包括字形在內。而一些日語遊戲裝在Windows XP所出現的亂碼問題，應使用Microsoft AppLocale內碼轉換器等程式去作內部轉換。
背景與原理
「Unicode補完計畫」的原理是把大五碼造字區的區位，和 Unicode 的相關字元作雙向對應，以達到無須借着外字集，也能使大五碼文件或檔名使用原先欠缺的漢字。
由於大五碼僅收錄13,053個漢字，對不少使用者而言確實不足夠，例如日語假名，人名、科學用的特殊字等等都欠奉。長久以來解決這種問題的方式都是加裝各種外字集，例如櫻花輸入法（支援日語假名）、中國海字集等。但目前世界的潮流是以使用包含最多字數的 Unicode 為目標。以外字集收錄字符根本難以作為資料交換之用，除非對方也安裝了該外字集。
在預設狀態下，作業系統字碼表中，大五碼造字區是和「Unicode 造字區」作雙向對應的，也就是說當電腦讀取到某個原先是落在造字區的內碼時，電腦會去讀取與其相對應的Unicode造字區字元。結果是，由於不是每人電腦內的Unicode造字區都使用同一造字檔案，所以把外字集的用字傳送給其他人時，對方若無安裝相同的外字集，就不能看到裡面的內容。
「Unicode補完計畫」試圖以修改作業系統字碼表的方式以解決問題。它把大五碼造字區的字元對應到相關的Unicode編碼。與造字不同的是，「Unicode補完計畫」讓這些字元保持了雙向流通性。在補完後的電腦上，當這些字元從大五碼轉變到 Unicode 儲存後，它們全都會被對應到正確的Unicode位置上，之後即使是對於沒有安裝補完計畫的電腦使用者，只要他的系統和程式支援 Unicode ，在讀取這些文字時，就完全沒有問題。
原理 與 一堆雜七雜八的 ... by s793016
核心原理詳述，請參閱以下網址，這是一切的根本： http://cpatch.org/unicode/tech/index.html
以下我儘量把我理解的東西寫一寫吧，我是從上面那個網址的前身 (cosdream 時代) 開始接觸這玩意的，我前後花了兩年時間自己作功課才能全盤搞懂它，我知道在看的各位俊男美女每個都比我聰明得多，如果您真有心想瞭解這個很多人稱「邪惡的東西」到底在幹嘛，應該不用像我那麼久才能懂。
這是一系列的東西，先從古早的古早說起好了。
剛開始電腦在美國出現時，美國國家標準局鑑於資訊交換的重要及為統一文字符號的編碼標準，讓不同廠牌機型的電腦皆能使用同一套標準化的信息交換碼，於是特別制定了 ASCII 碼 (America Standard Code for Information Interchange，美國資訊交換標準碼)，作為數據傳輸的標準碼。需注意的是這個標準本身只有使用 7 個位元 (0 ～ 127 用來表示英文字母、數字及其它符號) ，後來 IBM 把它加了一個位元，變成現在使用的 8 個位元，並且定義了128 ～ 255 的字符，也由於早期 x86 電腦業界幾乎可以說是 IBM 本身的奮鬥史，故這個 IBM 版的 ASCII 就變成目前電腦系統中使用最普遍也最廣泛的英文標準碼。
這部份資料可參見：
http://zh.wikipedia.org/wiki/ASCII http://zh.wikipedia.org/wiki/EASCII
微軟在 Dos 時代為了西方各國的需求，將各國的語言歸納後編號，定義了所謂的 CodePage，如：美國用的英文就是 CodePage 437，我們用的正體中文 Big5 是 CodePage 950，這個編號一直沿用至今。最初 CodePage 只是用來定義他的表中，編號 xx 的字該長怎樣，編號 yy 的字該長怎樣。
後來 Unicode 標準出現了，微軟在 Windows 3.1 時代與 Apple 合作開發了 TrueType 字型標準，就直接拿 Unicode 當作 TrueType 字型本身的「序列碼」。
什麼是「序列碼」？我們知道「字型」本身其實就是一個大圖庫，那麼他得有一個表頭去記錄他內含的哪個圖型是在編號第幾號，如此在實際取圖出來應用時才知道要取哪一個，這個紀錄表就叫「序列碼」，在 TrueType 標準中，序列碼就是該字的 Unicode 碼。雖說如此，不過微軟在 Windows 下實作抓取字型顯示的部份作了偷吃步：他把 CodePage → Unicode 的表放到 GDI 裡面，如此便可加速 TrueType 字型的取字時間。
時間再往後推，Windows 95 出現了，微軟搞了個 VFAT 標準，他跟之前的 FAT 標準最大的差異在 VFAT 支援「長檔名」，而這長檔名的儲存法是這樣的，他使用 Unicode 去存長檔名的部份，而產生的短檔名則使用各語系 Windows 本身的 CodePage 編碼去存。也因為如此，所以在 Windows 95 系統目錄下開始有了一個檔案叫作 Unicode.bin，這個檔的主要作用就是存放該 CodePage 的 CodePage → Unicode & CodePage ← Unicode 表，以讓檔案系統能正常運作。這個檔負責的 CodePage ← Unicode 轉換，遇到「無對應」的字會以「底線」顯示。
時間再往後推，到了 web browser 大戰的年代前期，微軟決定開發 IE 來跟 Netscape 對打，從 IE 4 開始，微軟為了「網路無國界」、多語顯示的需求，擴充了 CodePage 架構，把 CodePage 表中加入了 CodePage → Unicode 及 CodePage ← Unicode 兩張表，又由於微軟的戰略運用，Internet Explorer 整合了原先的 Explore，從有內建 IE 的 Windows 版本開始，微軟就一直在偷偷的用 Unicode 去代替 CodePage 了。這個檔負責的 CodePage ← Unicode 轉換，遇到「無對應」的字會以「問號」顯示。
到這裡為止，Windows 98/ME 使用的 2 個內含 CodePage ←→ Unicode 表的檔案就出線了：專管 Explore Big5 顯示的 CP_950.NLS，與檔案系統使用的 Unicode.bin。不過提到這別忘了在顯示部份還有一個抓字型圖的 GDI.EXE，他本身只有 CodePage → Unicode 的表。
Windows 2000/XP 是 NT 核心的作業系統，其內部所有的訊息都是使用 Unicode 在傳遞，微軟為了讓 2000/XP 能吃下 98 時代的眾多不支援 Unicode 舊軟體，所以會讓系統在背景無時不刻的作 CodePage ←→ Unicode 的轉換動作。換句話說，您在 Windows 系統內 (包括 98) 看到的一切，您以為那是您熟悉的 Big5，其實那些都早就被轉成 Unicode 了，只不過他以 Big5 的排列順序 出現而已。「開始」選單是這樣，檔案總管顯示的是這樣，甚至您用 IE 開啟一個 Big5 網頁，也是這樣的結果。
或許微軟本身也發覺了，在一個系統中同時使用三份相同內容的表在作不同的事，是蠻笨的作法，所以在 NT 系統下，這三個檔被整合成一個，以 Big5 而言，就是 C_950.NLS 這個檔案。
至此，Unicode 補完計畫動到的所有 Windows 系統檔，已經全部列出來了。
接下來的部份，請參閱 http://cpatch.org/unicode/tech/index.html ，我說過，這是一切的根本，而且我並無法寫的比他更容易讓人理解，所以我就不多廢話了。
至於為什麼在裝了補完後，一定要作改名才能存取原本的舊檔案，如果您搞懂 http://cpatch.org/unicode/tech/index.html 在講什麼、前面這些基礎知識您也都搞懂了，那這個問題基本上您就已經理解了。我試著再解釋看看。
前面有提到 VFAT 如何存長、短檔名了 (忘記的人請再拉回去看) ，今天假設您有一個檔叫作「あああああ.txt」，您的系統未安裝補完前，他在磁碟上的長、短檔名會是這樣 (為求方便理解，我直接列出 hex 碼)：
檔名：あああああ.txt 長檔名：F6F8F6F8F6F8F6F8F6F8002E007400780074 → Unicode 格式
然後，今天您裝了補完計畫，因為日文被我們從 Unicode 造字區改對應到 Unicode 日文區去了，如果您的應用程式是個不支援 Unicode 的程式 (如：ACDSee、Nero、Winamp) ，他在跟系統要檔名列表時，系統會先去取檔名列表回來，但是系統發現這個要求的動作不是使用支援 Unicode 的 API 來呼叫的，所以系統會在背景把取得的列表處理過再傳給應用程式，這時應用程式看到的檔名是長這樣的：
檔名：あああああ.txt 長檔名：C6E8C6E8C6E8C6E8C6E82E747874 → CodePage 格式
您可以看到，雖然該應用程式有取到長檔名，但是他的內容已經被系統自動轉碼過了，本質已經變了。如果您這時命令應用程式去操作這個檔，那麼系統會在收到應用程式要求後，再對該 CodePage 長檔名在內部作一次轉換的動作，於是最後系統會用這個檔名去操作您的檔案：
檔名：あああああ.txt 長檔名：30423042304230423042002E007400780074 → Unicode 格式
但是您磁碟上的檔名並不是上面這個，所以最終結果就會發生系統回報「找不到檔案」、「無法開啟」的錯誤訊息。
要解決這個問題，在 2K/XP 下可以透過系統提供的 Unicode API 去作改檔名的動作，讓您的舊檔名能正確對應到轉換過的 Unicode 字碼，這支程式我們也有提供，叫作 UcFileRenamer。98 下則到目前為止沒有簡單的方法可以處理這個，因為 98 下沒有 Unicode API，或許您會說微軟有提供所謂的 Unicode Layer，但那個也只是一個 Unicode API 的接收器而已，要使用它應用程式要在編譯時把它加入一起編，重點是他最後還是會把收到的 Unicode API 轉換過後，用舊系統 API 去作您要它作的事，回傳值也一樣會在內部轉換過後再傳回去應用程式手上，所以這個東西對我們的需求，根本沒用。
最後回應一下 MozTW 最近在提的，讓補完計畫只作 Big5 → Unicode 對應，而 Unicode → Big5 的對應則回歸微軟 CP950，基本上 FireFox/Mozilla 本身不會碰觸檔案系統，所以他可以這麼搞，但補完計畫並不一樣，因為補完計畫改的是系統本身在使用的 Big5 ←→ Unicode 對照表，所有跟 Unicode 有關的東西都會因此被影響到，包括上面提的「檔案操作」問題，所以補完計畫在這部份必需實作雙向對應。
作業平台
「Unicode補完計畫」修改作業系統中的字碼表，處理Unicode和非Unicode字碼的對應。「Unicode補完計畫」首先是在以 Unicode 架構為核心的微軟 Windows NT （包括 Windows 2000 和 Windows XP） 作業系統上開發，之後又支援了以 ANSI 架構為核心的 Windows 98 和 Windows Me。
Linux也有另外的使用者，開發Linux版的補完計畫。
Palm上也有另外的使用者，開發對應的補完計畫：
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
修改的檔案：
- $SYSDIR\CP_950.nls IE (檔案總管) 顯示時使用的轉碼表
- $SYSDIR\unicode.bin 負責跟檔案系統操作相關的轉碼表 (如果您有興趣可以這樣玩：把 $sysdir\unicode.bin 砍了，在重開機後，系統會使用最原始的預設 CodePage:437 顯示，在這情況下所有存在於檔名中的中文字都會以『__』顯示，這包括大部份的桌面捷徑和幾乎整個『開始』功能表)
- $SYSDIR\GDI.exe 在顯示字型時，取得字型的檔案 (將 CodePage 內碼依此檔內含之轉碼表轉換成 unicode 碼，再以此 unicode 碼到 TrueType 字型檔中提取字型)
註：$SYSDIR 是代表某路徑的一個變數，在 Windows XP 預設是 C:\WINDOWS\system32，在 Windows 2000 預設是 C:\WINNT\system32，在 Windows 98 和 Windows ME 預設是C:\WINDOWS\system。
- $WINDIR 也是一個路徑變數，在 Windows 98、 Windows ME 和 Windows XP 預設是C:\WINDOWS，Windows 2000 預設是 C:\WINNT。
字元的來源
在「Unicode補完計畫」的第2版中，字元的基本來源是參照「中國海字集」，再加上中國海字集所遺漏的簡體中文、日語等字而成。
「Unicode補完計畫」的 2.40 Alpha 3 版，除了大五碼原有的符號和漢字外，共收錄了 4,916 個漢字及漢字偏旁、日語的半形及全形假名、俄語西里爾字母等，涵蓋了在GB 2312（不是 GBK 或 GB 18030）、Shift_JIS之中出現的所有漢字，和香港增補字符集之中，Unicode碼落在 U+4E00～U+9FA5 (即 Unicode 1.1版定義) 的漢字。（因編碼空間不足的關係，並不收錄在香港增補字符集的 Unicode 擴充漢字）
使用上的問題
「Unicode補完計畫」原先的立意是避免利用造字，以達成擴充Big-5的目的：但由於Unicode環境尚未成熟，以及使用者的誤用，「Unicode補完計畫」有時反而為使用者本身──甚至其他使用者──帶來了其他的麻煩。
網頁交換
這是「Unicode補完計畫」使用者可能會影響到其他使用者的最大問題。
一般的網頁瀏覽器或電子郵件客戶端，在使用者打出了非該軟體顯示畫面預設編碼（例如寫一封用 Big-5 編碼的信件）的字元時，軟體會自動把這些字元轉換成Unicode 參照碼，例如「堃」會被自動轉換成「堃」；然而在補完後的電腦，由於即使打出的是原非大五碼預設的字元，也會被認為是大五碼的字元（裝了「Unicode補完計畫」的系統，在對照字碼表後，發現當中有這個字），因此就不會被轉換了。這也就是說，其他使用者不一定能看見該使用者所打的字──除非他們也有裝「Unicode補完計畫」。於是這反而與「Unicode補完計畫」的創立宗旨背道而馳：原先避免以外字集解決缺字的「Unicode補完計畫」，反而變成了另一套外字集。
解決方案：當使用者安裝「Unicode補完計畫」時，會獲得一份「HTML外字相容轉換器」(另外也有網路版)，可以直接把原本不屬於大五碼的字元轉換為參照碼；接下來只要使用這份夾雜着參照碼的文件，就能讓其他使用者也見到這些字元。另一種做法是，像推廣櫻花輸入法一樣推廣「Unicode補完計畫」，使其也變成一種人人使用的非官方標準。然而最終的解決方案是放棄Big-5，將網頁或信件直接改用Unicode編碼。
註：但是在原本就只有ANSI的網路環境下──例如Telnet BBS──Unicode補完計畫還是只能當外字集用。
- 此時使用者可以選擇有內建特殊字碼表的Telnet程式，如PieTTY，即無須安裝「Unicode補完計畫」。
新舊檔名
這是原櫻花輸入法使用者會面臨的問題。
在未安裝「Unicode補完計畫」的電腦，當使用者使用櫻花輸入法為檔案命名時，儲存在電腦內的檔名雖然是 Unicode 編碼，卻是在「Unicode造字區」內的字碼；而補完後的電腦，由於字碼表已被修改，這些檔案名稱在 Unicode 架構的程式的檢視下，就會變成空白；而對於 ANSI 架構的程式（例如 ACDSee、Winamp 等)，甚至會變成無法存取的亂碼。這就表示甚至連 ANSI 架構的作業系統（例如整個 Windows 98）都無法存取該檔案。另外還有一個問題：若電腦是未安裝「Unicode補完計畫」的 ANSI 架構作業系統，以上的狀況就會剛好相反（以 Unicode 架構的作業系統則無此問題）。
解決方案：Unicode補完計畫內附一個檔名轉換程式，可以把造字區檔名和 Unicode 檔名互換，但僅能在 Unicode 架構的作業系統下使用；ANSI 架構作業系統的使用者必須要手動改檔名。另一個比較有效率的作法：如果是雙系統的使用者，可以直接在 Unicode 架構的作業系統下使用改檔名程式，讓 ANSI 架構的作業系統使用。
其他問題
- Unicode補完計畫的編碼不相容於香港增補字符集的編碼，兩者只能擇其一。簡單來說，即使Unicode補完計畫與香港增補字符集均有某一個字，但因這個字在大五碼中的位置不相同，故那個字只能在 Unicode 的環境下交換，不能直接透過大五碼交換。
- Unicode補完計畫會使用到使用者造字區；也就是說如果使用者有自造字，這些字可能會不見。
- 有人表示補完計畫會讓 Internet Explorer 的自動選擇網頁編碼準確度下降，但是無法證實。
- 在安裝補完計畫後，Microsoft FrontPage 2003 會運作不正常，但是如果 FrontPage 2003 是以 Unicode 儲存網頁，就能正常運作。
- 對於不是使用系統字碼表的軟體──例如 Mozilla Firefox 等跨平台瀏覽器或 Java 軟體──補完計畫會無效，這些軟體需要「個別補完」（例如有些私編版的 Firefox，就有將補完後的字碼表編譯進去）。
- Windows 98 的細明體字形 (mingliu.ttc) 比起 Windows Me / 2000 / XP 的版本來得舊。舊版字形有不少缺字情況；使用者必須在新版 Windows 中，複製細明體去更新 Windows 98 的字形檔案。
- Windows 98 / Me 的使用者需要再安裝「中國海字集」，才能正常顯示純文字檔案。
- 由於 Windows XP Service Pack 2 改進了系統檔案保護的能力，而補完計畫需要變更一個系統檔案，故必須要在「安全模式」下，才能安裝成功。
參看
參考文件
- 「Unicode補完計畫」讀我檔案(附於安裝程式中)