“Unicode补完计划”的意思、由来-中文百科全书

简介

要留意的是“Unicode补完计划”不等于 Unicode。当你看见有人说“我安装了Unicode”，通常是他把“Unicode补完计划”和 Unicode 搞混了。

“Unicode补完计划”也不是用来解决软件显示乱码的问题。电脑内要有相关的字形 (例如支援整个 Unicode 汉字的字形) ，才能在电脑显示器看到。因为“Unicode补完计划”只包含了编码转换表，并不包括字形在内。而一些日语游戏装在Windows XP所出现的乱码问题，应使用Microsoft AppLocale内码转换器等程序去作内部转换。

历史

2001年9月: Unicode计划1.0版发表。支援日文假名。

2001年10月: Unicode计划2.0版发表。支援第一水平汉字单向对应。

2002年4月: 中文化联盟发表Big5 Extension扩充规格。一口气支援大量汉字。

2002年5月: Big5 Extension扩充规格与Unicode计划同意整合。

2002年6月: 有鉴于Big5 Extension易与中推会的Big5E名称混淆，正式决定统一以Unicode计划作为名称，由中文化联盟发布。

背景与原理

“Unicode补完计划”的原理是把大五码造字区的区位，和 Unicode 的相关字符作双向对应，以达到无须借着外字集，也能使大五码文件或档名使用原先欠缺的汉字。

由于大五码仅收录13,053个汉字，对不少使用者而言确实不足够，例如日语假名、人名、香港特殊用字、科学用的特殊字等等都欠奉。长久以来解决这种问题的方式都是加装各种外字集，例如樱花输入法（支援日语假名）、中国海字集、香港增补字符集(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架构的Window

包括Windows 98、Windows ME。

修改的档案：

$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补完计划会使用到使用者造字区；也就是说如果使用者有自造字，这些字可能会不见。

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补完计划字码表。)

词条	Unicode补完计划
释义	Unicode补完计划（官方网站使用的识别系统用字是Unicode补完计画）是台湾电脑使用者针对大五码 (Big-5) 自面世以来，字数不够用的问题（又称缺字问题）所采取的其中一种解决方案（参看大五码#影响），使网民能从简体中文或日语网站，复制网页内的文字，原封不动的贴在装了“Unicode补完计划”的电脑内（具体字符请参看字符的来源）。它是一个自由软件。简介历史背景与原理作业平台 ANSI架构的Window 字符的来源使用上的问题网页交换新旧档名其他问题简介要留意的是“Unicode补完计划”不等于 Unicode。当你看见有人说“我安装了Unicode”，通常是他把“Unicode补完计划”和 Unicode 搞混了。 “Unicode补完计划”也不是用来解决软件显示乱码的问题。电脑内要有相关的字形 (例如支援整个 Unicode 汉字的字形) ，才能在电脑显示器看到。因为“Unicode补完计划”只包含了编码转换表，并不包括字形在内。而一些日语游戏装在Windows XP所出现的乱码问题，应使用Microsoft AppLocale内码转换器等程序去作内部转换。历史 2001年9月: Unicode计划1.0版发表。支援日文假名。 2001年10月: Unicode计划2.0版发表。支援第一水平汉字单向对应。 2002年4月: 中文化联盟发表Big5 Extension扩充规格。一口气支援大量汉字。 2002年5月: Big5 Extension扩充规格与Unicode计划同意整合。 2002年6月: 有鉴于Big5 Extension易与中推会的Big5E名称混淆，正式决定统一以Unicode计划作为名称，由中文化联盟发布。背景与原理 “Unicode补完计划”的原理是把大五码造字区的区位，和 Unicode 的相关字符作双向对应，以达到无须借着外字集，也能使大五码文件或档名使用原先欠缺的汉字。由于大五码仅收录13,053个汉字，对不少使用者而言确实不足够，例如日语假名、人名、香港特殊用字、科学用的特殊字等等都欠奉。长久以来解决这种问题的方式都是加装各种外字集，例如樱花输入法（支援日语假名）、中国海字集、香港增补字符集(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架构的Window 包括Windows 98、Windows ME。修改的档案： $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补完计划会使用到使用者造字区；也就是说如果使用者有自造字，这些字可能会不见。 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补完计划字码表。)
随便看	斫地斫断斫伐斫拂斫父斫击斫开斫轮斫轮手斫木斫丧斫杀斫鲜斫营斫斩斫治斫馘斫胫斫砻斫畲斫锉斫胥斫鲙砭焫砭剥