莊振宏先生也是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/