《四庫全書》電子版工程與中文信息技術
The Engineering for Electronic Publication of Siku Quanshu
and Chinese Information Technology

張軸材

Abstract：In this article, author explored the engineering for Wenyuange Siku Quanshu Electronic Version, the largest Chinese electronic publication in the world, which is based on an extended CJK character set (CJK⁺) and developed with Single Data / Single Binary technique , running on Simplified / Traditional Chinese, Japanese, Korean and English Winows98 or Windows NT 4.0. The article also described how OCR technique is adopted to be converting hundreds millions handwritten Hanzi into coded characters, and how the Unicode/CJK⁺ based Full Text Retrieval system works with Variant Handling for the ancient Chinese document.

目錄

1. 工程背景與目標

(1)《四庫全書》
(2)《四庫全書》電子版
(3) 4KQS對中文信息處理技術提出的新課題機遇與挑戰

2. 4KQS與漢字字符集

2.1 《四庫全書》用字底數

1. 數量級，估計
2. 小規模隨機抽樣統計
3. GBK的可用性和涵蓋率
4. 中規模統計
5. 卷內標題與《中華古漢語字典》的外字

2.2 《四庫全書》電子版用字符集CJK⁺

1. 從GBK (CJK字匯)起步
2. 定義4KQS的字符集( Version 1.0) CJK⁺
3. 過渡到Unicode/CJK⁺為基礎的平臺
4. 逐步地定義剩餘的約4400個碼位的Private Use Area
5. 相應的一系列工作

2.3採用CJK⁺後的實例

3. 4KQS與OCR技術：多特定人準規範脫機手寫識別

1. OCR預處理
2. OCR引擎
3. OCR識別率
4. OCR識別速度
5. OCR的後處理
6. 其它研究和嘗試

4. 4KQS與多平臺、跨語境技術

1. 數據的Unicode化- 制備Single Data
2. 檢索界面的 Unicode化- 制做Single Binary
3. 用戶界面的Unicode化-展現 Single Data

5. 4KQS與中文檢索技術

1. 傳統的檢索機制
2. 作者與作者、作者與書目、書目與書目之間的Hyperlink
3. 182萬條的卷內標題
4. 基於Unicode/CJK⁺的全文檢索引擎
5. 漢字關聯

6. 4KQS與其它中文技術

7. 小結

8. 鳴謝

參考資料

作者信息

1. 工程背景與目標

(1)《四庫全書》

　　盛世修典，清朝纂修《四庫全書》是中國文化史上的一次重大的文獻整理活動。

　　從乾隆三十七年（1772）正月開始征書，三十八年（1773）二月四庫館開館，到乾隆四十六年（1781）十二月第一份《四庫全書》抄成，這次由朝廷倡導的規模空前的修書活動，在中國歷史上是絕無僅有的。《全書》廣泛網羅和搜集了從上古流傳至清初的所有著作，用“經”、“史”、“子”、“集”四大部分類，共收書約3,461種，總計約79,337卷，約80,000萬字或97,700萬字[1]。它全面總結和系統整理了三千年來中國封建文化的學術成果，保留了豐富的典籍，反映了那個時代人們的認知世界。任職於“四庫全書館”的官員學者，多是當時學術界名流，他們傾十年心血而成的《四庫全書》，無疑也是對中國古代文化的一大貢獻。

　　世人對《四庫全書》的褒貶不一，褒者譽之為“文化的萬里長城”；貶者曰“四庫出，天下書亡”，對於館臣奉旨刪節、篡改原著造成的後果痛心疾首。然而，《四庫全書》乃世上第一大書則是不爭的事實。《四庫全書》作為一部完整的叢書，它明晰統一的體例，宏大的規模，全面的收羅，豐富的資料，都是其他叢書難以比擬的。該書因卷帙浩繁，不曾付梓刊行，只手抄了七部，分別建閣貯之，這就是被稱作“內廷四閣”或“北四閣”的北京大內之文淵閣、圓明園之文源閣、承德避暑山莊之文津閣和盛京（今瀋陽）故宮之文溯閣；以及被稱作“江南三閣”的揚州大觀堂之文匯閣、鎮江金山寺之文宗閣和杭州聖因寺之文瀾閣。四庫七閣因書而建，《四庫全書》因閣而得以保存。從書成閣立至今二百餘年間，書與七閣歷盡滄桑，伴隨著中國近代史上的頻繁戰亂而飽受摧殘，最短的存世僅六、七十餘年，目前只有文淵、文津、文溯、文瀾四閣尚屹立人間。

　　歷史上，北四閣《四庫全書》乃是皇帝御覽之寶，南三閣雖然名義上是為“人文淵藪”的江浙學子開放，實則仍然被官方嚴格控制，普通學人難得一窺。辛亥革命後，《四庫全書》才逐步走出宮廷，但從未全面影印。本世紀八十年代以來，雖有“景印文淵閣《四庫全書》”問世，但多為少數大型圖書館的鎮館之寶，普通讀者仍然難得一見，即令得見，其手續之繁，檢索之難，亦令人生畏。

回到目錄

(2)《四庫全書》電子版 　　

　　隨著電子技術的飛速發展，特別是電子出版業的興起，學術界、圖書館界和出版界的專家學者萌發了運用電子技術、讓以《四庫全書》為代表的中華古籍瑰寶以新面貌重見天日的構想與實踐，讓它真正擺上學者的書桌、案頭。從1996年下半年起，該項目開始策劃、和專題預研，納入了系統工程的軌道。在慎密的調查研究和實驗研究的基礎上，經中華人民共和國新聞出版署批准，香港迪志文化出版有限公司與上海人民出版社決定合作出版“文淵閣《四庫全書》電子版”，並交由迪威多媒體公司與書同文電腦技術開發公司負責主持技術開發和工程實施。經過一年多的開發，該項目已產生階段性成果並正式列為“國家九五重點電子出版項目”。《四庫全書》電子版不是《四庫全書》簡單的電子拷貝，而是其豐富內容在電子平臺上、利用網絡技術、數據庫技術和現代檢索技術的再加工與重組。它是中華文化與先進科技的結合，也是傳統內容與現代工具的結合。

《四庫全書》電子版，分為原文及標題檢索版（標題版，舊稱圖形版）和原文及全文檢索版（全文版）。 　　“標題版”目前已經完成，共有原書四百七十萬頁（按現代頁計算）圖像，分配在168張光盤上，備有多種檢索機制和一系列輔助工具，以利於讀者的研究。 　　“全文版”目前已經跨越了以研發為主的階段，突破了大部分關鍵的技術難關，進入了工程化的規模，Prototype已經完成。全套“全文版”，約180張光盤，除具備“標題版”的全部數據和功能之外，還裝有八億漢字的內容，可以檢索到單字。預計經、史、子、集可在1999年春、夏、秋、冬完成。

　　整個電子版工程（為了簡便起見，以下將《四庫全書》電子版工程寫作“4KQS”）的目標，是要立足於先進而成熟的現代科學技術，除了極少數的例外、將文淵閣《四庫全書》全盤電子化，面向全球所有的華人和研究中華文化的學者，把《四庫全書》帶入21世紀，開拓古籍電子化的新路。

回到目錄

(3) 4KQS對中文信息處理技術提出的新課題 機遇與挑戰

　　4KQS是一項複雜的系統工程，工程的崇高目標激勵了一大批有志於中華文化典籍電子化的學人和工程技術人員，特別的，它為中文信息技術研究、開發提供了從科研到技術、從技術到工程、市場的機遇，提供了廣闊的用武之地；同時又為中文信息技術的進一步發展提出了新的課題。

在所有挑戰性的課題中，我們面臨著四個影響全局的抉擇：

1. 怎樣表達《四庫全書》中的八億漢字？八億漢字的內容要用到多少個漢字？這涉及編碼字符集的定義與選擇。選擇Code Page還是Unicode ?
2. 怎樣將手寫漢字轉化為編碼漢字？即漢字輸入問題。人工錄入為主還是機器錄入(OCR)為主？
3. 怎樣檢索這些字符化的漢字內容？在缺少古漢語分詞規範、詞庫和其它電子化語言知識的情況下，是否、或怎樣邁入古文全文檢索這個陌生的領域？
4. 怎樣讓整套圖文及檢索機制在多種語言、多個視窗平臺環境中使用，而無需一套一套地開發、轉換這些程序和內容？換言之，怎樣將微軟公司用於系統軟件的Single Binary技術 {即同一套基本程序用於多個語言環境的技術} 用於4KQS這樣的大型電子出版物呢？

　　實際上，只要確認了“全文版”這個目標，對上述問題，我們幾乎就沒有選擇的餘地：我們必須遵守國際標準，在國際標準的框架內定義《四庫全書》電子版的字符集；我們必須做專門的開發，製作4KQS為代表的古籍OCR的引擎和全套軟件，而避免人海戰術式的人工錄入；我們不得不開發基於古漢語的全文檢索系統，因為市場上沒有符合要求的FTR (Full Text Retrieval)引擎可供使用，而海量數據不容許簡單的檢索機制；面對Giga Byte數量級的數據，和Code Page有限的代碼空間，我們只有走Single Data / Single Binary的道路(不僅同一套基本軟件，而且同一套基本數據都用於多種語言環境)。

　　好在，信息技術發展到了這樣的地步，允許我們“踏在巨人的肩上”、選擇較高的起點和較高的目標。

　　以下，簡單描述我們在這幾方面的進展、困難和體會。

回到目錄

2.4KQS與漢字字符集

　　字、詞、語，字是基礎。製作八萬萬漢字的《四庫全書》電子版，首要的是要摸清漢字底數，決定漢字表達的方略。

　　在4KQS策劃之初，就面臨著一個矛盾的兩方面：一是《四庫全書》到底用字多少？二是現有的標準字符集可以提供多大的代碼空間可供使用？

2.1 《四庫全書》用字底數

　　第一個問題在兩年內幾乎不可能有非常準確的答案，因為《四庫全書》不同於字書、辭書，有字頭索引可查。要想了解這個數字，只有在全部數據錄入之後才可見分曉。在預研階段，我們祇能進行小規模的抽樣分析，同時參考其它的有關數據。而後，隨著工程的進展，我們又進行了中規模和較大規模的統計，底數才越來越明。基本的事實與推論是：

1. 《四庫全書》，除“小學”（文字學）之類（訓詁之屬、字書之屬、韻書之屬），其餘部分並非“字書”或“辭書”，它的用字，應比《康熙字典》低相當的數量級，估計在三萬字以下。
2. 十二萬字語料的小規模隨機抽樣統計顯示，語料-用字的曲線符合一般的規律，在語料大於8萬字次時即開始趨於飽和，在12萬字次處，涵蓋99%語料的用字3262個，斜率是萬分之六，即是說，每增加一萬字次的語料，就增加6個漢字。但是，總漢字數並未隨語料增長而飽和，在語料為12萬字次處，斜率高達1.46%。因此，這個小樣本的統計令人憂慮。唯一能夠鼓舞工程繼續進行的事實是：所有12萬字次的語料，除了6個外字之外，全部是用GBK表達的。這說明，我們可以從GBK(等於CJK字匯)起步，至少在相當一個時期內，可以使用GBK作為4KQS的字符集。
3. 以GBK (CJK)為基礎，對《四庫全書》涉及的作者數據庫、書目數據庫、古漢語字典以及《四庫全書》簡明目錄的統計，進一步表明了GBK的可用性和涵蓋率：

語料內容	語料漢字 出現率 （字次）	GBK外字（字次）	外字字次(萬分之)	GBK外字（個數）
作者數據庫	25702	20	7.78	18
書目數據庫	25779	2	0.78	2
中華古漢語字典	895712	5887	65.73	1967
《四庫全書》 簡明目錄	264196	40	1.51	33

其中，中華古漢語字典本身不是《四庫全書》的內容。由於它屬於字書，外字的個數和外字所佔語料比例也較高。該字典選用的字頭，來自大量的古籍語料，其GBK之外的“外字”，可作為四庫全書的自定義字的候選字。

4. 進一步的中規模統計顯示了一定的統計規律性：

語料內容	語料漢字出現總字次	GBK外字（字次）	外字字次(萬分之)	外字 複用率	GBK外字（個數）
全書卷內標題	10403906	13769	13.23	7.14	1928
經部部分內容	104362255	92707	8.88

特別需要指出的是，四庫全書的182萬條卷內標題，一千多萬字次的語料具有良好的代表性。在400萬字次語料處，用字隨著語料的增長已趨於飽和，雖然偶遇特殊內容發生跳躍、漢字量突增，總體的斜率（每萬字次語料所用漢字數量）仍然比較平緩，平均1.44 字/10000字次。

5. 將《四庫全書》卷內標題與《中華古漢語字典》的外字進一步分析，發現他們的外字中大約有40%~50%落在CJK Extension A之中：

語料內容	語料漢字出現總字次	所用漢字 (個)	在CJK(GBK)	在CJK Ext.A	在CJK+ CJK_A外
全書卷內標題	10403906	14683	12755	947	981
中華古漢語字典	895712	16121	14154	879	1088

取上述《四庫全書》卷內標題和《中華古漢語字典》落在(CJK+CJK Extension A)之外的漢字的並集，並定義這些漢字在ISO/IEC 10646 的Private Use Area，便形成了《四庫全書》電子版工程的第一批自定義字。

回到目錄

2.2 《四庫全書》電子版用字符集CJK⁺

　　對第二個問題，Code Page還是Unicode？採用GBK，有大批成熟的軟件可供使用，但最多祇可以有20902標準字和1894個自定義字的碼位；採用ISO/IEC 10646/Unicode，目前尚缺乏足夠的支持軟件，但是有(CJK) 20902 +(CJK Extension A) 6582個標準字和6400個自定義字的碼位。

　　從實際出發，兼顧長遠字量增長及跨平臺的需求，《四庫全書》電子版工程運用的實際步驟是：

1. 從GBK (CJK字匯)起步；一切軟件和數據均以Code Page為基礎；用漢字組合串詳細記錄GBK的外字信息。
2. 在摸清了用字底數之後，定義4KQS的字符集( Version 1.0) CJK⁺ 如下:

a)標準字ISO/IEC 10646/Unicode之CJK Unified Ideographs;

b)標準字ISO/IEC 10646/Unicode之CJK Unified Ideograph Extension A;

c)自定義字ISO/IEC 10646/Unicode之Private Use Area ( EUDC,E000-E785)。

3. 及時將全部數據和軟件轉換過渡到Unicode/CJK⁺為基礎的平臺上。
4. 充分利用CJK⁺，嚴格記錄與管理CJK⁺的外字。經過分析與統計，逐步地定義剩餘的約4400個碼位的Private Use Area。

[CJK⁺組成圖見下頁]

5. (5)CJK⁺一旦定義，相應的一系列工作都要隨之而解決，這些工作包括、但不限於以下這些：

A.確定CJK⁺的屬性（部首、筆劃、拼音、注音），這些屬性是排序、檢索、輔助輸入的依據；其中，部首/筆劃還依新舊字形不同而有所差異。

B.製作CJK⁺的字庫，為了與《四庫全書》風格一致，選用了楷體，而且分GB新筆形與傳統舊筆形兩種。CJK及CJK Extension A部分由方正集團製作，而EUDC部分則隨工程進展分批自行添加。

C.為專業人員開發基於CJK⁺的輸入方法，選用北京翔舟新技術公司劉書澤博士的“劉形碼”為基礎，發展為“四庫流行碼”。在諸多輸入方法中選用“劉形碼”，完全是從工程的角度考量，因為該方法在《漢語大詞典》電子版數千萬簡繁混合數據的錄入中，經歷過考驗證明是適用的。

下圖描述了CJK⁺的概貌：

回到目錄

2.2 採用CJK⁺後的實例

　　採用CJK⁺後，字符集擴大了，外字量明顯減少；同時為未來的外字預留了相當大的備用空間。即使如此，為了合理使用4KQS字符集CJK⁺、正確地用編碼字符表達《四庫全書》的內容，還必需有一套規則來減少外字、管理外字。為此，工程中心頒布了認同-代換及異體字、外字處理規則（以下只是節錄，刪去了大量的實例）。

特別地，規定了詳細紀錄外字的規則：

５． 外字記錄 1) 上策：用組合序列表示外字。 2) 中策：用“相似”符加上肯定的異體字記錄之。 3) 下策：實在模糊、難以辨認者或難以用組合法描述者才代之以問號。

　　在這種情形下，從GBK過渡到CJK⁺，使得外字的出現率大大下降。以經部前19冊870多萬語料為例，外字出現率從萬分之5.57降到了萬分之1.73，當CJK⁺進一步擴充時，這個比例還會下降。細分析這萬分之1.73的外字出現率，發現其中屬於原文模糊不清的有萬分之1.53，這些字，允許用方框等符號在行文中代替，光標一指便可顯示原文字跡[見下圖]；而真正的外字，只有大約萬分之0.2。外字出現率的壓低，對於保證該電子出版物的質量，錯誤率低於萬分之一，有重要的意義。

例：《四庫全書》經部前19冊使用CJK⁺前後(四校前後)外字量變化

圖：模糊不清的字可以在光標所指方框之處顯示原文字跡。

　

[註]本節涉及國際標準編碼字符集ISO/IEC 10646及CJK, GBK, CJK Extension A的若干詳細內容，請參閱資料[2][3]。

回到目錄

3. 4KQS與OCR技術：多特定人準規範脫機手寫識別

　　當年纂修《四庫全書》，從乾隆三十八年二月開館，至五十二年四月續繕三份全書告成，在長達十四年的時間里，清朝政府動用大量的人力物力，終于基本完成了七份《四庫全書》的纂修和繕校工作。參加編修、謄寫的多達4,000餘人，抄成的七份總共20餘萬冊。粗略估算，不算編修，每謄寫一份，當時大約需要4000人年。

　　根據測算，如果採用一般人工錄入/人工校對的方法，《四庫全書》8億字的錄入與校對，大約需要2000人年以上。由於《四庫全書》是人工抄寫，文言文環境下異體/異寫的辨認將大大降低錄入校對的速度。為了在兩年內完成，必須有1000人懂文言、會電腦的隊伍。從投資成本和技術管理的角度來看，這個方案均不是上策；況且，而今已經幾乎不可能招募具有相當於當年鈔繕書手水平的大批人員。工程任務迫使我們必需尋求新技術的方案。

　　“工欲善其事，必先利其器”，從預研階段，《四庫全書》工程中心和清華大學計算機系就密切合作，埋頭苦幹，力排眾議，進行了大量的研究與開發，把清華的“非特定人手寫識別OCR技術”發展為面向《四庫全書》的、工程規模使用的“多特定人準規範手寫OCR引擎”。這項開發的基本策略在於：

１．最大限度地發揮電腦的作用，讓電腦作為“炮兵”，解決85%以上的識別問題；

２．綜合運用OCR提供的信息，最大限度地方便錄校人員，配備“先進武器”，讓人能方便地集中力量解決剩餘的識別問題-像“步兵”一樣去最終“解決戰鬥”。

　　這項開發取得了令人滿意的成果，預計總體的人年需求為此降到了原來的三分之一，即大約700人年。《四庫全書》OCR引擎和配套系統得到了大規模的工程應用。

(1)目前，OCR預處理已經完成了230萬頁掃描、分頁、切邊、端正的全部工序，集中進行“單字切分”。經過了若干個月的測試，數十次的修改、上百萬頁的考驗，切分軟件已能自動採用多種算法，處理大字/小字、交錯/粘連、局部圖、等等規範的和非規範的頁面；為了保證單字切分的正確性，還提供了方便的人工輔助糾錯功能，供給大批質檢人員使用。[見下圖，圖中分割線為電腦劃出。]

　

(2)OCR引擎，業已全面Unicode化，支持CJK+。憑著上億漢字字跡的積累，經過篩選、校對、淨化，識別字典已擁有的7000漢字的多種筆跡，可涵蓋古籍語料的99%。

[圖為計算機正在識別]

(3)OCR識別率，一般而言，由於小字過多、印章譟聲的影響，祇可以達到89%，對於沒有印章和小字較少的普通頁，可達94%，平均92%。

(4)OCR識別速度，在PII/266上，達到每秒22字。目前已經進行了兩億多漢字的識別。在工程中心，基本上是4台PII/266檔次的高檔PC日夜運轉。

(5)針對OCR的後處理，專門開發了“校得快”軟件（業已支持CJK⁺），採用多種信息和手段，讓校對人員可以突破傳統的模式：

A.將原文字跡(圖)與識別結果(編碼漢字，文)一一對應，方便地進行圖文對照、順序瀏覽校對；

B. 按漢字聚類，非順序式地瀏覽校對，便於發現問題；

C. 隱蔽其它內容、突出重點地校對（最可能出錯的文字）；

D. 使用“二選跟隨”，即將概率較高的第二候選字與光標一起移動，一擊鼠標而置換“首選字”；[大約可以解決2-3%的問題]

E. 方便地調用和點擊其餘9個候選字，而無需鍵盤輸入；[大約可以解決5-6%的問題]

F. 用組合序列，用已編碼的漢字描述描述外字，以便進一步的處理。[千分之一以下，上圖@, =,|,~分別代表包圍結構、上下結構、左右結構和異體代換]

G. 方便地察看原文上下文有關段落；

H. 通過100M網絡，快速地把問題提交給古文輔導員或同時；

I. 利用鍵盤，通過《四庫流行碼》輸入，祇需輸入1-2%的漢字；

下面的表格，可以大致定量地描述在OCR和OCR後處理階段，OCR怎樣分擔了人的勞動：

		百 分 比
OCR正確識別/無需輸入		89-91%
人工輸入	光標跟隨/二選字輸入	1-2%
	點擊其餘候選字輸入	5-6%
	鍵盤輸入/四庫流行碼	1-2%
	鍵盤輸入外字組合串	<0.1%

誠然，人在OCR預處理階段的校對勞作也是投入，但那是與古漢字輸入性質完全不同的工作。

(6)為了進一步提高OCR的識別率，亦曾進行過多種其它研究和嘗試，比如：

1. 多識別器（並行）
2. 多識別器（串行）
3. 利用出錯信息表
4. 二元語法(Bigram)
5. 進一步利用各候選字的距離參數

但是，從工程的角度出發，考慮古漢語的複雜性，目前祇審慎地試用了二元語法最近的一個成果，它平均可以正確地糾正3.5個字/頁（額定336個字/頁），即獲得1%的改善。

　　《四庫全書》電子版工程的實踐表明，進行面向識別對象的開發後，OCR技術用於古籍電子化是可行的。目前，雖然主要用於多特定人準規範手寫文稿的識別，但是，作為副產品，木板印刷宋體和鉛字印刷宋體的OCR也已開發成功，並經歷了相當流量的考驗。

　　從學術和技術的角度，進一步提高切分的正確率和OCR的識別率，可能還有很大的餘地；但是從工程的角度看，不知是否會付出不相稱的代價。目前整個OCR工程，應當從哪個角度入手，進一步提高效率、改善精度，仍然是高科技切入的機會。

回到目錄

4. 4KQS與多平臺、跨語境技術

　　《四庫全書》這樣的文化瑰寶，一經電子化，就更加垂諸久遠。一個尖銳的問題擺在了決策者的面前：怎樣才能使《四庫全書》電子版在大中國大陸、香港、澳門、臺灣，乃至整個漢字文化圈，和全世界都能閱讀使用而不是僅限於在中文簡體版的平臺上使用呢？

　　解決這類問題，有兩種策略：一是傳統的方法，以Code Page 為基礎，一個一個語言環境、一個一個代碼頁地去轉換和實現；二是比較系統地以國際標準、工業標準為基礎，保持基本的程序和基本的軟件維持不變，去進一步開發各個語言環境。Microsoft在開發系統軟件和重點應用軟件時，便是採用的這種策略，稱之為Single Binary。這個策略，大大加速了Microsoft開發、移植各個語言的產品的進程。

　　Single Binary策略對於《四庫全書》電子版工程有明顯的裨益，但是對於大型電子出版物，特別是中文出版物，實現Single Binary還沒有先例。何況，除了Single Binary，我們還需要維持一套Giga Byte級的數據不經轉換地使用: Single Data。我們稱之為SDSB (Single Data/Single Binary )。

　　實現SDSB，首要的條件是4KQS所有的軟件和數據都要基於Unicode。雖然由於內容的緣故，我們已經決定了字符集要走這一條道路(Unicode/ CJK+)，但這只是實現SDSB的必要條件，不是充分條件。我們還要對相關的語言平臺和相關軟件的實際情況有較深入的了解和分析，有些關節，還屬於底層的信息。由於各個視窗平臺產品目前正處於從Code Page向Unicode過渡的階段，有些軟件的有的地方還有Bug，或對Unicode 支持得不夠完善，我們不得不採取種種措施來補救低平臺（主要是Windows95、偶爾也涉及Windows98、IE、LanguagePack），上的不足。

1. 數據的Unicode化- 製備Single Data：由於我們使用的是CJK+, 轉化工作就不是簡單的調用MultiByteToWideChar()。再加上一般的數據庫軟件如Visual FoxPro和Access目前祇支持GBK而不支持Unicode, 甚至編輯器也只有NT 4.0以上的NotePad可用，這就大大加重了我們轉化工作的難度。好在Visual C⁺⁺和Visual Basic是支持Unicode的，這是我們實現Single Data的基本工具。

2. 檢索界面的 Unicode化- 製做Single Binary：

1. 對於用于Code Page的數據類型char、char*和MFC CString要相應地改為用於Unicode的類型wchar_t、wchar_t* 和自定義的類CWString。
2. 並將檢索中用到的基於Code Page的API改為基於Unicode的帶有w的API（如果系統提供的話），有的則需要自己重新編寫。

3. 用戶界面的Unicode化-展現 Single Data：是三項工作中難度最大、最複雜的一項工作。

我們的策略是：

1. 充分利用IE (Internet Explorer) + LanguagePack在Unicode Support方面的進展；大量的數據顯示以HTML形式交由IE完成。
2. 用VC有選擇地開發一些標準的控件。例如ListBox, ComboBox和EditBox（單行/多行）

　　然而，由於Windows 95,Windows98和NT 4.0多個平臺下,各個版本的IE, LanguagePack，在字庫的 Language ID及 Code Page的不同設置之下，CJK部分、CJK Extension A和EUDC部分（一部分與Code Page 有Mapping關係，另一部分則沒有）往往有不同的性態，為此，用C TextOutW()和 IE對標準數據在多個語言平臺上進行了大量的摸底測試，並在字庫Setting、軟件、Installer等諸方面進行了相應的調整，經過反覆的測試/修正，才基本上實現了《四庫全書》電子版的Single Data/Single Binary。

　　目前，經過測試的幾個平臺，從Windows95, Windows 98到Windows NT 4.0，簡體中文、繁體中文、日文、韓文和英文的環境下，都可以運行《四庫全書》電子版。但是，從專業的角度，隨著CJK⁺的擴充，推薦的平臺當屬Windows NT 4.0。

表：《四庫全書》電子版 原文及標題檢索版在多個語言平臺的性態。

OS Lang.	簡體中文	繁體中文	日文	韓文	英文
Windows95	良	良	良	良-	良-
Windows98	優	優	優	優-	優-
Windows NT 4.0	優	優	優	優	優

原理上，4KQS應能在所有其它語言的平臺下使用；只是目前還缺乏相應的測試。

以下是4KQS在日文平臺上運行的畫面。

回到目錄

5. 4KQS與中文檢索技術

越是大部頭的出版物，越是需要強大的檢索機制來輔助讀者；

越是大部頭的出版物，越是需要檢索的細密程度；

越是大部頭的出版物，越是需要非順序式的、由此及彼的閱讀；

越是大型的出版物，越需要“電子的經絡”，這是電子出版物的靈魂。

但是，相應的，檢索的時間和空間的代價，就要變得更加高昂。必需優化算法，降低代價。

《四庫全書》電子版，即是屬於這種情況。

電子版採取了如下的一系列措施來強化檢索機制：

1. 一方面，傳統的檢索機制必不可少，三千作者的數據庫，四千書目的數據庫，按照部、類、屬、書目的(樹狀)分類結構、蔟性檢索體系解決了這方面的問題。
2. 充分利用吉林大學出版社的《四庫大詞典》的數據，經過加工處理，與傳統的數據庫比對，建立了眾多作者與作者、作者與書目、書目與書目之間的Hyperlink，這大大幫助了讀者聯想式地、由此及彼地查閱這部巨型典籍。
3. 即使如此，書目仍然是最小的檢索單位。許多著作，橫跨兩張以上甚至多達四五張光盤，簡單地告訴讀者首卷在何處仍然無助於事。為了突破這一點，《四庫全書》工程中心下大力氣，結合OCR技術，編制了182萬條的卷內標題。這些標題，不是傳統圖書館學意義上的細目，而是將卷名、書名、形式標題、邏輯標題、詩詞名、表名、圖名、甚至段落的首句組合在一起，構成更細密的綱目，幫助讀者檢索。這種檢索機制，在傳統檢索與全文檢索之間，建立了一個橋梁；同時也突破了原文圖形檢索的難關。
4. 基於Unicode/CJK+的全文檢索引擎, 經過精心的設計，現實地採用了以單字為基礎的方案。目前，該引擎已經開發完畢，（實質上是一個獨立於全文內容、適用於古文的引擎），它與全文檢索系統的接口調試業已完成，表現了良好的適用性。占空比為1:2，檢索信息一直到篇章/字位。對於一億四百萬真實語料實施檢索，在PII/233MHz 128M RAM, Windows NT 4.0 Server上，檢索“李白”需470ms；在PII/166MHz 32M RAM, Windows NT 4.0 Workstation上，也祇需1.482秒。檢索“商鞅變法”前者需要1.271秒；後者需要1.487秒。
5. 古漢語檢索，納入語法知識提高正確性固然重要，但目前尚缺乏相應的電子資料；而古漢語多以單字為基礎，我們的重點放在了通過漢字關聯來提高命中率。這些關聯信息是：

1. 簡體-繁體關係；
2. 正體-異體關係；
3. 正字-訛字（形近異義字）；
4. 通假-被通假；
5. 古今字；
6. 新舊字形；
7. 中日差異；
8. 其它

　　以上述關係為基礎，對讀者輸入的字串進行預處理，衍生一系列可能的變體字串來檢索。由於採用了特別的技術，實踐證明，命中率提高了，而時間的開銷並未大幅度地增長。

納入關聯字預處理後的檢索實例

漢字語料數量：10400萬， 《四庫全書》經部

硬件平台：Pentium II 233MHz 128M RAM

操作系統：Windows NT Server 4.0

檢索字串		匹配數目		查詢時間（ms）
無關聯處理	有關聯處理	無關聯處理	有關聯處理	無關聯處理	有關聯處理
荊　軻	荊　軻	1	42	130	316
養　廉	養　廉 　槏 　 　覝	20	45	250	290
商鞅變法	商鞅變法 謪	4	4	431	656

從測試中可以看出，關聯字的引入，

1. 增加了待檢索的字串的數目。對於n個字長的字串，若每個字Ci的關聯字有Ki個，則字符串的數量為 K₁*K₂*K_i*…*K_n ( i=1,2,…若無關聯字，Ki=1)。
2. 檢索串增加了，兩字字串和三字字串比較明顯。這也有可能引入一些荒謬組合，造成誤檢的副作用。讀者如果不願意，可以事先選擇關聯的類型[見下圖]。但Default是簡繁關係與正異關係。對“荊軻”而言，有2x2個串待查；對“養廉”而言，則有4x4個串待查。
3. 實際的檢索結果是，命中率提高了許多，由於正文中，“軻”多為“荊軻”，引入關聯，使匹配數從一個增加到42個；經檢查，並無誤檢。正文中，“養廉”的寫法還有“養”，關聯字的引入也使得它們悉數被檢出(從20個匹配增加到45個匹配)，經檢查，亦無誤檢。（在其它情況，可能會發生誤檢的情況）。
4. 檢索速度，由於優化了算法，速度不但沒有按K₁*K₂增長，甚至比K₁+K₂的增長倍數還低許多。

這種關聯字處理，不僅適用於內文，還適用於作者、書目、標題的檢索預處理。
需要指出的是，關聯信息也必需以CJK⁺為基礎。
以下是全文檢索的一個結果畫面：

回到目錄

6. 4KQS與其它中文技術

　　《四庫全書》電子版工程的需求，代表著一大類中文電子出版物的發展需求。其中有些並不是中文出版物所特有的，比如，Client/Server網絡結構設計，多媒體技術，加密解密技術，C與HTML聯合程序設計，SQL數據庫等等。我們可以充分利用已有的成熟技術到工程中去，而不必另起爐灶，重複開發。同時，像《四庫全書》這樣的電子版工程又呼喚著一些新的需求，比如：

1. 支持Unicode/CJK+CJK Extension A的數據庫管理系統。
2. 電子化的、通用的古漢語知識庫：單字及其屬性（形、音、義，碼、頻、序）、字詞語及其相互關聯。
3. 電子化的、通用的歷史古漢語知識庫：時間（朝代-紀元）、地點（歷代地圖）、人物、事件。以幫助建立更廣泛更深入的超級鏈接。
4. 基於CJK+CJK Extension A的TTC ( True Type Collection)，自動適應不同國家和地區的字形規範。
5. 跨平臺的、大眾化的漢字輸入方法，跨平臺的IMEgenerator。
6. 方便實用的補字工具，跨平臺的EUDC Editor, TTF-TTE Linker。
7. 補字與輸入法同步的連接器EUDC-IME-Linker。
8. 組合序列-整字轉換合成器。
9. 古漢語聯機字典（目前已經有了不完備的原型，摘自《四庫全書》全文版屏幕，見下圖）：

顯然，中文信息技術界的朋友大有用武之地。

回到目錄

7. 小結

　　將先進科技與中華文化相結合，借以保存和弘揚中華文化，是世界各地華人的共同願望。中文信息學界，更是把它作為自己責無旁貸的使命。《四庫全書》電子版工程，綜合地運用著中文信息技術的前沿成果，同時在一定程度上又推動了新的技術的開發，取得了寶貴的經驗教訓，為古籍電子化、文獻數字化、電子圖書館的發展探索著新的途徑。

　　目前，儘管該工程已經進入了正常運行的軌道，但大量艱苦工作還在前頭。為了確保該工程高質量地進行，除了已有的技術和管理之外，還迫切期待中文信息學界的專家學者不啻指教和支持，使《四庫全書》電子版能夠以不愧於我們民族文化的水平奉獻給世界。

回到目錄

8. 鳴謝

　　作者欽佩余志明先生投資於華夏文化事業並在金融風暴中毫不動搖的勇氣；並由衷地感謝他和李超倫先生給予我從事於此項有意義的電子文化工程的機會。

　　作者對於建立並發展京、港、滬、榕良好合作關係的迪志文化、迪威多媒體、書同文電腦、上海人民出版社、亞洲仿真及中文大學出版社的各位同仁亦表深深的謝忱。

　　本文採用的諸多技術資料和數據，凝聚著《四庫全書》工程中心全體同仁的心血，作者對於他們的辛勤勞動和創造性的工作表示萬分感謝。特別地，我要感謝我的學友與助手鄧家明，以及劉旭波、王曉明、王曉波、丁柯、朱人傑、石磊、張虎、張弛宜、傅哲、李長業、陳子天、范亦凡、李慶旭、王琴、鄭霄、董心雨、孫為霞、張毅工、陳圓等一批年輕有為的朋友。

　　圖書館界、文史界的朋友楊訥、朱岩、金樹祥、欒貴明、劉薔、王清珍、袁林亦給與了我許多知識與支持。在此一並感謝。

　　在開發相關技術的時候，每每與北大方正鮑慧雲、傅燕麗、張建國、繆榮，清華大學夏瑩、馬少平、姜哲，微軟北京研發中心的張湘輝、任健、李東、毛永剛、王允中、楊永生、賈立群等先生/女士討論與討教，都得到啟發和幫助。在此一並致謝。

　　　作者謹以此文 獻給我的夫人、中科院軟件所研究員楊秀霞。

回到目錄

參考資料

[1]胡宜柔《四庫全書》共收多少？ 《新華文摘》1981年第2期

[2]The Up-to-date CJK Related Document Collection, ISO/IEC JTC1/SC2/WG2/IRG N601, 1998-11-08 最新CJK文件匯編

[3]計算機科學技術百科全書 清華大學出版社 1998年

[4]《四庫全書》電子版工程總體設計書，工程報告 1997-1998

回到目錄

作者信息

張軸材 　 CCID高級工程師

ISO漢字組(IRG)召集人

《四庫全書》電子版工程 技術總監

通信地址：北京海淀區志新村小區14號 100083

TEL: 8610-6234 5536 6234 5537

FAX: 8610-6231 2924

Email: joezhg@public.bta.net.cn

回到目錄