Big-5 Fundamental Functions Project

當一九九六年十月, 我正在教資料結構的課程 (那是我第一次擔任這門課的任課教師). 在講述 string 這個抽象資料結構的時候, 為了使同學們學習一些與中文有關的程式技術, 並且製造一些實際上有用的程式, 我決定把所有書上提到的 ASCII string 抽象結構, 統統改成 Big-5 string 的抽象結構.

剛開始的時候, 我隨意在黑板上寫下了基本的設計概要. 但是在實際以此結構設計程式的時候, 發現有修改的必要. 現在在此表現的設計結構, 是在九六年的十一月和十二月陸續定稿的.

其實, 這套基本功能程式的設計, 應該可以被我在前一年, 教計算機概論三 (後來改名為程式語言應用) 那門課程的時候開始設計的 S-Code 抽象資料結構所包含. 那麼, 為什麼要增加專門為五大碼 (Big-5) 設計的基本功能程式呢? 這並非是我要改弦易幟, 也非放棄宏大的 S-Code 理想, 而是向現實妥協了.

故事是這樣的. 一九九六年三月到七月之間, 我和當時二年級的陳韋辰同學合作開發了一個類似 grep 的中文字串搜尋程式. 我們稱之為 cgrep. 我把它當做是 S-Code 計劃中的一個例題 (我想藉由這些例題, 表演給別人看, S-Code 的內碼系統和基本功能程式可以有些什麼樣的用途). 七月初, 朋友童闓運先生把 cgrep 的 PC 可執行檔取走, 目的是幫助從事於佛典電子化的朋友處理他們龐大的佛典資料. 童先生很快地向我抱怨 cgrep 跑得太慢. 他說, 其實絕大部分的中文電子文件都是以 Big-5 碼儲存的, 而我的 cgrep 程式把它們全都翻譯成 S-Code 內碼才加以處理. 這太浪費時間了. 有多浪費時間呢? 我在七月三十日做了實驗. 我準備了一個含有七十萬個中國字 (以 Big-5 碼儲存) 的檔案, 用標準的 S-Code 程式讀入一遍, 花費的時間如下.

Real Time OS System Time CPU Time
1.7 1.6 0.0
如果完全不理會中文字碼的雙碼特性, 而只是單純地用 C 的 fgetc() 來讀一遍, 花費的時間如下.
Real Time OS System Time CPU Time
0.4 0.3 0.0
接著, 我寫了一個很單純的程式, 假設輸入的文字是標準無誤的 Big-5 夾雜 ASCII 的文字檔, 並且讀入後不轉換成 S-Code 內碼. 如此再讀一遍, 花費的時間如下.
Real Time OS System Time CPU Time
0.7 0.6 0.0
由此可見, 內碼轉換附加給程式的負擔, 的確頗重; 重達一倍. 如果應用程式本身就很複雜, 那麼輸入與輸出時因為轉碼所造成的額外負擔, 就可能相對地輕了一些. 否則, 轉碼步驟就宣賓奪主了. 如果輸入資料本身只是使用 Big-5 碼, 而且應用程式也並不複雜, 那麼似乎真的沒有必要做轉碼的額外動作.

有鑑於絕大部分的中文電子文件確實是以 Big-5 碼儲存, 我於是與此事實妥協, 決定與 S-Code 平行開發一套不轉碼的電子中文處理系統. 我認為, 一旦兩者的基礎部分都準備好了, 則在較上層寫應用程式的時候, 差別應該很小. 所以, 開發兩套系統所花費的時間, 應該遠小於開發一套系統的兩倍. 而且, 我並粗排除, 以後將這兩版程式合而為一的可能.

這一套 Big-5 基本功能程式的設計目標, 與 S-Code 是一致的. 簡單的說只有一個目標, 就是希望處理中文的程式寫作, 能夠愈接近處理西文的程式愈好. 如果這個目標能夠達成, 則我們在標準的程式語言, 資料結構, 演算法之類的基礎課程中所學習的處理西方文字資料的方法, 就可以很直接地應用在中文處理上.

為了達成這個目標, 最基本要做的就是: (1) 中國字每字一內碼; (2) 此內碼須與 ASCII 完全相容. 比如說, 以 C 程式語言為發展平臺者, '\n' 仍然是折行記號, '\0' 仍然是字串結束記號, EOF 仍然是檔案結束記號.

最新版本的 C 程式原始碼, 儲存在 big5eng.hBig5.c 檔案內. 但是, 除非我在這裡宣布它們是最後定稿的版本, 否則它們就隨時都有可能更改. 因為我只有在教課的時候才順便做這方面的工作, 所以, 即使它們停滯了一兩年沒有改變, 也不見得就是最後的定稿版本. 將它們取回使用的朋友們當瞭解這一點.

最後, 我建議您選擇閱讀以下幾種相關文件:


Created: Nov 17, 1996
Last Revised: Jan 16, 2002
© Copyright 1996, 2002 Wei-Chang Shann

shann@math.ncu.edu.tw