庄振宏先生也是IETF互联网工程特遣组织属下之IDN国际化域名工作小组的主席之一。

摘要：

互联网原本就是美国的发明。所以，互联网草案协议里对于英文以外的语言兼容性问题等方面，很自然地就 会做很少，甚至完全没有做到，适当的考虑。虽然如此，全球有百分之六十的人口不使用英语是一项不争的 事实。所以，互联网草案协议里绝对有必要考虑到如何兼容其它非英语系语言，以便让互联网真正成为国际 互通的网络。

1. 简介

互联网在五、六年前初受欢迎的时候，曾被大众誉为“全球村”。虽然现在“全球村”这一说法已不再，可是 它却是一个值得探讨的概念。

一个村庄应解释为某个区域里的居民社群。居住在某一个村庄里的人们必定有许多共同之处，如文化、语言、 宗教、科技、生活方式等。所以说，对于“全球村”这一说法，在定义上，就是横跨全球的一个村庄部落。 这样的一个村庄，便是架在互联网网络架构上的一个数码虚拟村庄。互联网上的每一台电脑计算机都使用 同一种科技、使用同一种草案协议进行沟通。这共通的草案协议便是IP互联网草案协议。

可是，很可惜的是，人类之间的沟通并不使用草案协议。

自人类尝试建筑巴别圣塔以来，我们便受到诅咒，得饱受因为使用不同语言所带来的分歧。对于大多数人 来说，我们非常骄傲地，甚至积极地，接受这样的诅咒；因为我们的语言便塑造了我们的个别文化，也 赋予了我们个别的身份。

为了在数码差距的隔阂上架起桥梁，也为了让互联网更能国际互通；互联网必须为不使用英语做母语的人们 建立一个更简便易用的平台。而这样的神圣工作的整个过程，便叫做“国际化”(Internationalisation) 或是“本土化”(Localisation)工作。

2. I18N与L10N所带来的难题

国际化(I18N)笼统上指的便是将软件程式加以准备，以便可以兼容适用于多种文化、地域或地点[2]的工作过程。 “I18N”便是“国际化”(即“Internationalisation”字里的“I”开头字母 + 接下来的其它18个字符 + 该字里的“N”结尾字母)的缩写。本土化(L10N)则是指将软件程式加以改编，针对适应而适用于某一种文化、 地域或地点 。“L10N”便是“本土化”(即“Localisation”字里之“L”开头字母 + 接下来其它10个字符 + 该字里的“N”结尾字母)的缩写。

许多人秉着普遍错误的观念，认为I18N与L10N基本上是用户界面方面的私人问题；而且他们认为，倘若软件 都保持根据“8-比特”的利落性，那国际化工作便不会遇上什么难题。可是，事情却并非如此简单。

2.1 CCS编码字符集

CCS编码字符集是一套明确的规则，基本上它将字符集里的个别字符，赋予个别的数字编码，并在两者之间 立下正式的关系系统。[9]。

在为日文做L10N工作(即“日本化”，或是J10N工作)时，我们可以使用那些已受JISx201、JISx208以及 JISx212等规则所规划的日本字符。或者，我们也可以使用一套内含(几乎)所有文字字符的全球标准 字符集，如ISO10646等。ISO10646等字符集完全符合31-比特的CCS规则。

使用CCS的决定，在很大的程度上，是根据必要条件而定的。尤其是在JIS与ISO10646之间，它们的主要不同 在于前者是以语言为基础而建立的CCS，而后者则是以编码为本的CCS。

有些语言拥有多过一种编码。例如日语，日本人便有使用平假名、片假名和汉字等。有些编码字符能在几种 语言里通用，如中文、日文和韩文等都使用汉字字符。[10]ISO10646能够处理CJK中、日、韩文 里汉字字符的统一化。这将能够减少汉字字符里重复(或看起来相似)的字符数量，并将三种语言里共通使用的 字符归纳统一，使用同一个编码据点。

所以，如果选择使用ISO10646的话，那您便会遇到电脑无法区别编码据点以外文字字符的问题。要解决这 问题便有需要为宽带以外的语言文字作麻烦的标签记符。可是，倘若使用当地本土化的CCS，如JIS等，您 则会遇到得同时应付各种语言的多个个别CCS字符集的混乱问题。

2.2 CES字符编码方案

CES字符编码方案是一种附加比特编号的字符编码形式方法。[24]

且看J10N一例，倘若我们决定使用JIS编码标准制式的话，那在为ISO2022-JP、EUC-JP或Shift-JIS等CCS 字符集做编码工作时，我们都可以有多个CES编码方法可供选择。倘若我们选用ISO10646的话，我们也能 拥有UTF-8、UTF-16或UTF-32等多个CES编码方案。

可是话说到底，任何一种CES，无论如何始终都无法充份独立地担任全部的编码工作。譬如说，日文版的 视窗2000版，其运作系统便建立在UTF-16之上。可是有些数据流和API接口等却建立在UTF-8之上，而一些 广为受用的应用软体则可能使用Shift-JIS (Win95/98)或EUC-JP (Unix)等。因此，在难免使用大型映象 平台的情形下，各个CES之间的互通编码技术是有必要发展的。

2.3 匹配与检索

在一般的英语软件来说，一看到A=B(对于上下档字符敏感度的匹配)便可探知匹配度。可是对于I18N与L10N 软件来说，却完全行不通了。

以ISO10646为例，"?#8221; 便有两种代表方法：(一)、以U+00E5为代表的组合形式；或者是(二)、U+0061 U+030A 所代表的分解形式。

Unicode统一编码系统在第#15章Unicode技术报告上[25](见图一)便已立下字符间的等值规则。基本上， 规格化形式分为4大类：NFC组合规格形式、NFKC互通兼容组合规格形式、NFD分解规格形式和NFKD互通兼容分解 规格形式。

图一、字符间的Unicode等值规则[25]

匹配度也分为高度匹配、低度匹配和完全匹配等。匹配度则有赖于软件是否能够有判断规格形式的功能而定。 规格形式很可能无法独立存在。就以中文软件为例，一个需要繁简中文双向等值匹配功能的中文软件，必定 就会需要额外的运作规则，而这样的规则便会从此另树成为全新的专门科学。其它如希伯来文及阿拉伯文等 语言，则有元音可有可无的不规则语言架构。

文字检索功能，更是为I18N工作难上加难。以往常用的“空格”定位文字检索范围，现在根本用不上。好比中文 而言，一条句子写下来字里行间根本都不使用任何空格。所以倘若在为“的士司机”这一词汇进行检索时， 首先便得使用“语形学分析法”将词汇分成“的士”和“司机”两个词组，才可进行次串检索。

2.4 分拣与校勘

校勘，或是分拣，指的是文字资讯单位次序定位的过程。[24]

分拣次序在文化与文化之间都有所不同，而且有许多专门的应用体更是需要用到其中的变更体系。分拣次序 也可能在个别文字当中、或者整条句子上的层面进行。它也可以根据发音、或字形，甚至在方块文字里头的 笔划与根号等而进行。[24]

因此，分拣次序将无法根据二进制码的字符编码排列、或是通过单层砝码排序等来进行。这也代表说，分拣排序 对文化通统认同分拣来说，只有间接的影响能力。[23]

2.5 字符体现引擎

字符体现引擎利用字体集来向用户体现字符文字。倘若缺乏一个适用的字符体现引擎，那用户在屏幕上便 只能看到乱码字串。软件是否能够理解字符体现程式上的习性以及所注明的字形种类是及其重要的。

除此以外，对于一些语言，如希伯来文和阿拉伯文等，还有字符bidi双向体现的必要性。阿拉伯文字符 会根据位置次序与元音的排位，而可能被省却，或是被挪位它处。至今，还未曾出现一套能够完整体现 阿拉伯文的字符体现引擎。

2.6 IME文字输入引擎

IME文字输入引擎是让用户使用惯用语言输入文字的装置。

电脑可以通过多种方法进行文字的输入。键盘是至今最常用的输入工具，可是有许多文字根本无法通过键盘 上的101个键来进行输入。所以，一套IME文字输入引擎可能是一套复杂的软件系统，能够允许用户通过语音 或笔划的输入，进行字符的选择使用。对于文字系统里有多个读音符号的语言(如欧洲语言等，一个字符普遍 上都会有两个以上读音符号)更是需要一套IME文字输入引擎。[22]

不是所有的OS运作系统都内设适当的IME文字输入引擎。如果某件软件能够支援I18N，可是用户却无法与应用体 接触的话，那就毫无意义了。

2.7 其它

L10N不单只是改变所受用的语言而已。譬如说，一套以美金作单位、并且根据美国会计法则与税务法所 编写的会计程式，即便在没有语言障碍的情形下，也无法在新加坡畅销。

所以说，L10N所要求的，是人们对各地社群作风、使用习惯、法律规则的了解与认识，也得为此目标达到 一定程度上的用户化定制才行。

3. 互联网的I18N化与L10N化

我们如何将一个本来就已环球化的网络加以I18N化？我们如何进行L10N而又不将互联网“分割诸侯”呢？

随着越来越多非英语系用户纷纷上网，互联网草案协议的确有强大的需要，进行英语以外文字的兼容化。

另一方面，互联网本来就是为全球互联互通而设计的网络。所以，不论您身处俄罗斯，亦或是巴西，互联网都会 根据同一套TCP传输控制协议传输共通的IP草案协议[20，21]。因此，倘若各国各地都为迎合自己的需要 而自行将互联网分割本土化，那便会与L10N将互联网本土化的原本意义有着很大的抵触。L10N的确潜在着将 互联网“分割诸侯”的危险：试想想个别网络倘若一意孤行，各执自己的草案与协议，那对互联互通工作简直 是一场恶梦。

IETF必须面对这些问题。[8]再者，加上I18NL与L10N本身的微妙复杂之处，这些问题更显得更加艰巨。

即便如此，IETF已经非常努力地为I18NL与L10N的草案协议与系统，进行精心的设计与配置工作。

关于I18N与L10N方面的相关工作，在此是无法一一陈述的。以下所列出的，便是一些为让不使用英文的用户， 更简易使用互联网的例子。

3.1 互联网电邮地址

互联网上的电邮系统，本来是建立于美国7比特ASCII编码系统之上。每一通电邮都是以延伸性metadata标题， 根据美国7比特ASCII编码系统一向的事先包裹，以便呈现在80栏屏幕上的固定字形宽度。[18，19]

当时，IETF在尝试实行I18N和L10N(即多语言化)的工作时，尚未有ISO10646等适用的国际CCS系统。因此， IETF的方案便是利用邮件标题，在其中制造文字集的标签记符功能。因为有些本土化文字集原属8比特型， 所以便发展了一套编码系统，来负责ASCII以外字符的传输。这个方案后来普遍被叫做MIME[13，14]多用途的网际邮件扩充协议。

MIME，在原理上，提供了可以与国际客户群进行电子通讯的功能；也能在遇到不熟悉字符、或是不存在文字集时， 通知用户。现在电邮客户群里大多都支援MIME内容输送编码。可是问题是，一般客户只能兼容一定数目的语言 字符集；而且在电邮字符集间的对译转换，常需要庞大的映象平台才可进行。

3.2 万维网

HTTP互联网服务程序协议[15]在万维网上是普遍受用的基本草案。它是一项设计简单的草案协议，负责 将主机上的网页输送到用户端去。

W3C万维网联盟会[26]于1999年，与IETF联手研发了HTTP第1.1版[15]。HTTP第1.1版增加了以下I18N功能：

a. 可向接收用户注明主机所发送之页面的原本编码类别(字符集参数) b. 可向接收主机注明用户端所能够解析的编码类别 c. 可向接收用户注明主机所发送之页面所使用的语言(内容语言标题) d. 可向接收主机注明用户端所能够使用的语言系种，也谓语言商议功能(核准接受语言标题)

有了这些功能(尤其是功能d)，主机便可以测知用户所想用的语言，并从而提供以该语言所编写的网页资料。

HTML电脑用语是万维网上刊登内容的国际通用混合语。经过几轮的进化过程，今日的HTML电脑用语已经备有 多项功能，可以应付国际上多元化互联网社群的个别特殊需求。[4]

ISO8859-1原本是HTML所使用的CCS基础。可是这显然无法支援那些使用Latin-1拉丁语字符以外的文字的网页。 许多用户都因此尝试将当地语言的编码寄存在HTML用语里，从而进行外语的主机服务。因此，HTML的多语言化 其实是由基层用户的主动而开始的。

W3C联盟会相继召开了I18N工作小组和利益集团[5]，来统一组织HTML所开始的I18N化工作。现在所使用的HTML第 4.0版便是以ISO10646作为其CCS基础的；其中ISO10646属下的各个CES，如UTF-8、UTF-16等都可以兼容使用。 而对于其它的CCS和CES，只要有适当的语言标签记符，便也可以使用。

虽然W3C联盟会的原意本来是让所有HTML引用ISO10646，可是在许多浏览器还无法支援ISO10646的情况下， 将当地语编码寄存在HTML仍然是普遍受用的方法。即便是Netscape和Internet Explorer的第5、第6版等， ISO10646的支援仍未充份完成。所以，要ISO10646完全融入HTML还需要一段时间。

3.3 域名

DNS域名系统能够提供个别的一致性域名空间，并能确保这些域名能够个别准确地接驳到独有的网络资源(如 IP域址等)。DNS系统是一个级层式发布可靠检索的系统。为了确保检索的准确单一性，域名的拼写都被限制 于几个字符以内，其中包括英文字符里的A至Z(上下档敏感)，0至9，以及连字杠号“-”等；这便是俗称的LDH(Letters，Digit及Hyphen)[16，17]。

随着广告宣传，网域域址及电邮地址纷纷得到普及使用，域址当中的域名更是成为万众瞩目的环节。可是， LDH限制的束缚显然的是互联网定位指标的绊脚石。因此，IETF在1999年年底召开了IDN国际化域名工作组[6]，研究并 拟定支援非英语域名的技术要求与制式标准。

域名已经成为互联网上不可或缺的一部份，而且广受许多草案协议的使用。多年来，许多草案协议和软件等都以 域名只允许LDH字符的使用为前提，而进行设计发展。因此，现在如果想要添加LDH以外的字符的话，难免会 打破协议常规或者破坏软件的正常运作。

再加上，每每任何I18N工作的实施，必定就会遇上需要能够准确无误地进行匹配工作；而这将带来复杂的标准化规则的干扰。 以IDN内行话来说，域名使用上的标准化工作过程就叫作NAMEPREP[12]。

IDN工作组虽然迟迟未能呈出总结，可是对于利用IDNA应用体[7]来施行IDN的计划，却大体上已经达成共识并已获得支持。 IDNA这份用户端应用体能够负责NAMEPREP的工作，将所输入的文体转换成ASCII兼容的编码[1，3，11]。该应用体是利用 ISO10646里的TES编码转换程式来完成LDH字串转换工作的。在加上ACE系统的相并施行，所有现存的草案协议、主机以及 应用体便可以在不受到不兼容问题的状况下，正常运作了。

4. 总结

国际化与本土化工作，因为本质上的复杂性问题，所以在实施上必须进行精心策划与设计。随即实施后，用户端 的易于使用与否，也得小心衡量；否则必定会遇到互联网瓜分分裂的危险。

既然如此，IETF属下的互联网工程师也非常理解非英语用户的需要。因此，他们也不遗余力地研究I18N与 L10N在互联网上的使用与应用，所须探讨的事项。

有朝一日，要用互联网就得懂英语这样的一个隐在条件，将不再成立。用户便可以不论上线、下线时，都 使用自己想用的语言了。也只有到那时，一个充满多元化文化与社群的“世界村”理念，才会得以实现。

鸣谢

感谢i-DNS.net国际化域名系统公司的叶一青先生与洪伟量先生对此份文稿的校正。

第3.1章有关互联网电邮的资料，取材自克理斯 纽曼先生还未出版的互联网草案书。

参考资料

[1] 取材自AMC-ACE-Z 第0.2.1版, draft-costello-idn-amc-ace-z-00.txt, Adam M. Costello著

[2] 取材自CJKV Information Processing, ISBN 1-56592-224-7, Ken Lunde著

[3] 取材自Differential Unicode Domain Encoding (DUDE), draft-ietf-idn-dude-02.txt, Mark Welter, Brian W. Spolarich, Adam M. Costello联合著作

[4] 取材自HyperText Markup Language, http://www.w3.org/MarkUp/

[5] 取材自Internationalisation at W3C, Martin Duerst, http://www.w3.org/International/

[6] 取材自Internationalised Domain Names Working Group, http://www.i-d-n.net/ , James Seng, Marc Blanchet联合著作

[7] 取材自Internationalised Host Names in Applications, draft-ietf-idn-idna-03.txt , Patrik Faltstrom, Paul Hoffman联合著作

[8] 取材自Internet Engineering Task Force, http://www.ietf.org/

[9] 取材自ISO/IEC10646-1:2000. International Standard ?Information technology ?Universal Multiple Octet Coded Character Set (UCS) ?Part 1: Architecture and Basic Multilingual Plane

[10] 取材自Language and Script, Unicode Consortium, http://www.unicode.org/unicode/onlinedat/languages-scripts.html

[11] 取材自MACE: Modal ASCII Compatible Encoding for IDN, draft-ietf-idn-mace-01.txt , M. Ishisone, Y. Yoneya联合著作

[12] 取材自Preparation of Internationalised Host Names, draft-ietf-idn-nameprep-05.txt , Paul Hoffman, Marc Blanchet联合著作

[13] 取材自RFC 1521 MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. N. Borenstein, N. Freed等，于1993年9月联合著作

[14] 取材自RFC 1522 MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text. K. Moore于1993年9月著

[15] 取材自RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee等，于1999年6月联合著作

[16] 取材自RFC1034 Domain names - concepts and facilities. P.V. Mockapetris于1987年11月著

[17] 取材自RFC1035 Domain names - implementation and specification. P.V. Mockapetris于1987年11月著

[18] 取材自RFC2821 Simple Mail Transfer Protocol. J. Klensin, 于2001年4月编辑

[19] 取材自RFC2822 Internet Message Format. P. Resnick于2001年4月编辑

[20] 取材自RFC759 Internet Message Protocol. J. Postel于1980年8月著

[21] 取材自RFC761 DoD standard Transmission Control Protocol. J. Postel于1980年1月著

[22] 取材自Terminology used in Internationalised in IETF, draft-hoffman-i18n-terms-01.txt, Paul Hoffman著

[23] 取材自Unicode Collation Algorithm, Unicode Standard Annex #10, Mark Davis, Ken Whistler 联合著作

[24] 取材自Unicode Consortium, http://www.unicode.org/ The Unicode Standard Version 3.0, Unicode Consortium, ISBN 0-201-61633-5

[25] 取材自Unicode Normalisation Forms, Unicode Standard Annex #15, Mark Davis, Martin Duerst联合著作

[26] 取材自World Wide Web Consortium, http://www.w3.org/