這篇其實很早就有草稿了，只是拖到最近才把它完成。
之前有談過如何設定 Gnu Screen 的方法，如果你常掛在 server 上，那應該對 Screen 這個好用的工具並不陌生。這篇主要是談怎麼 patch 它，來讓它支援 Unicode 補完計畫 (UAO)。
Unicode 補完計畫 (UAO) 對廣大的鄉民來說，可以說是再親切不過的了，BBS 電子佈告欄在台灣相當地盛行，但它底層僅僅支援 Big5，對於鄉民來說，看日文是件再正常不過的事了，但 Big5 畢竟是個急就章推出的編碼 (事實上，它也沒有一個既定的標準，唯一勉強可以稱得上標準的是 Big5-2003)，在當初的設計中並沒有加入日文假名等使用需求。所幸 Big5 有所謂的”使用者造字區”，提供給使用者自行定義新字，也有了後來的”倚天擴充字集”加入了包括日文假名等使用者特殊需求字。
然而，Windows 對於這塊由倚天自行定義的區域，在轉換成 Unicode 時也對應到了使用者造字區，而非它們各自對應到實際在 Unicode 的字，於是造成了 mapping 上的錯誤。UAO 便是為了解決這個問題而產生的，它做的事情只是將這段使用者造字區對應到 Unicode 正確的字。
上面說到的，是針對 Big5 <-> Unicode 的轉換發生在 Windows 的情況，可以利用安裝 UAO 來解決；但因為我的環境是 UTF-8，已經習慣用 Screen 提供的 Encoding Translation 功能來上 BBS 瀏覽文章了，但 Screen 預設提供的 Mapping Table 並沒有處理 UAO，因此這種轉換是在 Screen 內部的情況便無法靠安裝 UAO 來解決，所以必須 patch。
其實許多前輩們已經針對這個部份提供了 Screen 的 UAO patch 以及修正過的 Mapping Table，但他們提供的 Mapping Table 是以 UAO 2.42 所產生的 Binary 檔，這意味著我不清楚它是支援到 UAO 2.42 哪個程度，即使完整支援了 (這反而不好)，Binary 檔也代表它難以再編修和進 Version Control System。
所以我從 Firefox 3 的版本取出了內建的 Mapping Table 文字檔來做處理，Firefox 在 2 的版本已經內建單向處理 UAO 的功能了，所以可以取其 Big5 -> Unicode 單向的 Mapping Table 來做修改。修改後再利用轉換程式編成 Binary 檔便可替代原本 Screen 當中的 “18″ 檔 (也就是 Big5 <-> Unicode Mapping Table)。
利用修正過後的 Screen 便可看到在日文假名以及某些特殊字框的顯示正常很多了；但是實際使用後會發現一個問題，就是對於某些 Double Mapping 的字會優先轉換到 0×8140-0xA0FE 這段擴充區 (這裡所謂的 Double Mapping 是指多個 Big5 的字對應到同一個 Unicode 的字，例如 0xB86D 和 0×82AA 都是對應到 0×7F6E，一個是正常區的，另一個是擴充區的)，而在當初的 Mapping Table 文字檔便是依造 Big5 的字碼來排序，很不巧的 0×8140-0xA0FE 這段擴充區會放置在最前面；而又剛好 Screen 的 Mapping Table 是同時做雙向轉換的，針對這種 Double Mapping 的情況，它會以第一個找到的為優先，這便造成了某些不需 UAO 便可閱讀的字，變成需要 UAO 才能閱讀了，而這篇文章是你打的。解決方式便是將這段擴充區移到 Mapping Table 的最後面，讓正常區的字優先權較高。於是最後的 Mapping Table 表便誕生了，我在每行最後都有加上 UTF-8 所對應到的字。
最後的比較圖如下：
參考資料：
- http://moztw.org/docs/big5/
- Unicode 補完計畫
P.S. 其實 UAO 在本意上是良好的，但是作法我不太推崇，畢竟它不是一個標準，只是為了配合 BBS 所產生的過渡產物，所以讓 Screen 支援 UAO 僅是為了讓瀏覽 BBS 文章更方便而已，在其他環境下，我還是建議以 Unicode 為主，畢竟它是一個標準，支援度又高，Big5 就讓它慢慢走向歷史吧！
Recent Comments