【Unicode补完计划】
Unicode补完计划（Unicode-at-on，简称UAO，官方网站使用的识别系统用字是Unicode补完计-{画}-）是台湾电脑使用者针对大五码（Big-5）延伸的紊乱、以及微软Code Page 950（Microsoft Windows内建的Big-5转码表）未收录某些常用字（又称缺字问题）以及缺乏对于倚天中文系统、中国海字集延伸中的简体中文、日文假名与日文汉字支援等问题所采取的其中一种解决方案（参看大五码#影响）。透过对Code Page 950的修改，使得原始采用简体中文或日语的内容，在复制至ANSI架构的程式时能转换为Unicode补完计划字集下的对应字元，而不会造成缺字的问题（详细字元请参看字元的来源）。它是一个自由软体。
除了系统支援，使用者亦需安装相关字型才可正确显示文字。
要留意的是「Unicode补完计划」不等于Unicode。当有人说「我已安装Unicode」，通常是将「Unicode补完计划」和Unicode混为一谈。
「Unicode补完计划」也不是用来解决软体显示乱码的问题。电脑内要有相关的字型（例如支援整个Unicode汉字的字型），才能在电脑显示器看到。因为「Unicode补完计划」只包含编码转换表，并不包括字型在内。而有些日语程式装在Windows XP所出现的乱码问题，应使用Microsoft AppLocale等程式去作内部转换。
== 背景与原理 ==
「Unicode补完计划」的原理是把大五码造字区的区位和Unicode的相关字元作双向对应，以达到无须借助外字集、也能使大五码文件或档名使用原先欠缺的汉字。
由于大五码仅收录13,060个汉字，对不少使用者而言确实不足够，例如日语假名、人名、香港粤语字、科学用的特殊字等等都欠缺。长久以来解决这种问题的方式都是加装各种外字集，例如樱花输入法（支援日语假名）、中国海字集、香港增补字符集（HKSCS）等。但目前世界的潮流是以使用包含最多字数的Unicode为目标。以外字集收录字符根本难以作为资料交换之用，除非对方也安装了该外字集。
在预设状态下，作业系统字码表中，大五码造字区是和「Unicode造字区」作双向对应的，也就是说当电脑读取到某个原先是落在造字区的内码时，电脑会去读取与其相对应的Unicode造字区字元。结果是，由于不是每人电脑内的Unicode造字区都使用同一造字档案，所以把外字集的用字传送给其他人时，对方若无安装相同的外字集，就不能看到里面的内容。
「Unicode补完计划」试图以修改作业系统字码表的方式以解决问题。它把大五码造字区的字元对应到相关的Unicode编码。与造字不同的是，「Unicode补完计划」让这些字元保持了双向流通性。在补完后的电脑上，当这些字元从大五码转变到Unicode储存后，它们全都会被对应到正确的Unicode位置上，之后即使是对于没有安装补完计划的电脑使用者，只要他的系统和程式支援Unicode，在读取这些文字时，就完全没有问题。
== 作业平台 ==
「Unicode补完计划」修改作业系统中的字码表，处理Unicode和非Unicode字码的对应。「Unicode补完计划」首先是在以Unicode架构为核心的微软Windows NT（包括Windows 2000和Windows XP）作业系统上开发，之后又支援了以ANSI架构为核心的Windows 98和Windows Me。
Linux也有另外的使用者，开发 Linux版的补完计划。
Palm上也有另外的使用者，开发对应的补完计划：
* CJKOS版本
* 掌龙版本
=== 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\unicode.bin删除并重新开机后，系统会使用最原始的预设代码页437显示，在这情况下所有存在于档名中的中文字都会以『__』显示，这包括大部份的桌面捷径和几乎整个『开始』功能表）
* $SYSDIR\GDI.exe在显示字型时，取得字型的档案（将代码页内码依此档内含之转码表转换成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）、JIS X 0208之中出现的所有汉字，和香港增补字符集之中，Unicode码落在U+4E00至U+9FA5中 （即Unicode 1.1版定义）的汉字。（因编码空间不足的关系，并不收录在香港增补字符集的Unicode扩充汉字）
== 使用上的问题 ==
「Unicode补完计划」原先的立意是避免利用造字，以达成扩充Big-5的目的：但由于Unicode环境尚未成熟、以及使用者的误用，「Unicode补完计划」有时反而为使用者本身──甚至其他使用者──带来其他的麻烦。
=== 网页交换 ===
这是「Unicode补完计划」使用者可能会影响到其他使用者的最大问题。
一般的网页浏览器或电子邮件客户端，在使用者打出非该软体显示画面预设编码（例如写一封用大五码作编码的信件）的字元时，软体会自动把这些字元转换成Unicode参照码，例如「堃」会被自动转换成「&#22531;」；然而在补完后的电脑，由于即使打出的是原非大五码预设的字元，也会被认为是大五码的字元（装了「Unicode补完计划」的系统，在对照字码表后，发现当中有这个字），因此就不会被转换。这也就是说，其他使用者不一定能看见该使用者所打的字──除非他们也有装「Unicode补完计划」。于是这反而与「Unicode补完计划」的创立宗旨背道而驰：原先避免以外字集解决缺字的「Unicode补完计划」，反而变成另一套外字集。解决方案是，当使用者安装「Unicode补完计划」时，会获得一份「HTML外字相容转换器」（另外也有 网路版），可以直接把原本不属于大五码的字元转换为参照码；接下来只要使用这份夹杂着参照码的文件，就能让其他使用者也见到这些字元。另一种做法是，像推广樱花输入法一样推广「Unicode补完计划」，使其也变成一种人人使用的非官方标准。然而最终的解决方案是放弃大五码，将网页或信件直接改用Unicode编码。NoteTag|注：但是在原本就只有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补完计划会使用到使用者造字区；也就是说如果使用者有自造字，这些字可能会不见。
:PS：如果使用者的自有造字放在Unicode补完计划提供的「造字保留区：0xFA40～0xFA63」内的话，则不在此限。
*有人表示补完计划会让Internet Explorer的自动选择网页编码准确度下降，但是无法证实。
*在安装补完计划后，Microsoft FrontPage在处理Big5编码网页时会运作不正常（包括：存档会当掉导致档案大小归零内容遗失），但是如果FrontPage是处理Unicode网页，就能正常运作。
:PS：这个问题只有在使用者的Windows其「非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补完计划但内建其字码表的软体 ==
*PieTTY：SSH与Telnet客户端程式。
*OpenPCMan：Telnet客户端程式。
*Firefox 2.0版：网页浏览器。（Big5→Unicode单向使用Unicode补完计划字码表。）
== 相关条目 ==
*大五码（Big-5）
*中国海字集
*Unicode
==参考文献==
== 参考文件 ==
*「Unicode补完计划」读我档案（附于安装程式中）
* C_xxx.NLS & CP_xxx.NLS结构解说
* Unicode.bin结构解说
* Windows File Protection: How to disable it on the fly
== 外部连结 ==
*  「Unicode补完计划」官方旧站 - 镜像
*  中文编码网页-台湾Unicode补完计划（按部首排序）-字
*  「Unicode补完计划」官方网站 - 失联站台
*  补完计划救星fix-attempted=yes  - 失联站台
== 备注 ==