Jserv's blog

中文簡繁轉換的複雜性

中文繁簡體轉換的議題，原本在我的觀點來說，應該是很多現成的軟體元件可以應用，而在查閱了一些資料後才發現，問題遠比想像中的複雜。稍早的 blog [漢字走向全球化的挑戰] 與 [繁簡轉換的議題] 有提到過去的一些發現，而我也是在認識 jie 之後，才開始正視這個議題的，同時，我也在今年的 Debian@Taiwan 社群計畫的 [WishList2005 / 夢幻軟體計畫] 提交了一個提案 [TSCC]，主要就是著眼二岸三地辭語對照與轉換，規範繁簡體中文用語轉換系統的基礎框架，昨天利用晚上的時間實做了一部分。

但是我總是發現困難重重，不僅難以擴充，更不知道該如何整合現有的中文輸出機制，而剛剛查閱 CJK.org 後，發現一篇論文 [The Pitfalls and Complexities of Chinese to Chinese Conversion] ，我將原本的中文版 [轉換成 PDF 文件]。不難發現，即便使用 Unicode 後，簡體與繁體中文可以並行使用，但衍生的問題才要開始。Unicode 的 CJK 表意文字區域規範了多數的 glyph，而不少應用程式，比方說 [OpenVanilla] 與 [SCIM] 著手提供了表格式的轉換，但還是只能針對單一 Unicode 漢字，但就實用的角度來說，至少我們還需要類似 [同文堂] 的詞語導向的轉換設計。

在這篇論文裡頭我們可以看到序言提到：

In 1996, the CJK Dictionary Institute (CJKI) launched a project to investigate these issues in-depth, and to build a comprehensive SC↔TC database (now at three million SC and TC entries) whose goal is to enable conversion software to achieve near 100% accuracy.

這樣的資料庫已經衝到上萬個詞條，就目前開放的實做來說，「新同文堂」(URL實在太分歧了，以至於我不知道該列出哪個) 還不到兩千條。就算今天我們能夠聚集網路上熱心朋友的貢獻，將對照詞彙表的數量累積到同樣的等級，就效率來說，是否能夠迎接拔山倒海的轉換資料量呢？我很好奇。

為了務實，我打算先將上述的議題擱置，改來寫 [gaim] 的一個 plugin，作為一個 testbed 來驗證 TSCC，初期已經有最簡單的表格式轉換，可以處理 in-coming/out-going messages 的轉換，稍後我會放到公開的 svn repository。
由 jserv 發表於 August 6, 2005 08:52 PM