語言問題

Visual Studio .NET 2003

語言問題的產生是因為世界各地的語言採用不同的顯示、字母、文法和語法規則。

雙向認知

大小寫設定

字碼頁

複合文字認知

字型

輸入法

鍵盤

分行和斷句

鏡像認知

Unicode

雙向認知

雙向 (Bidirectional,Bidi) 一詞用來描述文字的書寫方向可由左至右 (Left-to-Right,LTR),也可由右至左 (Right-to-Left,RTL)。英文和阿拉伯文混用的文字就是一個很好的範例。

確認您的應用程式是否為雙向認知時,請特別注意幾個問題。

  • 內部資料儲存 - 如上面所述,雙向文字有 LTR 和 RTL 書寫方向。雖然兩個書寫方向不同,但是儲存方式都是從第一個字元到最後一個字元。最容易理解的方式,就是想像資料從緩衝區的頂端往底端依序儲存。
  • 顯示資料流 — 大部分拉丁語系的語言一次顯示一個字元。雙向文字字元位置採用不同屬性來規定文字方向,以及阿拉伯文連字如何依前後字元變更其形狀,而這些屬性已經變更了這種顯示公式。現在,最好將目前顯示的行儲存在緩衝區內,然後您每次在行中進行修改或加入字元時,即輸出整個緩衝區內容。
  • 字行長度 — 基於上述項目說明的連字變更情況,所以加總快取字元長度來計算行的長度並不是理想的方法。

大小寫設定

ASCII 具有內建功能,可讓您為每個英文字母建立小寫和大寫字元,方法是對其對應的字碼指標加上或減去 0x0020:

A[0x0041] + 0x0020 = a[0x0061]

如此一來,轉換大小寫就成了簡單的加減演算;

if ((c >= 'a') && (c <= 'z')) upper = c - 0x0020;

但是有重音的拉丁字母則不包含在內 (A[U+0102]、a[U+0103])。光是把將所有字元加減同樣的值,還是無法取得對應的大寫和小寫表示。

大小寫處理的演算辦法不適用於所有項目,還有其他幾個原因:

  • 有些語言不具有一對一的對應大小寫字元。例如:
    • 歐洲法文的重音字元在大寫時不加重音符號 (é 變成 E)。然而,加拿大法文的重音字元則保留其重音符號 (é 變成 É)。
    • 德文 ß 大寫的對等用法是 SS。
  • 大部分的非拉丁語文字甚至不使用大小寫的概念。例如:
    • 中文
    • 日文
    • 泰文

字碼頁

字碼頁是依照特定順序選定的字元碼清單 (字元以字碼指標表示)。字碼頁通常經過定義,以支援指定語言或共享通用寫入系統的語言群組。所有的 Windows 字元碼都包含 256 個字碼指標。最前面的 127 個字碼指標大部分表示相同字元,這樣才能保有延續性和使用舊字碼。上層 128 個字碼指標 128-255 (以 0 起始) 字碼頁有相當大的不同。

例如,字碼頁 1253 提供希臘文寫入系統需要的字元碼。字碼頁 1250 提供拉丁文寫入系統如英文、德文和法文所需的字元。上層 128 字碼指標包含重音字元和希臘文字元。所以,您不能將希臘文和德文儲存在同一個資料流裡面,除非您包含一些表示參考字碼頁的識別碼類型。

由於中文、日文和韓文包含 256 個以上的字元,所以需要根據包含 256 個字碼指標的字碼頁概念來開發不同的配置。結果就產生了雙位元組字元集 (Double-Byte Charater Set,DBCS)。

DBCS 將一對字碼指標 (雙位元組) 表示為一個字元。所以在程式設計時,光是用一組指標表示組內第一個位元組時會被忽略,除非後面緊跟著一個定義的第二個位元組。DBCS 需要使用能把成對字碼指標視為一個字元的程式碼。但是,這樣仍不允許在同一個資料流中組合兩種語言,例如日文和中文,因為同一個雙位元組字碼指標會根據不同的字碼頁而代表不同的字元。

複合文字認知

複合文字所需要的特殊處理,涉及下列一個或多個特性:字元的重新排列、視前後文變更形狀、結合字元和讀音符號的顯示、專門的斷字和對齊規則、游標定位和篩選出不正確的字元組合。所謂複合文字包括:阿拉伯文、希伯來文、泰文、越南文和印度文語系。

所以務必遵守下列要點:

  • 顯示輸入文字時,不要一次輸出一個文字。
  • 若要配置字元/圖像 (Glyph) 緩衝區,請勿以為一個字元就等於一個圖像。
  • 若要測量字行長度,請勿加總快取字元寬度。

字型

Windows 具有選取適當字型以顯示特定指令碼的能力。Windows 採用一種名為 MS Shell Dlg 的新字型名稱來提供這個功能。MS Shell Dlg 是一種對應機制,可讓 Windows 支援字元不包含在字碼頁 1252 中的文化特性/地區設定。它不是字型,而是代表不存在之字型的字型名稱。MS Shell Dlg 字型名稱會對應到與目前文化特性/地區設定關聯的預設 Shell 字型。例如,在美國英文版的 Windows 98,它是對應至 MS Sans Serif。但是,在希臘版的 Windows 98 則對應至 MS Sans Serif Greek。在美國英文版 Windows 2000 是對應至 Tahoma。但是,東亞版的 Windows 9x 無法使用 MS Shell Dlg。如需詳細資訊,請參閱當地語系化和 Shell 字型

然而,應用程式開發人員建立多語系應用程式時經常忽略字型。處理字型問題時,請務必注意這兩點:

  • 硬式編碼字型名稱 — 使用 Unicode 時,我們要面對的不僅是幾百個,而是數千個不同的字元。大部分的字型不涵蓋所有的 Unicode 字元集。所以如果硬式編碼出的字型名稱能顯示英文字元,卻不能顯示日文,那麼所有當地語系化的日文文字就會無法正確顯示。另一個不將字型名稱進行硬式編碼的原因,在於顯示文字的系統可能沒有您想採用的字型。
  • 硬式編碼字型大小 — 有些指令碼會比其他指令碼來得複雜,需要更多像素才能適當顯示。例如,大部分的英文字元可以 5x7 格線顯示,但是日文字元需要至少 16x16 格線才能清楚地顯示。中文需要 24x24 格線,相較下泰文的寬度只需要 8 像素,但高度需要至少 22 像素。這就是為什麼有些字元可能無法用過小的字型顯示。

處理字型名稱和大小最好的方法,就是把他們當成另一種可當地語系化的資源。使用 MS Shell Dlg 可以解決在 (任何語言版本的) Windows NT/Windows 2000 上執行 (任何語言的) 應用程式的問題。將字型設定為可當地語系化的資源,就可解決讓當地語系化工程師能夠變更當地語系化 UI 字型的問題。

輸入法

輸入法 (IME) 又稱為前端 (Front End) 處理器,這是一種 Applet,可讓使用者以標準 101 鍵鍵盤輸入東亞書寫語言所使用的數千個不同字元。

使用者採用這些方法中的一種來撰寫文字:字根、注音表示或輸入字元的字碼頁索引數字。IME 相當普遍,Windows 根據每個國家/地區最常使用的輸入法將 IME 隨附在軟體中。

IME 包含一個可將按鍵轉換為音素和表意字元的引擎,再加上一個包含常用表意文字的字典。使用者敲擊按鍵時,IME 引擎會嘗試將此按鍵所代表的字母轉換為表意字元。

由於許多表意文字具有許多相同的發音,所以 IME 引擎所作的第一個猜測不一定會是正確的。當 IME 的建議不正確時,使用者可以從同音字清單選擇,而使用者選擇的同音字即成為下一回 IME 引擎的第一個猜測。

您不需要使用當地語系化的鍵盤,就可輸入表意字元。當地語系化的鍵盤可直接產生音素音節 (例如假名或韓文),使用者也可使用拉丁字元表示音素音節。

日文中的羅馬字母是拉丁字母,用來表示假名。日文鍵盤含有可讓使用者切換輸入羅馬字母和假名的額外按鍵。若您不是使用日文鍵盤,您需要鍵入羅馬字母來產生假名。

在 Windows 執行的應用程式有三種不同層級的 IME 支援:不支援、部分支援和完全自訂支援。將應用程式經過稍微修改 (如重新調整視窗) 即可自訂 IME 支援,或者應用程式也可完全變更 IME 使用者介面的外觀。

  • 不支援 — 無 IME 認知的應用程式會忽略所有的 IME 特定的 Windows 訊息。大部分針對單一位元組語言設計的應用程式無法認知 IME。無 IME 認知的應用程式透過預先定義的全域類別 (稱為 IME),會繼承作用中 IME 的預設使用者介面。Windows 會依照 IME 全域類別,自動替每個執行緒建立一個視窗,同一執行緒中所有無 IME 認知的視窗會共用這個預設 IME 視窗。
  • 部分支援 — IME 認知應用程式會建立本身使用的 IME 視窗,不需採用系統預設。具有 IME 部分支援的應用程式會使用這些功能,來設定 IME 使用者介面視窗的樣式和位置,但是這些部分仍需要由 IME DLL來繪製,而 IME 使用者介面的大體外觀仍然一樣。
  • 完全支援 — 相較之下,完全 IME 認知應用程式從 IME DLL 接管繪製 IME 視窗的工作 (狀態視窗、組字視窗和候選視窗)。這種應用程式能夠完全自訂這些視窗的外觀,包括決定視窗位置、選擇採用哪種字型和字型樣式來顯示應用程式的字元。這項功能使 IME 的互動更順暢,並為使用者建立「自然」的介面,對於文字處理和主要用來處理文字的類似程式,顯得特別方便有效率。

如需詳細資訊,請參閱輸入法 (IME)

分行和斷句

分行和自動換行演算法對於文字剖析和文字顯示相當重要。西方文字通常依循連字符號規則或字緣來分行的模式,或是依據空白區 (空格、跳格鍵、行結尾、標點符號等) 來斷字的模式。

但是,亞洲 DBCS 語言與西方語言的規則迥異。例如,與大部分西方文字非常不同的中文、日文、韓文和泰文並不一定要使用空格來區隔前後兩個字,泰文甚至不使用標點符號。

對於這些語言,多語系軟體的應用程式就無法採用空白字元或標準斷字規則,來設計分行符號和自動換行演算法。這些語言必須採用其他的方針。

例如,避頭尾規則決定日文的分行方式 — 您可以在任何兩個字元之間分行,除了下列例外:

  • 一行文字結尾不可以是任何前置字元的開頭,例如左引號、左括弧和貨幣符號,前置字元不應該與後面的字元分開。
  • 一行文字不可以使用下列任何字元開頭,例如右引號、右括弧和標點符號,這些字元不應該與前置字元分開。
  • 某些溢位字元 (標點符號) 可能會延伸超過水平文字的右邊界,或超過垂直文字的下方邊界。

鍵盤

鍵盤配置會依文化特性/地區設定而有所不同。有些字元在所有鍵盤配置中找不到。設定快速鍵組合時,請確定您能夠透過國際化的鍵盤重新建立這些鍵,尤其是計畫在 Windows 2000 多語言使用者介面 (Multilanguage User Interface,MUI) 使用快速鍵組合時要特別注意。

因為每種文化特性/地區設定可能會使用不同的鍵盤配置,所以請考慮使用數字和功能鍵 (F4、F5 等) 來作為快速鍵組合,而不要使用字母鍵。

您不需要將數字和功能鍵當地語系化,使用者不會直覺將這些鍵當成字母組合。有些快速鍵可能無法適用於一些特定文化特性/地區設定的所有鍵盤配置。例如,有些文化特性/地區設定會使用一個以上鍵盤,例如東歐和大部分的阿拉伯語系國家。

鏡像認知

由右至左 (RTL) 語言中,不僅文字對齊和文字閱讀順序是由右至左,連 UI 的配置也應依照其自然的方向。當然,這些配置變更只會套用至當地語系化的 RTL 語言。

注意   .NET Framework 不支援鏡像。

阿拉伯文和希伯來文版的 Windows 98 引進鏡像技術,以翻轉字元來解決這種問題。Windows 2000 採用同樣的技術,使 UI 具有完美的 RTL 外觀和感覺。Windows 98 中,這項技術僅提供給當地語系化的阿拉伯文和希伯來文作業系統使用。但是在 Windows 2000 及更新版系統上,所有版本的作業系統都具有鏡像認知的功能,讓您能夠輕鬆地建立鏡像的應用程式。

若要避免混淆座標,請嘗試將左右的概念換成遠近。鏡像實際上只是座標的轉換而已:

  • 原點 (0,0) 位於視窗的「右」上角
  • X 刻度因子 = -1 (也就是 X 的值由右向左增加)

下圖說明座標從 LTR 轉換成 RTL:

為了將應用程式需要重新寫入以支援鏡像的部份減到最低,系統元件 (如 GDI 和 User) 已經經過修改以開啟和關閉鏡像,因此除了主控描繪的控制項和點陣圖之外,不需再更動到其他的程式碼。

如需詳細資訊,請參閱視窗功能中的視窗配置和鏡像 (Window Layout and Mirroring)。

Unicode

所有的應用程式有時都需要處理文字或數值資料。在過去,不同文化特性/地區設定的語言需求,意味著在應用程式內部使用不同的編碼方式來表示這個資料。這些編碼方式讓作業系統和應用程式的程式碼基底變得非常沒有組織 (歐洲語言採用單位元組版本,東亞語言採用雙位元組版本,而中東語言採用雙向版本)。這種不一致的現象造成資料的共用不易,甚至更難以支援多語系 UI。

全球化的目的在於撰寫可在任何支援的文化特性/地區設定下正常運作的程式碼,因此,您的產品必須具備能夠以唯一方式表示所有必要文化特性/地區設定中每個字元的資料編碼方式結構描述 (Schema)。Unicode 正符合這些需求。

Unicode 可以讓您在同一個資料流中儲存不同的語言。這種編碼方式可表示 64,000 個以上的字元。Surrogate 推出後,能夠表示 1,000,000,000 個以上的字元。Windows 中使用 Unicode 有助於建立多語系的程式碼,因為您不再需要參考字碼頁或字元指標群組來表示一個字元。

Unicode 是一種 16 位元的國際字元編碼方式,涵蓋超過 45,000 個字元的值 (還有空間可容納 100 多萬個字元值)。Unicode 文字通常比其他編碼方式的文字更容易處理,也不需要記錄哪些字元已經編碼和產生字元的編碼方式結構描述。

注意   能使用 Unicode 的產品仍未完全全球化。其實,讓您的程式碼能使用 Unicode 只是全球化工作的十分之一。

Windows 2000 使用 Unicode 編碼方式來表示所有的國際字元,即可支援 64 種以上的指令碼和數百種語言。

請參閱

全球化和當地語系化的問題

顯示: