UTF-8 Notes

Terminal/screen

參照小光光學長的文章來設定一個 app-transparent 的 Big5 <-> UTF-8 terminal. 該文章和其中 reference 到 yjchou 的 screen with utf8 都提到當透過 screen 把原先 Big5 的輸出轉為 UTF-8 時，對於許多符號的輸出與轉換會出現慘不忍睹的情況。稍微找了一下原因，發現問題出在相當多的環節，錯也不在任何一個地方。但在 Big5 尚未成為非主流之前，也只能想辦法讓這問題得到暫解。

screen 在 mlterm 中顯示 Unicode 文字

screen 有個 Big5 和 UTF-8 的對應表，裡面把每一個 Big5 -> UTF-8 作對應。screen 可以把 Big5 轉出成 UTF-8 給 UTF8-capable 的 terminal, 而從 terminal 餵進 Unicode 字元也會嘗試被 map 回 Big5, 若遇到對應不到的情況則輸出問號。我們必須為每個 Big5 的字都找到對應的 Unicode, 否則當我們使用到未對應到的字元時就會發生轉不出來的情形。舉例來說，如

○ ● △ ▲ ◎ ☆ ★ ◇ ◆ □ ■ ▽ ▼

這些會出問題的符號，只能夠對應到 Unicode 中的 0x25** 和 0x26** (參照 http://www.unicode.org/charts/ 的 Box Drawing,Block Elements, 和 Geometric Shapes 等等)。看起來沒有什麼問題，但這些符號是 half width 還是 full width, 各家都沒有一致的說法; 以 Big5 來說，所有的 Big5 都是 full width (wide char), 所以 Big5 ASCII Art 都是在這標準下畫出來的。就我手上有做 CJK Planes 的 Unicode TTF 來說，MSung Light TC (StarOffice 附的), PMingLiU (Windows), SimSun (Windows), SimHei (Windows), Bitstream Cyberbit (Bitstream/Netscape), Arphic TTF (GPL'ed) 都是作成 full width. 而 Arial Unicode MS (Windows), Andale Sans UI (StarOffice), Andale WT UI (StarOffice) 以及所有其他沒有做 CJK 的 Unicode TTF 都是作成 half width. 有 CJK 的字形需要這些符號，而我們也習慣於它們是 full width. 沒有 CJK 的字型自然也沒有理由把它們當成 full width 來用。這些符號在 Unicode 中不是 CJK 專屬的，是大家共用的。這在一般軟體 (如文書處理軟體) 當中不會有問題，因為這些軟體本來就允許 variable width 的字。但在 terminal 下，尤其是許多憑藉這些字元的固定寬度的環境之中，就必須有明確的定義。

Br0ken Big5 to UTF-8 conversion

UTF-8 <-> Big5

目前手邊支援 UTF-8 顯示的 terminal 大致有 gnome-terminal 與 mlterm, 其中 gnome-terminal 和 mlterm 對於 variable width 的文字處理方式不同，gnome-terminal 在一些方面還有問題，而 mlterm 需要設定:

mlterm/main

encoding = UTF-8
use_multi_column_char = true
col_size_of_width_a=1 (???)
not_use_unicode_font=true     
#only_use_unicode_font=false  (mlterm/aafont: ISO10646_UCS4_1_BIWIDTH=simhei-iso10646-1;)
use_variable_column_width = false

其中 col_size_of_width_a 根據文件中的說法是 Specify number of columns of Unicode characters with EastAsianAmbiguous property. 實際上看 cvs source code 的結果卻似乎沒有發現這個選項實質上在哪邊作用。很奇怪。設了和不設也沒有什麼差別。

not_use_unicode_font=true 的原因是我希望 mlterm 能夠把不同 encoding 的字分給不同 font 顯示，因為 fixed width 又有中文字的 TTF 通常 ISO8859-1 的字都不甚好看。自然設成了 false 就會只用 ISO10646_UCS*(_BIWIDTH) 的字型來顯示。(BIWIDTH 所設定的是寬字元所用的字型。在某種程度上還是可以分開設。) 值得注意的是 not_use_unicode_font 和 only_use_unicode_font 不能同時被設定。

mlterm/aafont

ISO8859_1=Luxi Mono-iso10646-1;
BIG5=SimHei-iso10646-1;
GB2312_80=SimHei-iso10646-1;
JISX0208_1978=Kochi Gothic-iso10646-1;
JISX0208_1983=Kochi Gothic-iso10646-1;
JISX0208_1990=Kochi Gothic-iso10646-1;

Luxi Mono 是最近的 XFree86 版本就有附上的字型。Kochi Gothic 是用來顯示日文假名的 free TTF, 品質很高，在 Debian 中是作成了 ttf-kochi-* 的套件。SimHei 是從 Windows 來的 simhei.ttf. Windows 另一套 Arial Unicode MS (arialuni.ttf) 擁有很大的 Unicode Coverage, 品質也很好，但上述所謂 Big5 和 Unicode 共享的特殊符號以及 box drawing 符號則是作成半形的，這在顯示 Big5 Art 會變成只有一半的寬度，所以沒有使用。

screen

Screen 的 Big5 -> UTF-8 互轉之間的問題是，screen 對於 Halfwidth/Fullwidth 有自己的一套定義。這代表 screen 在需要把某碼的字轉成 UTF-8 時，會把它認為不是 double width 的字轉出來之後再加一空白。參照 screen/encoding.c 的 source 可以得知。而那些 Big5 特殊符號在經過 screen 由 Big5 轉成 UTF-8 時，由於不在 screen 的 double width 定義裡頭，所以轉出來之後都附加了一個空白。配上 mlterm 使用 full width 的符號字型之後便慘不忍睹。但當 mlterm 使用的字是像 Arial Unicode MS 一類，把特殊符號作成半形的字時，藉由調整 use_variable_column_width 和 use_multi_column_char 選項可以讓寬度變成正常，但是因為字型本身是半形的，諸如 ──── 的線就會變成虛線，而其他的 ANSI Art 以及 BBS 上的 Bullet 也會一起毀掉。因此我 dirty hack 把這些符號也加進去，如下:

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

int
isb5full(c)
int c;
{
    return
        (c >= 0x00a7 && c <= 0x00f7) ||
        (c >= 0x02c7 && c <= 0x02d9) ||
        (c >= 0x0391 && c <= 0x03c9) ||
        (c >= 0x2013 && c <= 0x2642) ||
        (c == 0x300a || c == 0x300b) ;
}

不知道為何 screen 獨鍾 0x300a "《" 和 0x300b "》" 等。但經過這樣的修改，顯示這些特殊符號時就會很正常。

Big5 art with hacked screen

screen 的 Big5 日文假名對應原是錯的，修正 table 後，這些文字會對應到相應的 Unicode 日文區。而 mlterm 如果設定用不同的字型顯示不同字集，也就會用想要的字型來顯示 Big5 日文。

mlterm with big5 kana text

luit

XFree86 4.3 已經讓 xterm 在啟動的時候自動去執行 luit 做轉碼的工作。不過我不知道該如何設定 xterm 去分辨 double width 和 single width. luit 是一個有趣的轉碼程式，它不會像 screen 一樣在轉過來的途中附加一個空白，所以 Big5 特殊符號從 Big5 -> UTF-8 很正常。若是不用 xterm，可以在指定的 locale 環境下面單獨執行 luit. luit 沒有假名對應。對於一般使用是沒有什麼問題。

luit Big5 to UTF-8 conversion

yyt

yiyantang 也是一個有趣的轉碼終端機，它是用 libhz 來做轉碼的工作，還有自動判斷簡體/繁體編碼來做轉換的功能。可以在 Big5 <-> GB <-> UTF-8 <-> hanzi 等等之間自由互轉。也可以把輸入的文字轉成所需要的編碼，意思是可以藉由一個非 UTF-8 的 terminal, 與一個 zh_TW.Big5 的 xcin 來輸入 UTF-8 的文字。它的假名對應也是錯的，其他許多地方的對應也有點奇怪，不過只要藉由修改 libhz (zh-autoconvert) 的 source code 中的 table 就能解決了，我暫時沒去動它。

yiyantang Big5 to UTF-8 conversion

結語

無論用那種方式轉碼，畢竟只是權宜之計。例如 Big5 中有一區希臘字母是全形符號。當有天 terminal 中顯示出了一些希臘字母的編碼，用 screen 轉出來成為 Big5 便會全部變成全形字，這自然非我們所期盼的結果。由於 Unicode 裡面就那麼一區是 Greek Letters, 並沒有定義所謂全形希臘字區，只要繼續使用 Big5, 這種問題永遠不能夠解決。長遠來說，還是要使用統一的編碼，才可能同時使用各種不同語言的文字。

請指正。

Visitors' Comments:

Fatal error: Call to undefined function mysql_pconnect() in /home/eric/public_html/utf8note/db_connect.php on line 2