全型字（Full-Width）、半型字（Half-Width）

以往在 Unicode 不普及的時候，我們的地方編碼裡頭就有全型及半型之分，例如英文字母 a 這是半型，但在我們 Big-5 碼中也有相對的全型的字母 ａ。半型的 a 是 one byte，全型的 ａ，是 two bytes。

但是，這其實和幾個 byte 無關，而是半型是佔字型的 em 框的一半寬度，全型字則是佔字型 em 框的整個寬度。否則目前的 UTF-8 編碼，中文字豈不是都是一又二分之一型？或更寬的型？所以，目前 Unicode 並不全依這個來分類字型寬度，而是有許多情況，需視所在的內文是屬於什麼 locale 來做寬度調整的。

在 Unicode 裡頭是只編碼位，而不涉及 glyph 本身的形狀，因而會有些字寬不確定的情況（Ambiguous）。有些以往半型、全型的字都有編兩個碼位給他，例如上述的英文字母 a，有些則沒有，例如 U00A7 這個 section 符號，就只有一個碼位。因此。在  EastAsianWidth.txt 裡頭，是標示為 A（Ambiguous）。他是要佔 em size 的一半或是整個，要視字型製作者而定，要給東方語系用的字型，會造成全型，要給西方語系用的字型，會造成半型。

這是在討論一些終端機模擬程式時會碰到的問題，尤其是要連進 bbs 系統裡頭的時候，這個沒分清楚，那麼畫面就會亂掉，那要如何解決呢？據我目前所知，並沒有完整解決方案，只能說我們要進 bbs 的，要用特定的字型，把半型、全型字造正確，而且，bbs server 這端也要依相同的規則來分辨是半型或者是全型，否則就會天下大亂。

很多人倡言 bbs 該改用 UTF-8 編碼，使用 Big-5 已經落伍了，這很好，但請這些人士，告訴我們該如何解決這個問題先。 

參考資料：

 http://www.unicode.org/reports/tr11/tr11-15.html

補充一下，EastAsianWidth.txt 中的字寬分類有六種：

A：Ambihuous
F：Full Width
H：Half Width
Na：Narrow
W：Wide
N：Neutral（Not East Assian）

以東方語系而言（其實所有語系都一樣），我們主要是把全型、半型分清楚。當然，這些是指需要等寬字的場合，如果是比例調合字的場合，那麼問題比較少。
 

剛好想到，如果有辦法去㧓使用者用來顯示的 font/fontset 的字元寬度，然後限制列寬為 XX ，超過就換行，這樣看起來好像可行，只是感覺效能可能會不太好。

想歸想，我不會寫程式

應該是有困難，因為使用者也搞不清楚 char map，是系統幫他配對的，而從一開始的 Unicode mapping 定義就 ambiguous 了，所以目前有困難。只能用 OTF 的特性，或軟體自行處理，發生不對時，由使用者去調整切換（gvim 就是這樣處理的）。

另外使用者的字型，我們無法確定誰會用哪一種。自行去偵測字型的內容的話，好像可行，但會拖慢速度，像以前用偵測字的 bounding box 用在排版系統的做法都已經被揚棄了，因為不太優雅。

嗯，雖然是笨方法，但這是我想得到最不需要使用者費心的方法了。速度慢的話，加個 cache 也許有幫助？

或者，折衷一下，把 unicode 中有明確寬度的字元 (narrow, wide, half-width, full-width) 按標準顯示，ambiguous 的字元，再用字型判斷，或者在 bbs 中加入類似 html lang 屬性的判斷，以使用的語言場合來判斷 ambiguous 字元的寬度。而 neutral 字元，unicode 好像建議處理成 narrow，照辦不知道會不會有問題。

我想應該這種方式以目前的情形是不會有人去用的。因為有其他的方式可行。

困難往往不是來自技術問題。Unicode 當初會定義出 ambiguous 字元，就可以知道，這個問題是多麼困擾，多麼不「統一」了。試想想看，在還沒有「統一碼」（Unicode）的時代，為什麼不會有這種問題？所以，這跟本就不是技術上的問題，問題是出在 ambiguous 字元，碰到的人（不是寫程式的人）想怎麼表現的問題。

也就是說為了 bbs，就只是針對 bbs 這個軟體去解決，像 gvim 的解決方式一樣。其實 gvim 怎麼解決，就照著辦就是一種不錯的方式，至少，你要自動的話，就固定的寬字元就成了。但是碰到把這些寬字元造字成半型的字型，這要怎麼去表現就要另外特別處理了。

至於 bbs 系統，說穿了也是人的問題，他是全國連線的，你無法說動全國所有 bbs 的管理者改程式，甚至有許多的 bbs 管理者並沒有這種能力，你改好好的，人家不見得領情就更換。

我瞭解我的盲點在那裡了，原來是搞錯問題

那篇「gvim 的怪字型」，其實以前學 vim 的時候有看過，不過以前不知道那是是什麼問題，現在懂了。

這個我倒不怎麼在意，有 unicode 需求的，或者在意 unicode 支援的，自然會想辦法解決，技術能力不足，呵呵，不干我事，他們應該都懂得比我多吧。如果有人不想加上 unicode 支援的，認為 bbs 沒這個需求，沒必要換，這也 ok 啊，不是所有站都一定要用 unicode 的，夠用就好啦～

目前 bbs 最普遍的做法是轉碼，但事實上有些碼是不可逆的，所以仍然會有細節問題。而且，這樣一來，不支援 Unicode 的 bbs 站就無法連線，也就失去 bbs 原來全國連線的目的，變成是一個獨立的 group（就像目前的 ptt），但是獨立的 group 的時候，顯然 bbs 的功能無法滿足多數族群的需求（如圖檔、影音），所以，目前 bbs 會沒落，不是沒有原因的，把 bbs 的連線強項拿掉了，終究是把餅愈做愈小直至消失。

也因此，這個問題想去解決的人並不多，bbs 相對於 web 界面，已經形成了小眾文化了。連我這個老 bbs 人口也不願在 ptt 註冊，因為就是他們的策略，使得 bbs 全國連線沒落的。