跳至正文

传统校勘流程向数字化平台迁移的初步探索——以中华书局点校本《三国志》的修订为例

傳統校勘流程向數字化平臺遷移的初步探索
——以中華書局點校本《三國志》的修訂爲例

鳳凰出版社 吳葆勤

一、引論
校勘是一門傳統學問，有書籍的傳播，就有校勘的應用。1934年，陳垣先生在《元典章校補釋例》中，將校勘方法概括爲對校、本校、他校、理校四種，承用至今。四種方法中，胡適先生認爲，“用善本對校是校勘學的靈魂”（見《校勘學方法論》）。對校法，就是廣搜同書别本，擇其善者，以他本校之。對校可以發現錯誤，又爲修正錯誤提供依據；對校可以發掘版本異文，豐富我們對版本流傳的認識。傳統的對校法在西方校勘學理論體系中，相應的術語是collation（比對）。西方學者認爲collation的關鍵在于認真細心，知識要求不高，因此西方校勘家往往不親自比對，保羅·馬斯《校勘學》甚至指出：“不自覺的推測可以很容易地危害校對的客觀性”，“最可靠的校對者”往往要“關掉自己的知識系統，純粹通過視覺開展工作”。（蘇傑編譯：《西方校勘學論著選》）這個提法可能較爲符合西方文獻的實際，但對于中國古代文獻的對校，恐怕不僅不能“關掉知識系統”，還要盡可能豐富多方面的古文獻學知識。要想精準地比對出古代漢語文獻的異同，除了認真細心之外，還涉及到語言學、文字學、版本學，甚至古代書法的學養。文獻識讀有誤，比對異同則無從談起；機械照錄筆劃異同，又形成無謂的冗餘信息，不僅于事無補，反而徒增負擔。只有當識讀環節很好地完成之後，才可以開始保羅·馬斯所說的“憑視覺開展工作”，成爲一個“最可靠校對者”。從對校法獲得的異同，綜合運用本校、他校、理校等多種方法進行評判，實現還原古籍原貌的預期，則謂之criticism（評判）。西方學者認爲，criticism才是真正意義上的校勘，也就是清代學者段玉裁所說的“定是非”。西方校勘學的這兩個層次，中國傳統的校勘學統稱之爲“校”。
正是基于對不同校勘層次的理解，從collation到criticism的傳統校勘流程向數字化平臺遷移，我們有了三點思考：一是collation的半自動化完全可以通過技術手段實現，這當然要以古籍版本的全文數字化爲前提；二是criticism所需要參考的各類學術文獻，完全可以通過數字化平臺彙聚，並有無限拓展的空間；三是“定是非”的核心工作，任何技術手段只能輔助而不能取代，必須完全依靠研究者自身的學識，這也正是學者永恒的價值所在。
1970年，E. F. Codd發表了里程碑式的論文A relational model for large shared data banks，提出了關係型數據庫理論和結構化查詢語言SQL（Structured Query Language）。從此，數據庫應用進入了學術研究的視野。目前的數字文獻大致分爲傳統平面媒體文獻的數字影像、數字編碼的全文文本以及結構化的數據庫。拋去計算機科學的術語，直白地說，數據庫中的表格（table）就是裝載不同類型數據（data）的容器，SQL語言則是數據庫提供的操作數據的工具。數據庫的規範、實用性，爲校勘流程的數字化提供了可能。
我們在數據庫中設計表格，把校勘所需要的文本數據（text）裝載進去，包括：（1）版本數據，指同一種古籍多個不同版本的電子文本，這是對校法必備的基礎數據；（2）參考數據，指與校勘相關的研究文獻，以及他校法的來源典籍等等，參考數據的採集是開放的、可持續的；（3）校勘成果，這是以前兩項數據爲基礎，綜合運用不同的校勘方法後，寫入數據庫的新內容，包括校勘資料長編、底本處理意見、校勘記以及統計數據等。我們利用SQL語言，編寫不同的函數（function）和視圖（view），對“版本數據”進行對校，辨别異同；對“參考數據”進行彙總，作爲校勘依據；利用SQL書寫查詢（query）代碼的自由度，對“版本數據”窮盡式地檢索，這又是本校法的靈活運用。下面我就以中華書局點校本《三國志》的修訂作爲實例，向各位專家彙報。不當之處，懇請批評指正。
二、實例
《三國志》古籍版本書影
1959年，中華書局點校本《三國志》問世。1982年，點校本作了較大幅度的挖改，推出第二版，重印期間又修正個别文字。點校本在海內外成爲最權威的版本，今天的各類整理本、注譯本，無一不受其影響。然而半個世紀以來，新資料、新方法、新成果不斷涌現，點校本二十四史的全面修訂已經勢在必行，《三國志》自然也不例外。早在2002年，我的父親——復旦大學古籍所吳金華教授就計劃全面修訂點校本《三國志》；2007年，修訂計劃作爲中華書局“二十四史”及《清史稿》修訂工程的子項目立項，成立了修訂組，做了大量的資料積累、專題研究工作，並形成較爲完整的《修訂長編》。2013年，父親去世，承蒙中華書局的信任，讓我來繼續完成修訂任務。從那時候起，我就一直思考三個問題：一是修訂組成員分散在各地，怎樣才能在同一個平臺下，遵循統一的修訂標準，高質量地完成修訂任務？二是除了已有的《修訂長編》需要覆核，不斷公布的新材料還需要納入到研究視野中，怎樣才能既减少重複勞動，又能兼顧到新材料的兼容，從而保證修訂本以全新的面貌問世？三是古籍整理永遠有不斷推陳出新的歷史要求，一個階段工作的終點，必然又是下一個階段工作的起點，怎樣才能預留出未來修訂的拓展空間，而不是奢望畢其功于一役？經過時斷時續的探索、徬徨與實踐，結合自己的研究經驗和知識儲備，我試圖利用數據庫來解決上述問題。
（一）數據庫設計
點校本《三國志》修訂的主要任務是以百衲本爲底本、以傳世宋元本爲通校本，充分吸收前人重要研究成果，在原點校本的基礎上，形成新的修訂本。修訂稿由三部分構成，一是在原《修訂長編》基礎上增補校正而成新《修訂資料長編》，二是據新《長編》提出針對底本的處理意見，三是增訂原點校本的校勘記。新《長編》是處理意見和校勘記的基礎，要盡可能完備。根據這個需求，數據庫表結構中各要素間的關係，用公式表示如下：
傳統的古籍校勘成果，其呈現形式多爲摘錄字詞或短句，附以校勘札記。與此相應的數據庫設計，就是對《三國志》全文進行語段切分，總體原則是以句爲單位，兼顧到長短句的均衡，太長的句子在語氣停頓中人爲切斷，原點校本明顯的句讀失誤造成的破句，略做調整。正文和注文共切分成125301個語段，每條語段標注基本屬性，在數據表中就成爲一條記錄。細化到具體設計，表結構由5組字段構成：
（1）點校本語段、編號和屬性[ID] [char](10) NOT NULL,
[中華書局點校本] [nvarchar](50) NULL,
[段落] [nvarchar](50) NULL,
[類型] [nvarchar](50) NULL,
[卷數] [char](2) NULL,
[頁] [int] NULL,
[行] [int] NULL,
（2）版本語段
[百衲本] [nvarchar](50) NULL,
[紹興本] [nvarchar](50) NULL,
[國圖紹熙本] [nvarchar](50) NULL,
[日藏紹熙本] [nvarchar](50) NULL,
[咸平本] [nvarchar](50) NULL,
[三朝本] [nvarchar](50) NULL,
[南監本] [nvarchar](50) NULL,
……
（3）校勘資料
[張森楷校勘記] [nvarchar](max) NULL,
[百衲本校勘記] [nvarchar](max) NULL,
[盧弼集解] [nvarchar](max) NULL,
[點校本校記] [nvarchar](max) NULL,
[復旦本校字記] [nvarchar](max) NULL,
[原修訂長編] [nvarchar](max) NULL,
……
（4）修訂成果
[新修訂長編] [nvarchar](max) NULL,
[處理意見] [nvarchar](max) NULL,
[修訂本校勘記] [nvarchar](max) NULL,
（5）統計數據
[校記處理] [nvarchar](10) NULL,
[文字處理] [nvarchar](10) NULL,
[標點處理] [nvarchar](10) NULL,
[段落處理] [nvarchar](10) NULL,
    這5組字段中，第（2）組和第（3）組都可以根據研究需要進行擴充，實際上也是爲將來的修訂預留空間。
從版刻文獻到結構化語段
（二）數據採集數據採集就是把數據填入到設計好的數據表中。數據採集可以在數據庫外使用文本處理軟件和microsoft office的EXCEL組件配合完成，這樣更加簡明直觀。
（1）切分語段並導入數據庫
文本處理軟件。工欲善其事，必先利其器。互聯網提供了多款文本比較（compare）軟件，如EmEditor，NotePad+，TextDiff，UltraCompare等等，這些軟件通過語法著色，對兩個文本中相異的字詞句高亮顯示，有助于用戶快速識别。筆者根據自己的習慣，選用EmEditor。
古籍電子文本。隨著古籍數字化的不斷推進，絕大部分常用典籍，如《四庫全書》、《四部叢刊》等大部頭叢書都已經數字化，大量的海內外網站也提供古籍電子文本。這些電子文本有精粗之别，不可能完全符合我們的要求，但是充分利用這些已有的文本，大體上能免去重新錄入之勞。我們得到授權使用的中華書局原點校本《三國志》純文本文件，質量較高，但由于點校本多次挖改造成版次不一致，且個别造字在轉換後丟失，在具體使用中也必須覆核。這個電子文本，也就是我們的工作本。製作校勘底本。對照底本的文字校改工作本，形成底本的電子本。質量高的工作本，校一遍基本能消滅錯誤，質量差的最好校兩三遍。校好的底本，做上標記。本例使用EmEditor自定義標志符，以#標出每卷傳主標題，以||表示分段，以〇作爲裴注間的分隔符。這些標志符在文本被切分成語段後，能幫助我們回復到原格式。無庸諱言的是，電子版無論校對幾遍，肯定會有錯誤存在，好在後面的程序對校，還有發現錯誤並修正的機會。原點校本《三國志》把自宋刻本以來夾排在陳壽正文中的裴松之注提出來重新分段，爲了便于和古籍原刻本相對照，我們把裴注仍然夾排到陳志中，首尾用【 】作爲區分。
中華書局點校本《三國志》卷三十四電子文本及切分後的語段
底本語段切分。EmEditor文本處理能力非常强大，尤其是錄製、編輯宏（macro）的功能，可以把基于正則表達式的查找、替換等操作封裝起來，組合在一起重復使用，簡單的幾條命令，就可以瞬間實現語段的初步切分。點校本《三國志》各卷篇幅不等，因此切分後的語段，最多的《武帝紀》達到4704條，最少的《二主妃子傳》只有282條。初步切分後的語段，需要重新瀏覽一遍，作些微調。底本語段，是多版本語段生成的基礎，這一步工作完成得越精準，後面的流程就越順利。需要注意的是，GBK字符集中沒有收錄的漢字，我們不使用超大字符集。實踐發現，GB18030以上的超大字符集，在數據庫中得不到良好支持，超出GBK字符集以外的漢字，數據庫能够顯示，但是系統內部却作爲“?”處理，這對字符的異同比較，是致命的干擾。我們採用拼字來解決GBK字符集中沒有的漢字，拼字規則按照CBETA 中華電子佛典協會製作《漢文大藏經》的辦法，拼字用[ ]括注，等到將來數據庫對超大字符集完全支持後，統一替換也不麻煩。
標注語段屬性。《三國志》全書文本屬性比較複雜，既有陳壽正文，又有裴松之注文。裴注中既有裴松之的自注、按語、史評，又包括夾注的文字音義，當然篇幅最大也最有價值的是裴氏徵引他書的材料。每條語段都有屬性，有的是整個數據表的惟一屬性。比如“太祖武皇帝”條，其屬性爲：[卷數]=“01”，[段落]=“武帝紀”，[類型]=“陳志”，[點校本頁碼]=“1”，[點校本行數]=“3”，數據庫表的唯一編碼[ID]=“WE_01_0003”，WE代表魏志，01代表卷一，0003指本卷第3條語段。對語段標注屬性，有助于對文本的深度挖掘。
在EXCEL表中標注語段屬性
多版本語段製作。複製底本語段爲副本，對照其他版本改造成相應的電子文本。底本語段經過仔細校對，在改造的時候，工作量會减少很多。改造完成後，啓用EmEditor的文本比較功能，底本與改造後的版本間的異同會高亮顯示。對異同逐條覆核，因爲兩個版本都是分别校對的，所以低級錯誤絕大部分存在彼有此無的互補關係，從而在覆核中予以糾正。古籍電子文本的校對是反復完善的過程，很難一步到位。按照這樣的流程，使用幾個通校本，就循環比對幾次，通過不斷修正，各版本的精確度就逐漸逼近原本。點校本《三國志》所使用的底本（百衲本）與通校本——紹興本《魏志》、咸平本《吳志》和三朝本都由中華書局校對組完成，在製作多版本語段的過程中，我們利用上述方法覆核，確實起到修正漏校和誤校的作用。
多版本語段的製作
語段的整體導入。多版本語段製作完成後，按照對應關係，全部複製到EXCEL表格中。我們利用SQL SERVER提供的數據接口，直接把EXCEL導入到數據庫表中的相應字段下。
在EXCEL表中置入多版本語段
（2）設計校勘資料錄入窗體語段入庫後，校勘資料就可以分解到相應語段下。《三國志》重要的校勘資料除了原《修訂長編》，還包括張森楷《三國志校勘記》、張元濟《百衲本校勘記》、盧弼《三國志集解》、趙幼文《三國志校箋》、易培基《三國志補注》等相對完整的校勘成果，一些零星的考證成果，絕大部分都被這些文獻吸收，個别遺漏的和新出的成果，以及我們在修訂過程中産生的新見解，將根據情況補入到新的修訂資料長編中。窗體的設計，是基于SQL編制的專門用于錄入校勘資料的視圖（view），所謂視圖，就是從原始數據表中選出需要的字段，形成虛擬表。以《三國志》爲例，我們選出6個字段，構成“校勘資料錄入”視圖的主體：
[張森楷校勘記] [nvarchar](max) NULL,
[百衲本校勘記] [nvarchar](max) NULL,
[盧弼集解] [nvarchar](max) NULL,
[點校本校記] [nvarchar](max) NULL,
[復旦本校字記] [nvarchar](max) NULL,
[原修訂長編] [nvarchar](max) NULL,
爲了操作更加直觀，也爲了數據庫的安全，我們使用microsoft office的ACCESS鍵接SQL SERVER數據庫的“校勘資料錄入視圖”，構建一個用戶界面友好的操作窗體。
ACCESS窗體
在ACCESS窗體中，更新的數據將直接寫入SQL SERVER數據庫。上述幾部重要的校勘成果，修訂組都準備了電子文本。在分解到數據庫的時候，又根據原書作了覆核。
（三）與對校法相關的函數設計如果校勘對象篇幅不大，且涉及到的版本數量較少，採用任意一款文本比較軟件，都能滿足對校法的基本需求。但像《三國志》這樣全書約69萬字（去除標點後的中華書局點校本字數）的超大文本，現存宋、元、明三朝刻本就在10個以上，更不必說他校法所要利用的類書、政書及改編史書中的豐富的《三國志》引文，以及明清以來蔚爲大觀的《三國志》校勘研究成果，這些多元、海量的文本數據，怎樣有機揉合到一起，不通過精心設計的流程和個性化的編程，功能單一的文本比較軟件是很難實現的。對校能否窮盡，是否精準，是這次修訂工作基礎，也是前人校勘《三國志》相對薄弱的環節。我們使用SQL SERVER內置的Transact-SQL語言設計了三個函數實現對校。
（1）“標點過濾函數”（onlyText）古籍標點是後人爲了方便閱讀而添加的符號，與古籍版本本身的的異同無關，必須在對校時予以過濾。創建這一函數並不複雜，使用內置的replace( )函數把語段中的標點直接替換成空字符即可。
（2）“異體字過濾函數”（formatText）古籍整理一是要盡可能保存古籍原貌，就是存舊；二是要盡可能讓讀者使用方便，就是循新。把握好存舊與循新的平衡關係，異體字就是必須要正視的問題。異體字規範過了頭，甚至無視異體字的時代性，以今律古，就失去了存舊的意義；完全放任異體字不整理，原樣照錄，就給新時代的閱讀帶來不便，後續的索引製作也不方便。對校法比較文本內容的差異，必然要考慮到古籍所屬時代的不起辨義作用的異體字、古今字、正俗字怎麽處理。前輩學者的處理方式有的較爲隨意，比如張森楷校《魏志·杜畿傳》“有君如此，奈何不從其教”，《校勘記》云：“監本、槧本‘奈’作‘柰’，正字。此俗譌體。”如果按照這個出校標準，無論哪個版本的《三國志》，需要校出“俗譌體”的地方比比皆是。東漢許慎《說文》云“柰，果也”，南朝梁顧野王《玉篇》增補成了“柰，果名。又柰何也”。宋代《廣韻》明確指出“奈，如也，遇也，那也。本亦作柰”，其後《集韻》《類篇》乾脆把“奈”合併到“柰”字頭下。 “柰”、“奈”混用，歷史脉絡是非常清晰的。對不起辨義作用的用字歧異出校，既不追根溯源，又不講求體例，就屬于冗餘校勘信息，是科學校勘必須要規避的。設計異體字過濾函數，就是通過對文字的斷代研究，搞清楚在版本刊刻的時代，哪些是古今字，哪些是正俗字，以及異體字的義項重合範圍，在對校中恰到分寸地過濾掉。需要指出的是，“過濾”並不是永久替換，而是通過函數暫時屏蔽，因爲刻本中不同的用字習慣，對研究版本間的傳承關係，具有不可忽視的價值。和過濾標點一樣，過濾異體字也同樣嵌套使用内置的replace( )函數。

異體字過濾函數
（3）“文本比較函數”(compareEdition)過濾掉標點、異體字、古今字、俗體字之後，就進入對校環節。文本比較函數算法大致如下：首先判斷兩個版本的語段是否全等，如果全等，則說明無版本異文。如果不等，繼續判斷語段字數是否相等。如果不等，說明某個版本存在衍脫，需要人眼比較。如果相等，就啓用循環模式，對語段逐字比較，異文計入變量進行累加，最後給出比較結果。
文本比較函數流程圖
（四）設計點校本《三國志》修訂平臺修訂平臺是傳統校勘流程數字化的最終實現。所有的函數、視圖設計，都是爲了最終構建一個高效、實用的修訂平臺所做的準備。我們仍然利用SQL SERVER視圖聚合構建平臺的基礎數據源。
ACCESS視圖
視圖包括幾個子模塊：（1）原始數據表中底本語段及其基本屬性：
[卷數] [char](2) NULL,
[ID] [char](10) NOT NULL,
[段落] [nvarchar](50) NULL,
[類型] [nvarchar](50) NULL,
[中華書局校百衲本] [nvarchar](100) NULL,
這些屬性便于修訂者快速在書中定位語段，提高效率。爲了增加語段的可讀性，我們又設計了“上下文語境函數”（contexts），動態抓取被修訂語段的前後兩條，共同構成一個相對完整的語境。“語段上下文”不寫入物理表中，只出現在視圖中；視圖關閉，數據就自動從內存中清除。
上下文語境函數
（2）彙總除底本外的各版本語段，供修訂者對語段衍脫情況的判斷或者對程序比對有疑問的地方進行覆核。[紹興本] [nvarchar](50) NULL,
[國圖紹熙本] [nvarchar](50) NULL,
[日藏紹熙本] [nvarchar](50) NULL,
[咸平本] [nvarchar](50) NULL,
[三朝本] [nvarchar](50) NULL,
[南監本] [nvarchar](50) NULL,
（3）彙總版本對校的異文。本模塊是對“文本比較函數”的重復使用，以底本爲核心，把各版本逐一和底本比對，比對的結果進行彙總。這種算法的好處有二：其一是可以自由更換底本。在校勘進行中，甚至完成後，發現底本質量不能讓人滿意，或者說發現更好的本子可以當底本，比如說南監本，只要在視圖中把底本更換成南監本，用南監本和各版本逐一比較，就輕鬆完成了底本置換，而相應的底本處理意見和校勘記只要根據南監本略作修改即可。其二，真正實現無底本校勘的可能，做到多本互校，擇善而從。當然出于校勘的方便，我們還是傾向主于一本的校勘模式。
ACCESS視圖校勘資料
（4）彙總校勘資料。針對每條語段，凡是校勘資料有相應內容的，就彙總在一起，便于比對。在實際工作中，由于幾家校勘成果彙總在一起，他們之間的因襲、抵牾就非常明顯。[張森楷校勘記] [nvarchar](max) NULL,
[百衲本校勘記] [nvarchar](max) NULL,
[盧弼集解] [nvarchar](max) NULL,
[點校本校記] [nvarchar](max) NULL,
[復旦本校字記] [nvarchar](max) NULL,
[原修訂長編] [nvarchar](max) NULL,
（5）列出要修訂欄目，允許用戶寫入內容。上述四個模塊都是只讀的，防止用戶誤改信息，只有這個模塊是可寫的。新修訂長編可以直接複製前幾個模塊的內容，加以修改補充，作爲寫處理意見和校勘記的依據。沒有在模塊（4）中列出的零碎材料或修訂組研究的新成果，都可以列入到本欄中。與處理意見相關的4項統計，可以從下拉式列表中選擇，主要是針對底本和點校本的處理辦法，比如“校記處理”和“文字處理”是針對底本改字和出校的統計，“標點處理”和“段落處理”是針對原點校本的修改統計。這樣在完稿之後，可以有一個準確的統計數據。頁和行的數據，對修訂稿完成後按照原點校本排序至關重要。[新修訂長編] [nvarchar](max) NULL,
[處理意見] [nvarchar](max) NULL,
[修訂本校勘記] [nvarchar](max) NULL,
[校記處理] [nvarchar](10) NULL,
[文字處理] [nvarchar](10) NULL,
[標點處理] [nvarchar](10) NULL,
[段落處理] [nvarchar](10) NULL,
[頁] [int] NULL,
[行] [int] NULL,
ACCESS視圖修訂内容
（6）以上是反映在用戶界面的模塊，最後一個包含在視圖代碼中的，又是非常重要的模塊是過濾條件。修訂工作能否節省時間和精力，取決于修訂人員的關注點是否集中在需要研究的語段上。既沒有版本異文又沒有相關研究成果需要審定的語段，都在過濾之列。用邏輯表達，就是只要任何一個版本和底本存在異文，或者任何一條語段存在前人或修訂者的研究成果，只要任意一個條件符合邏輯“真”，就必須過濾出來，供修訂者審定。如果此前邏輯“假”的語段被過濾之後，又因爲在修訂過程中增補了新資料，或者補充、修正版本語段後産生了異文，變成了邏輯“真”，我們又增加了“基礎數據修正入口”，使程序具有靈活性。
（五）數據的導出與導入修訂工作按卷進行，每卷完成後，都需要處理數據：一是備份，二是分發。點校本《三國志》的五位修訂者各自負責10至15卷，完成校勘資料的錄入和修訂。由我做語段的切分、屬性的標注、多版本語段的製作和彙校，這些前期工作完成後，導出數據到獨立的ACCESS文件中，分對給修訂組成員錄入相應的校勘資料。錄入結束，再把文件收回檢查，與彙校結果整合，篩選數據，形成修訂文件，再次分發給修訂組成員，正式進入修訂階段。完成後的修訂文件回收後，導入到數據庫中。所有文件的分發與回收，錄入與修訂，全部通過ACCESS文件作爲媒介與平臺，與SQL SERVER數據庫隔離。
我們最初的計劃是，數據庫架設在網絡服務器上，修訂組成員可以直接在異地實時工作，比文件分發—回收模式要簡單直接。甚至也考慮過採用流水綫作業，把按卷分工的縱向模式改成按模塊分工的橫向方式。但在實際工作中，各方面條件受限，以及工作習慣，我們還是採用了更接近傳統的方式。
全部修訂工作完成後，按照出版社的要求，從數據庫中提取出相應信息，如點校本的卷數、頁、行，修訂長編、處理意見、校勘記，按照卷數和頁、行排序，便于編輯和原點校本對照審核。
三、結語
點校本《三國志》修訂任務完成近三分之二，嘗試使用數據庫輔助工作也走了很多彎路，希望通過這一探索，爲數字化古籍整理平臺的研發提供一點微不足道的經驗。四點認識，分享如下：一、古籍整理與研究的方法雖然具有共性，但中國浩如煙海的古籍各有其獨特面貌。運用數字化技術從事古籍整理，只能基于古籍的獨特性，他人的成果只是借鑒，只有適合自己技術路綫，才是最有價值的。
二、對古籍整理而言，數字化手段只是輔助工具，合用即可，不必在形式上牽扯過多精力。
三、程序設計是不斷完善的過程，隨著研究工作的深入，需求也會有所變化，程序自然也要隨之修改，研究者無法削足適履去牽就既有的商業程序。因此，爲了更好地服務于古籍整理，研究一點技術非常必要，學習技術的道路也並非高不可攀。
四、數字化技術與古籍整理的質量並無必然聯繫，真正能提高古籍整理水準的是深厚的學養和無畏的獻身精神。
原文
标签:

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注