星期四, 11月 03, 2005

談古契書資料處理:之一

這一陣子在「想寫的文章」上進展頗為遲緩 --- 那我在忙些什麼啊?

嗯,一言難盡。簡單地說,是在做實驗室古契書電子檔的一些資料處理實驗。

實驗室裡,多年來持續在進行一個 THDL (Taiwan History Digital Library,台灣歷史數位化圖書館)的計畫。希望能藉由電腦科技與數位化古籍資料,來改善歷史學者(與一般民眾)對台灣歷史的研究與了解。

因此,實驗室有著許多「花不少錢」請人數位化的台灣古契書資料。然而,光是「資料數位化」這個過程,其實就隱含著許多困難。例如,古契書常常會有一些奇特的字,沒有被收錄到 Big5 或者 Unicode 裡,而這就產生了「缺字問題」。

除了這個相對明顯的「缺字問題」外,還有一些努力(或者說是苦工)就經常被忽視。例如,將這些不同 corpus(文獻集)的資料數位化時,通常都是請人「把文件內容掃描、打字」來取得數位資訊的,因而就產生了「資料彙整」的問題。例如,若打字人員是用 Microsoft Word 來鍵入資料,那麼我們最後還是得寫程式來將文字資料從 Word 文件中轉出。

對文件做資料格式轉換,聽起來也沒有什麼。不過,它背後還隱含著文件編碼(Big5、UTF-16 Big Endian、UTF-16 Little Endian、UTF-8)的假設。於是,用 Java 寫的轉換程式,輸出就是 UTF-16 Big Endian 的格式 -- 這讓我稍嫌老舊的 UltraEdit「無法正常編輯檢視」,於是我就得花點力氣再將它們再轉成 UTF-16 Little Endian 編碼。

另一方面,寫程式從 Word 文件將文字資料轉出,有可能對某些文件處理失敗。通常,這部分的努力很少得到「長官」合適的重視,也因此讓「資料處理」成為一件吃力不討好的差事。

經過一些資料檢視與實驗,我對於實驗室學弟妹們的辛苦(做了很多雜事,卻沒有被 appreciate 到的感覺),其實是有一份理解的。

7 則留言:

匿名 提到...

這些辛苦乍看之下都是為了"機器", 而不是為了"人". 不被"人" appreciate是正常的. 也許在後面那些能讓"人"感受的價值出現的時候(通常還是會跟隨著一些瑕疵, 譬如光是切詞, 以及跟隨而來的統計分析, 或搜尋比對等), 透過舉出一些(也許其實是無關的)瑕疵來彰顯前段作業的辛苦, 或許是有機會稍微平反一下.

mph 提到...

不管為人為機器都會有類似的情況。廖就說在工作的各位多多少少都有遇到這種吃力不討好的事;更氣人的是老闆根本不在意你的辛苦。

餵給機器吃,它還會從結果上有點回饋。遇到不識貨的老闆還真像是餵豬八戒吃人參果呢。

lcat 提到...

「餵豬八戒吃人參果!」mph 形容的真好 :)

不過工作就這麼回事,想開就好囉~

被掛掉的阿尼 提到...

突然想到, 在pc上, 其實可以直接呼叫word叫它吐純文字檔.
createObject("...","Microsoft Word") 大概這樣子吧, 有點忘了
因為m$把office的元件跟ui切得很開....

tu 提到...

令人困擾的就是:就算是呼叫 M$ 物件,也還是有轉碼的問題吧?

部分原因是:並非所有相關的程式,通通都預設相同的字元編碼。

如果只考慮 M$ 的環境,使用 UTF-16 Little Endian 應該可以減少許多麻煩。不過,Java 對字元的預設儲存格式好像是採用 Big Endian,所以...

被掛掉的阿尼 提到...

要自己先決定用什麼碼, 五大碼也行
至少這樣轉碼的複雜度是n, 不是n^2

tu 提到...

我的 UltraEdit 可以讀取 UTF-8,但是對於 UTF-16 Big Endian 就無能為力了...