檔案比對程式在佛典電子化上之應用【前言】 後學目前服務於中華電子佛典協會(以下簡稱 CBETA)，而 CBETA最令人讚佩的就是以高品質高精確度的電子佛典著稱。而其中最大的奧秘，主要是得力於 "檔案比對" 的觀念。 所謂檔案比對，就是將至少二份不同來源的檔案，把內容相互比對，將相異處找出來。若能利用電腦精確迅速的特性來完成這個工作，將會比人工校對來的正確而有效率。我們相信，在找到相異處之後，只要針對相異的部份來處理，必然可得到一份更高品質的資料。因為人為疏失是必然的，但兩份不同來源的文件在同一個地方發生錯誤的機率會變小，若三份文件在同一個地方都發生錯誤，那機率就更小了。 以三份不同來源而相同內容的經文來處理，CBETA 的目標是小於萬分之一錯誤率的品質。而在實際的測試中，CBETA 的確有能力達到這個目標。 【體驗】 檔案比對實際的情況是如何呢? 讓我們來體驗一番。 以此二句為例： 句一：戰士某申，身被鎧冑，直穿巿集而去，玆夫者誰？二王子是也！ 也許您並不能馬上的找出所有的差異，倘若使用比對程式處理，呈現的結果如下: 戰{{士||土}}某{{申||甲}}，身被鎧{{冑||胄}}，直穿{{巿||市}}集而去，{{玆||茲}}夫者誰{{？二|| ﹖三}}王子是也！ 共有六處七字的差異呢!您是否都發現了呢? 這個例子，也許能幫助我們了解使用檔案比對的好處。 【緣起】 電腦複製資料的快速和便利，帶給人們許多的好處。當然，人們很早以前就知道利用檔案比對來尋找差異，或是發現錯誤。 而筆者涉略檔案比對最先是源自於幾位從事電子佛典的朋友，他們在網路上提議以檔案比對的方式，針對網路上許多大德們提供的佛典電子檔案進行比對校正，以達到更高的品質。後來筆者也得到了中研院所設計的檔案比對程式，他們在輸入資料時是請兩家打字行輸入，再利用程式來比對。令人讚嘆的是，他們公開此一比對程式提供大眾使用，但有一個限制是：二份文件輸入的格式必需相同，如此才能做有效的處理。 但網路上流傳著許多佛典，其輸入者不一，來源也不同，格式很不一致，故無法利用中研院的程式，有些肯下工夫的朋友，就將文章的標點、空白等去除，再做成一字一行的檔案，然後使用 dos的 fc 來處理。如此也可以得到不錯的成效。 筆者在某個機緣下得知此事，就嘗試利用程式來幫忙。程式的構想如下： 【程式原理】 原文一 : ---，------，-----aaa----------bbbb-------- 1、設定 "忽略字"，逐一讀取 "非略忽字" 比對，直到出現差異為止。 若忽略字為標點與空白，則第一個找到的差異處在 aaa---- 與ccccc---
的第一個字 本例的暫存區如下: buffer 1 : aaa----------bbbb-------- 3、另一個參數叫 CompareNum ，記錄判斷差異在何處結束。本來內定值為 4 ，意即：當有連續 4 個字在二個暫存區都相同，表示差異至此結束。 程式就是先捉 buffer 1 前四個字 [aaa-] 去 buffer 2 找是否有相同的，若無，就用下一組四個字 [aa--] 去 buffer 2 找。 若都找不到，則程式結束，表示有連續 100 個字找不到相同的片段。也就表示二篇文章差異性太高，建議使用者做適當的修正或是結束比對。 本例會在 buffer 1 第 4-7 個字找到， 即第一次出現的 [----] buffer 1 : aaa [----]------bbbb-------- 於是第一篇的 aaa 與第二篇的 ccccc 相異， 然後從 [----] 再由第一個動作開始。直至檔案結束或發生太大差異中斷。 如此，fgfc 的主要程式碼就完成了初步的設計。然而，這樣的邏輯仍然不是很理想。主要的問題是，倘若 buffer 分別如下： buffer 1 : aaa----------bbbb-------- 則依上述原理，會在 buffer1 的 2-5 字 [aa--] 在 buffer 2 找到。結果就變成 buffer 1 : a [aa--]--------bbbb-------- 結果就不是我們所需要的，後來利用遞迴的方式，相互的修正比對，以求能得到較好的結果。亦即找到後並不立刻採用，而去記錄在 buffer 1的第 n 個對應 buffer 2 第 m 個。記錄 n+m 的最小值，然後逐一試過，直到buffer 1 超過最小的 n+m 個字(也就是說再做下去也不可能是最小值)，然後採用最小那一組，例： buffer 1 : a[aa--]--------bbbb-------- n = 2 buffer 1 : aa[a---]-------bbbb-------- n = 3 buffer 1 : aaa[----]------bbbb-------- n = 4 ............ 以 n + m = 10 這組最小，便採用這組。這個做法與採用 fc.exe 的方式比較，效果不差。且速度更快。 如果您設定的比對字數為 2 ，則執行的結果，和 fc.exe 的結果相同。然而，卻有其他的問題發生，底下是一個實例，例子中 B: 少了前面的第一句， 而我們將標點移去會比較清楚。 A: 大般若經第一卷般若經卷一大唐沙門某某序奉天承運... 若相同字數設為 2 (差異後面至少要有二個相同的中文字) A: [大]般若經 [第一卷般若經] 卷一大唐 [沙] 門某
[某] 序奉天承運 若相同字數設為 4 (差異後面至少要有四個相同的中文字) A: [大般若經第一卷] 般若經卷一大唐 [沙門某某]
序奉天承運 我們會發現設為 2 時，前半段的判斷並不理想，分的太細了，設為 4時，後面 [沙門某某] 我們則希望再分細一點。 有時我們不想計較太多，但在實際操作時，很容易因為不好的判斷，造成後面的文章不易繼續比對下去，因此，只能另尋他途了。 後來與朋友討論，得到了一個較好的方法。亦即先找到連續十個相同的地方，也就是設定相同字數為 10，再將差異處獨立出來，嘗試找 7 個相同的字，如此每次尋找相同的字的字數減少 3，一直到一個相同字。再以上例而言， 底下已經是找到七個相同字了， A: [大般若經第一卷] 般若經卷一大唐... 但再分析下去，都是相同的結果。至下一組差異時，假設目前這是相同字數為 4 的情況 A: [大般若經第一卷] 般若經卷一大唐 [沙門某某]
序奉天承運 若降為 1 時， 發現 [沙門某某] 與 [少門某人] 之中有二個字是相同的 [門某] 於是又分離出來，最後結果就是我們要的 : A: [大般若經第一卷] 般若經卷一大唐 [沙] 門某 [某]
序奉天承運 程式實際上是由 10 ， 7 ， 4 ， 1 這四種逐一比較，而這種方式不但不會變慢，事實上反而比之前的方案還快呢! 至此，fgfc完成了二個不同的適用版本：
有一點要提醒，就在讀取資料時，若是非中文的半型字(英文，數字，符號等)皆先行轉成二個位元字組，程式中就是在前加一個0x01，這樣一來，所有資料都變成雙位元，不論中文英文，程式處理起來也就單純多了。 有同事對程式進行了進一步的試驗，只要妥善處理，便可利用兩兩比對的方式，進行多個檔案的比對。 在今年三月，終於完成許久的心願，將 fgfc 改成視窗(winodws)介面的版本，並將 fgfc 與 fg3fc 合併。在改良使用介面後，正式命名為Wfgfc 1.0 版。這也是目前最新的版本了。 【其它應用】 曾經有朋友詢問，在英文文件的處理上，是否也能使用同樣的方式處理。經朋友測試的結果發現，若能改良成一次比對一個字(word)，則比較能適合英文資料的處理。畢竟，
後者較前者更容易檢查。 經後學思考過後，覺得修改程式的邏輯和原本的設計的方向有所不同，但若使用其它處理方式來達到以字為單位的比對結果，倒是容易的多。例如以空白為分割單位，以字串為比對的樣本。若有朋友對此類討論有興趣，歡迎與後學連絡。 【結語】 其實不只檔案可以比對，在本會的電子經典製作過程中，許多事都採用比對的方式處理。同一件事由二個不同的同事或程式各做一次，再將結果互相比較，我們發現這種作法所得到的結果和所投資的成本，相較於只做一次，然後花二次，三次或更多的精力去進行校對檢查，實在是省時省力又精確。因此，很樂意的將這個方式推薦給各位，倘若您對檔案比對程式有興趣，您可與我們聯絡，並且您也能在我們的網站上找到我們使用的檔案比對程式。 本協會開發的經文檔案比對程式是免費軟體，您可在非營利的情況下，完整的使用和散佈，任何對程式的破壞和反組譯，都是不被允許的。如果您在使用時有任何的建議或發現任何的錯誤，也請您告訴我們。 |