char c = L"a"; 

只允許從 U+0000 到 U+007F (7 位 ASCII) 范圍里的字符. 對(duì)于非 ASCII 字符, 不能直接從 wchar_t 到 char 轉(zhuǎn)換.

現(xiàn)在, 象 readline() 這樣的函數(shù)在 UTF-8 locale 下也能工作了.

怎樣激活 UTF-8 模式?

如果你的應(yīng)用程序既支持 8 位字符集 (ISO 8859-*,KOI-8,等等), 也支持 UTF-8, 那么它必須通過某種方法以得知是否應(yīng)使用 UTF-8 模式. 幸運(yùn)的是, 在未來的幾年里, 人們將只使用 UTF-8, 因此你可以將它作為默認(rèn), 但即使如此, 你還是得既支持傳統(tǒng) 8 位字符集, 也支持 UTF-8.

當(dāng)前的應(yīng)用程序使用許許多多的不同的命令行開關(guān)來激活它們各自的 UTF-8 模式, 例如:

• xterm 命令行選項(xiàng) "-u8" 和 X resource "XTerm*utf8:1"
• gnat/gcc 命令行選項(xiàng) "-gnatW8"
• stty 命令行選項(xiàng) "iutf8"
• mined 命令行選項(xiàng) "-U"
• xemacs elisp 包裹 以在 UTF-8 和內(nèi)部使用的 MULE 編碼間轉(zhuǎn)換
• vim 'fileencoding' 選項(xiàng)
• less 環(huán)境變量 LESSCHARSET=utf-8

記住每一個(gè)應(yīng)用程序的命令行選項(xiàng)或其他配置方法是非常單調(diào)乏味的, 因此急需某種標(biāo)準(zhǔn)方法.

如果你在你的應(yīng)用程序里使用硬轉(zhuǎn)換, 并使用某種特定的 C 庫函數(shù)來處理外部字符編碼和內(nèi)部使用的 wchar_t 編碼的轉(zhuǎn)換工作, 那么 C 庫會(huì)幫你處理模式切換的問題. 你只需將環(huán)境變量 LC_CTYPE 設(shè)為正確的 locale, 例如, 如果你使用 UTF-8, 那就是en.UTF-8, 而如果是 Latin-1, 并需要英語的轉(zhuǎn)換, 則設(shè)為 en.ISO_8859-1.

然而, 大多數(shù)現(xiàn)存軟件的維護(hù)者選擇用軟轉(zhuǎn)換來代替, 而不使用 libc 的寬字符函數(shù), 不僅因?yàn)樗鼈冞€未得到廣泛應(yīng)用, 還因?yàn)檫@會(huì)使得軟件進(jìn)行大規(guī)模修改. 在這種情況下, 你的應(yīng)用程序必須自己來獲知何時(shí)使用 UTF-8 模式. 一種方式是做以下工作:

按照環(huán)境變量 LC_ALL, LC_CTYPE, LANG 的順序, 尋找第一個(gè)有值的變量. 如果該值包含 UTF-8 子串 (也許是小寫或沒有"-") 則默認(rèn)為 UTF-8 模式 (仍然可以用命令行開關(guān)來重設(shè)), 因?yàn)檫@個(gè)值可靠又恰當(dāng)?shù)刂甘玖?C 庫應(yīng)該使用一種 UTF-8 locale.

提供一個(gè)命令行選項(xiàng) (或者如果是 X 客戶程序則用 X resource 的值) 將仍然是有用的, 可以用來重設(shè)由 LC_CTYPE 等環(huán)境變量指定的默認(rèn)值.

我怎樣才能得到 UTF-8 版本的 xterm?

在 XFree86 里帶的 xterm 版本最近已經(jīng)由 Thomas E. Dickey 加入了支持 UTF-8 的擴(kuò)展. 使用方法是, 獲取 xterm patch #119 (1999-10-16) 或更新版本, 用 "./configure --enable-wide-chars ; make" 來編譯, 然后用命令行選項(xiàng) -u8 來調(diào)用 xterm, 使它將輸入輸出轉(zhuǎn)換為 UTF-8. 在 UTF-8 模式里使用一個(gè) *-ISO10646-1 字體. 當(dāng)你在 ISO 8859-1 模式里時(shí)也可以使用 *-ISO10646-1 字體, 因?yàn)?ISO 10646-1 字體與 ISO 8859-1 字體是完全向后兼容的.

新的支持 UTF-8 的 xterm 版本, 以及一些 ISO 10646-1 字體, 將被收錄入 XFree86 4.0 版里.

xterm 支持組合字符嗎?

Xterm 當(dāng)前只支持級(jí)別1的 ISO 10646-1, 就是說, 不提供組合字符的支持. 當(dāng)前, 組合字符將被當(dāng)作空格字符對(duì)待. xterm 將來的修訂版很有可能加入某些簡(jiǎn)單的組合字符支持, 就是僅僅將那個(gè)有一個(gè)或多個(gè)組合字符的基字符加粗 (logical OR-ing). 對(duì)于在基線以下的和在小字符上方的重音符來說, 這樣處理的結(jié)果還是可以接受的. 對(duì)于象泰國文字體那樣使用特別設(shè)計(jì)的加粗字符的文字, 這樣處理也能工作的很好. 然而, 對(duì)于某些字體里, 在較高的字符上方組合上的重音符, 特別是對(duì)于 "fixed" 字體族, 產(chǎn)生的結(jié)果就不完全令人滿意了. 因此, 在可用的地方, 應(yīng)該繼續(xù)優(yōu)先使用預(yù)作字符.

xterm 支持半寬與全寬 CJK 字體嗎?

Xterm 當(dāng)前只支持那種所有字形都等寬的 cell-spaced 的字體. 將來的修訂版很有可能為 CJK 語言加入半寬與全寬字符支持, 類似于 kterm 提供的那種. 如果選擇的普通字體是 X×Y 象素大小, 且寬字符模式是打開的, 那么 xterm 會(huì)試圖裝入另外的一個(gè) 2X×Y 象素大小的字體 (同樣的 XLFD, 只是 AVERAGE_WIDTH 屬性的值翻倍). 它會(huì)用這個(gè)字體來顯示所有在 Unicode Technical Report #11 里被分配了East Asian Wide (W) 或 East Asian FullWidth (F) 寬度屬性的 Unicode 字符. 下面這個(gè) C 函數(shù)用來測(cè)試一個(gè) Unicode 字符是否是寬字符并需要用覆蓋兩個(gè)字符單元的字形來顯示:

  /* This function tests, whether the ISO 10646/Unicode character code
   * ucs belongs into the East Asian Wide (W) or East Asian FullWidth
   * (F) category as defined in Unicode Technical Report #11. In this
   * case, the terminal emulator should represent the character using a
   * a glyph from a double-wide font that covers two normal (Latin)
   * character cells. */

  int iswide(int ucs)
  {
    if (ucs < 0x1100)
      return 0;

    return
      (ucs >= 0x1100 && ucs <= 0x115f) || /* Hangul Jamo */
      (ucs >= 0x2e80 && ucs <= 0xa4cf && (ucs & ~0x0011) != 0x300a &&
       ucs != 0x303f) ||                     /* CJK ... Yi */
      (ucs >= 0xac00 && ucs <= 0xd7a3) || /* Hangul Syllables */
      (ucs >= 0xf900 && ucs <= 0xfaff) || /* CJK Compatibility Ideographs */
      (ucs >= 0xfe30 && ucs <= 0xfe6f) || /* CJK Compatibility Forms */
      (ucs >= 0xff00 && ucs <= 0xff5f) || /* Fullwidth Forms */
      (ucs >= 0xffe0 && ucs <= 0xffe6);
  }

某些 C 庫也提供了函數(shù)

  #include <wchar.h>
  int wcwidth(wchar_t wc);
  int wcswidth(const wchar_t *pwcs, size_t n);

用來測(cè)定該寬字符 wc 或由 pwcs 指向的字符串中的 n 個(gè)寬字符碼 (或者少于 n 個(gè)寬字符碼, 如果在 n 個(gè)寬字符碼之前遇到一個(gè)空寬字符的話) 所要求的列位置的數(shù)量. 這些函數(shù)定義在 Open Group 的 Single UNIX Specification 里. 一個(gè)拉丁/希臘/斯拉夫/等等的字符要求一個(gè)列位置, 一個(gè) CJK 象形文字要求兩個(gè), 而一個(gè)組合字符要求零個(gè).

最終 xterm 是否會(huì)支持從右到左的書寫?

此刻還沒有給 xterm 增加從右到左功能的計(jì)劃. 希伯來與阿拉伯用戶因此不得不靠應(yīng)用程序在將希伯來文與阿拉伯文字符串送到終端前按左方向翻轉(zhuǎn)它們, 換句話說, 雙向處理必須在應(yīng)用程序里完成, 而不是在 xterm 里. 至少, 希伯來與阿拉伯文在預(yù)作字形的可用性的形式上, 以及提示表格上的支持, 比 ISO 8859 要有所改進(jìn). 現(xiàn)在還遠(yuǎn)沒有決定 xterm 是否支持雙向文字以及該怎樣工作. ISO 6429 = ECMA-48 和 Unicode bidi algorithm 都提供了可供選擇的開始點(diǎn). 也可以參考 ECMA Technical
Report TR/53. Xterm 也不處理阿拉伯文, Hangul 或 印度文本的格式化算法, 而且現(xiàn)在還不太清楚在 VT100 模擬器里處理是否可行和值得, 或者應(yīng)該留給應(yīng)用軟件去處理. 如果你打算在你的應(yīng)用程序里支持雙向文字輸出, 看一下 FriBidi, Dov Grobgeld 的 Unicode 雙向算法的自由實(shí)現(xiàn).

我在哪兒能找到 ISO 10646-1 X11 字體?

在過去的幾個(gè)月里出現(xiàn)了相當(dāng)多的 X11 的 Unicode 字體, 并且還在快速增多.

• Markus Kuhn 正和其他許多志愿者一起工作于手動(dòng)將舊的 -misc-fixed-*-iso8859-1 字體擴(kuò)展到覆蓋所有的歐洲字符表 (拉丁, 希臘, 斯拉夫, 國際音標(biāo)字母表. 數(shù)學(xué)與技術(shù)符號(hào), 某些字體里甚至有亞美尼亞語, 喬治亞語, 片假名等). 更多信息請(qǐng)參考 Unicode fonts and tools for X11 頁. 這些字體將與 XFree86 一起分發(fā). 例如字體

    -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
  

  (舊的 xterm 的 fixed 缺省字體的一個(gè)擴(kuò)展, 包括超過 3000 個(gè)字符) 已經(jīng)是 XFree86 3.9 snapshot 的一部分了.

• Markus 也做好了 X11R6.4 distribution 里所有的 Adobe 和 B&H BDF 字體的 ISO 10646 版本. 這些字體已經(jīng)包含了全部 Postscript 字體表 (大約 30 個(gè)額外的字符, 大部分也被 CP1252 MS-Windows 使用, 如 smart quotes, dashes 等), 在 ISO 8859-1 編碼下是沒有的. 它們?cè)?ISO 10646-1 版本里是完全可用的.
• XFree86 4.0 將攜帶一個(gè)集成的 TrueType 字體引擎, 這使得你的 X 應(yīng)用程序可以將任何 Apple/Microsoft 字體用于 ISO 10646-1 編碼.
• 將來的 XFree86 版本很有可能從分發(fā)版中去除大多數(shù)舊的 BDF 字體, 取而代之的是 ISO 10646-1 編碼的版本. X 服務(wù)器則會(huì)增加一個(gè)自動(dòng)編碼轉(zhuǎn)換器, 只有當(dāng)舊的 8 位軟件請(qǐng)求一個(gè)類似于 ISO 8859-* 編碼的字體時(shí), 才虛擬地從 ISO 10646-1 字體文件中創(chuàng)建一個(gè)這樣的字體. 現(xiàn)代軟件應(yīng)該優(yōu)先地直接使用 ISO 10646-1 字體編碼.
• ClearlyU (cu12) 是一個(gè)非常有用的 X11 的 12 點(diǎn)陣, 100 dpi 的 proportional ISO 10646-1 BDF 字體, 包含超過 3700 個(gè)字符, 由 Mark Leisher 提供 (樣例圖象).
• Roman Czyborra 的 GNU Unicode font 項(xiàng)目工作于收集一個(gè)完整的與免費(fèi)的 8×16/16×16 pixel Unicode 字體. 目前已經(jīng)覆蓋了 34000 個(gè)字符.
• etl-unicode 是一個(gè) ISO 10646-1 BDF 字體, 由 Primoz Peterlin 提供.

Unicode X11 字體名字以 -ISO10646-1 結(jié)尾. 這個(gè) X 邏輯字體描述器 (X Logical Font Descriptor, XLFD) 的 CHARSET_REGISTRY 和 CHARSET_ENCODING 域里的值已經(jīng)為所有 Unicode 和 ISO 10646-1 的 16 位字體而正式地注冊(cè)了. 每個(gè) *-ISO10646-1 字體都包含了整個(gè) Unicode 字符集里的某幾個(gè)子集, 而用戶必須弄清楚他們選擇的字體覆蓋哪幾個(gè)他們需要的字符子集.

*-ISO10646-1 字體通常也指定一個(gè) DEFAULT_CHAR 值, 指向一個(gè)非 Unicode 字形, 用來表示所有在該字體里不可用的字符 (通常是一個(gè)虛線框, 一個(gè) H 的大小, 位于 0x1F 或 0xFFFE). 這使得用戶至少能知道這兒有一個(gè)不支持的字符. xterm 用的小的定寬字體比如 6x13 等, 將永遠(yuǎn)無法覆蓋所有的 Unicode, 因?yàn)樵S多文字比如日本漢字只能用比歐洲用戶廣泛使用的大的象素尺寸才能表示. 歐洲使用的典型的 Unicode 字體將只包含大約 1000 到 3000 個(gè)字符的子集.

我怎樣才能找出一個(gè) X 字體里有哪些字形?

X 協(xié)議無法讓一個(gè)應(yīng)用程序方便地找出一個(gè) cell-spaced 字體提供哪些字形, 它沒有為字體提供這樣的量度. 因此 Mark Leisher 和 Erik van de Poel (Netscape) 指定了一個(gè)新的 _XFREE86_GLYPH_RANGES BDF 屬性, 告訴應(yīng)用程序該 BDF 字體實(shí)現(xiàn)了哪個(gè) Unicode 子集. Mark Leisher 提供了一些樣例代碼以產(chǎn)生并掃描這個(gè)屬性, 而 Xmbdfed 3.9 以及更高版本將自動(dòng)將其加入到由它產(chǎn)生的每個(gè) BDF 文件里.

與 UTF-8 終端模擬器相關(guān)的問題是什么?

VT100 終端模擬器接受 ISO 2022 (=ECMA-35) ESC 序列, 用于在不同的字符集間切換.

UTF-8 在 ISO 2022 的意義里是一個(gè) "其他編碼系統(tǒng)" (參考 ECMA 35 的 15.4 節(jié)). UTF-8 是在 ISO 2022 SS2/SS3/G0/G1/G2/G3 世界之外的, 因此如果你從 ISO 2022 切換到 UTF-8, 所有的 SS2/SS3/G0/G1/G2/G3 狀態(tài)都變得沒有意義了, 直到你離開 UTF-8 并切換回 ISO 2022. UTF-8 是一個(gè)沒有國家的編碼, 也就是一個(gè)自我終結(jié)的短字節(jié)序列完全決定了它代表什么字符, 獨(dú)立于任何國家的切換. G0 與 G1 在 ISO 10646 里與在 ISO 8859-1 里相同, 而 G2/G3 在 ISO 10646 里不存在, 因?yàn)槿魏巫址加泄潭ǖ奈恢? 因而不會(huì)發(fā)聲切換. 在 UTF-8 模式下, 你的終端不會(huì)因?yàn)槟闩既坏匮b入一個(gè)二進(jìn)制文件而切換入一種奇怪圖形字符模式. 這使得一個(gè)終端在 UTF-8 模式下比在 ISO 2022 模式下要健壯得多, 而且因此可以有辦法將終端鎖在 UTF-8 模式里, 而不會(huì)偶然地回到 ISO 2022 世界里.

ISO 2022 標(biāo)準(zhǔn)指定了一系列的 ESC % 序列, 以離開 ISO 2022 世界 (指定其他的編碼系統(tǒng), DOCS), 用于 UTF-8 的許多這樣的序列已經(jīng)注冊(cè)進(jìn)了 ISO 2375 International Register of Coded Character Sets:

• ESC %G 從 ISO 2022 里激活一個(gè)未指定實(shí)現(xiàn)級(jí)別的 UTF-8 模式且允許再返回 ISO 2022.
• ESC %@ 從 UTF-8 回到 ISO 2022, 條件是通過 ESC %G 進(jìn)入的 UTF-8
• ESC %/G 切換進(jìn) UTF-8 級(jí)別 1 且不返回.
• ESC %/H 切換進(jìn) UTF-8 級(jí)別 2 且不返回.
• ESC %/I 切換進(jìn) UTF-8 級(jí)別 3 且不返回.

當(dāng)一個(gè)終端模擬器在 UTF-8 模式時(shí), 任何 ISO 2022 逃脫碼序列例如用于切換 G2/G3 等的都被忽略. 一個(gè)在 UTF-8 模式下的終端模擬器唯一會(huì)執(zhí)行的 ISO 2022 序列是 ESC %@ 以從 UTF-8 返回 ISO 2022 方案.

UTF-8 仍然允許你使用象 CSI 這樣的 C1 控制字符, 盡管 UTF-8 也使用 0x80-0x9F 范圍里的字節(jié). 重要的是必須理解在 UTF-8 模式下的終端模擬器必須在執(zhí)行任何控制字符前對(duì)收到的字節(jié)流運(yùn)用 UTF-8 解碼器. C1 字符與其他任何大于 U+007F 的字符一樣需先經(jīng)過 UTF-8 解碼.

已經(jīng)有哪些支持 UTF-8 的應(yīng)用程序了?

• Yudit 是 Gaspar Sinai 的自由 X11 Unicode 編輯器
• Mined 98 由 Thomas Wolff 提供, 是一個(gè)可以處理 UTF-8 的文本編輯器.
• less 版本 346 或更高, 支持 UTF-8
• C-Kermit 7.0 在傳輸, 終端, 及文件字符集方面支持 UTF-8.
• Sam 是 Plan9 的 UTF-8 編輯器, 類似于 vi, 也可用于 Linux 和 Win32. (Plan9 是第一個(gè)完全轉(zhuǎn)向 UTF-8, 將其作為字符編碼的操作系統(tǒng).)
• 9term 由 Matty Farrow 提供, 是一個(gè) Plan9 操作系統(tǒng)的 Unicode/UTF-8 終端模擬器的 Unix 移植.
• Wily 是一個(gè) Plan9 Acme 編輯器的 Unix 實(shí)現(xiàn).
• ucm-0.1 是 Juliusz Chroboczek 的 Unicode 字符映射表, 一個(gè)小工具, 使你可以選中任何一個(gè) Unicode 字符并粘貼進(jìn)你的應(yīng)用程序.

有哪些用于改善 UTF-8 支持的補(bǔ)丁?

• Robert Brady 提供了一個(gè) patch for less 340 (現(xiàn)在已經(jīng)合并進(jìn)了 less 344)
• Bruno Haible 提供了用于 stty, Linux 核心 tty 等的 多個(gè)補(bǔ)丁.
• Otfried Cheong 編寫了 Unicode encoding for GNU Emacs 工具箱, 使 Mule 能夠處理 UTF-8 文件.

Postscript 字形的名字與 UCS 代碼是怎么關(guān)聯(lián)的?

參考 Adobe 的 Unicode and Glyph Names 指南.

X11 的剪切與粘貼工作在 UTF-8 時(shí)是如何完成的?

參考 Juliusz Chroboczek 的 客戶機(jī)間 Unicode 文本的交換 草案, 對(duì) ICCCM 的一個(gè)擴(kuò)充的建議, 用一個(gè)新的可用于屬性類型(property type)和選中(selection)目標(biāo)的原子 UTF8_STRING 來處理 UTF-8 的選中.

現(xiàn)在有沒有用于處理 Unicode 的免費(fèi)的庫?

• IBM Classes for Unicode
• Mark Leisher 的 UCData Unicode 字符屬性庫和 wchar_t 支持測(cè)試碼.

各種 X widget 對(duì) Unicode 支持的現(xiàn)狀如何?

• GScript - Unicode 與復(fù)雜文本處理 是一個(gè)為 GTK+ 增加全功能的 Unicode 支持的項(xiàng)目.
• Qt 2.0 現(xiàn)在支持使用 *-ISO10646-1 字體了.
• FriBidi 是 Dov Grobgeld 的 Unicode 雙向算法的免費(fèi)實(shí)現(xiàn).

有什么關(guān)于這個(gè)話題的好的郵件列表?

你確實(shí)應(yīng)該訂閱的是 unicode@unicode.org 郵件列表, 這是發(fā)現(xiàn)標(biāo)準(zhǔn)的作者和其他許多領(lǐng)袖的話語的最好辦法. 訂閱方法是, 用 "subscribe" 作為標(biāo)題, "subscribe YOUR@EMAIL.ADDRESS unicode" 作為正文, 發(fā)一條消息到 unicode-request@unicode.org.

也有一個(gè)專注與改進(jìn)通常用于 GNU/Linux 系統(tǒng)上應(yīng)用程序的 UTF-8 支持的郵件列表 linux-utf8@nl.linux.org. 訂閱方法是, 以 "subscribe linux-utf8" 為內(nèi)容, 發(fā)送消息到 majordomo@nl.linux.org. 你也可以瀏覽 linux-utf8 archive

其他相關(guān)的還有 XFree86 組的 "字體" 與 "i18n" 列表, 但你必須成為一名正式的開發(fā)者才能訂閱.

更多參考

• Bruno Haible 's Unicode HOWTO.
• The Unicode Standard, Version 2.0
• Unicode Technical Reports
• Mark Davis' Unicode FAQ
• ISO/IEC 10646-1:1993
• Frank Tang's I?t?rnati?nàliz?ti?n Secrets
• Unicode Support in the Solaris 7 Operating Environment
• The USENIX paper by Rob Pike and Ken Thompson on the introduction of UTF-8 under Plan9 reports about the first operating system that migrated already in 1992 completely to UTF-8 (which was at the time still called UTF-2).
• Li18nux is a project initiated by several Linux distributors to enhance Unicode support for Linux.
• The Online Single Unix Specification contains definitions of all the ISO C Amendment 1 function, plus extensions such as wcwidth().
• The Open Group's summary of ISO C Amendment 1.
• GNU libc
• The Linux Console Tools
• The Unicode Consortium character database and character set conversion tables are an essential resource for anyone developping Unicode related tools.
• Other conversion tables are available from Microsoft and Keld Simonsen's WG15 archive.
• Michael Everson's ISO10646-1 archive contains online versions of many of the more recent ISO 10646-1 amendments, plus many other goodies. See also his Roadmaps to the Universal Character Set.
• An introduction into The Universal Character Set (UCS).
• Otfried Cheong's essey on Han Unification in Unicode
• The AMS STIX project is working on revising and extending the mathematical characters for Unicode 4.0 and ISO 10646-2.
• Jukka Korpela's Soft hyphen (SHY) - a hard problem? is an excellent discussion of the controversy surrounding U+00AD.
• James Briggs' Perl, Unicode and I18N FAQ.

我不斷地將新的材料加入這份文檔, 因此請(qǐng)定期來查看. 歡迎所有關(guān)于改進(jìn)的建議, 以及自由軟件社區(qū)里關(guān)于改善 UTF-8 支持的廣告. UTF-8 用在 Linux 里是新近的事, 因此我們?cè)趯淼膸讉€(gè)月里可以見到大量的進(jìn)展.

特別感謝 Ulrich Drepper 和 Bruno Haible 的有價(jià)值的注解

Markus Kuhn <<Markus.Kuhn@cl.cam.ac.uk>
創(chuàng)建于 1999-06-04 -- 最近更新于 2000-01-15 -- http://www.cl.cam.ac.uk/~mgk25/unicode.html