星期日, 11月 13, 2005

談古契書資料處理:之二

上回談到古契書資料處理的一些棘手處。

在數位化的過程中,必須有人介入(掃瞄、打字等等)來產生「第一手的數位化資料」。這裡的重點是:有人介入,就會有錯誤產生。有時是看錯原籍,有時是打錯字詞,有時則是心不在焉、錯誤連連。此時,如果沒有安排「校對」的人力(據說,實驗室的古籍資料,是有安排校稿的人力;但從結果看來,似乎在品質上沒有改進太多),寫程式來做後續處理的人,就注定陷入一番苦戰了。

此外,如果沒有事先加以規範(但老實說,要「事先」就知道困難所在、並加以防範處理,是相當不容易的),即使看到同樣的字,不同的輸入人員可能會將其數位化成「形狀類似、但實際上不同」的字碼。例如,古契書裡並沒有使用阿拉伯數字,因此 40 會寫成「四〇」。從實際數位化的資料來看,至少有「四〇」、「四O」、「四0」、「四○」(這些「零」--- 〇O0○---看起來很相似吧?)等幾種不同的結果。

如果數位化資料只是供人閱讀,那倒還好;但若想對這些資料做進一步的處理,寫成不同的字碼,會導致寫程式做進一步處理時的困擾(例如,要搜尋文件中出現「四〇」字串),甚至會導致資料轉換的錯誤。

最後,還想再為「編碼」所導致的煩惱多說幾句。事實上,光是編碼、轉碼的問題,就夠資料處理的人員忙翻了。多種編碼共存也就算了,開發工具與國際組織們,往往也各支援不同的標準。例如,目前的 PHP 版本,就只支援 ISO-8859-1 編碼格式的程式;Windows 與 Java 內部則是採用 Unicode (不過,前者是 Little Endian 編碼;後者是 Big Endian 編碼);而現在流行的 XML 則建議使用 UTF-8。

怎麼這麼多種「標準」啊?從技術的觀點來看,每種編碼是各有其優缺點。但我有時不免會想:那些英語系國家的開發人員,大概不曉得處理這種編碼轉換是多麼令人厭煩吧。

7 則留言:

被掛掉的阿尼 提到...

哈, 以前在做智財局的商標系統, 花最多力氣的就是近似問題
只是沒想到過了六年還是一樣的問題^^
那時候我整理了好多的近似群組, 包括形音,中英日及注音(後面是符號), 然後每一個群組有一個代號, 資料庫裡除了原始資料外, 還有一個被對應到各群組代表號的資料
例如蜥蜴的這些圈圈, 如果代表字是O, 就一律被歸納到四O
當時還有近似字串的問題, 不是語意的近似, 也是整理出一些近似規則, 把處理過的東西預存到資料庫裡
為什麼要預存, 因為橫越幾個系統的整合, 資料超過500萬筆, 可是要在一秒內找到結果...
而我就是把近似變成確定, 然後可以用簡單的資料庫既有功能, 在第一時間從把不可能的資料從值域裡排除...
不過那些東西後來也沒有整理, 程式也隨逝去的goedel而消失.
btw, 新的goedel幫我開一個帳號吧.....

tu 提到...

據說,我剛離開的公司目前還有專案在進行,而他們在許多地方還會遇到轉碼錯誤(變成亂碼)的情形...

所以啊,照阿尼(對了,這麼為什麼叫做「被掛掉的阿尼」呢?) 所說,至少經過六年的光陰,在「轉碼」的部分,幾乎都沒有什麼長進呢。

至於 goedel 目前是誰在管理,我也不清楚...

lcat 提到...

中文的問題實在頭大,而且也暫時看不到解決的可能,例如 Xoops 的模組的中文化,乾脆提供 UTF-8 及 Big5,至於其他編碼方式,就需要的人自己想辦法了 :P

被掛掉的阿尼 提到...

轉碼的東西, 再十年也不會長進
所以自己要決定自已要的碼
如果工具不支援, 寧可自己寫一組byte stream的string函式

被掛掉的阿尼 提到...

為什麼叫被掛掉的阿尼呢?因為阿尼每一集都會被掛掉....

htliao 提到...

這種專業(或遻不常見的)稿子,校對的效果,常常取決於這個校對者對該範疇的了解程度,熟悉的可能看一眼就知道了,不熟的要推敲半天也不知道那個才是對的.
在專業的部份我沒有什麼好建議,講個題外話的相關,大家可以"驚訝"一下.
http://www.ylib.com/class/topic/show2.asp?Object=gossip&No=38845&TopNo=8054
遠流的編輯素質算是不錯的, 發生這樣的錯誤相信負責的編輯也很無力吧......即便當初寫下要將"大夫"改"醫生"的手跡多麼潦草,會看成是”丈夫”變成”醫生”,即使誤以為克莉絲蒂是”先生娘”(當然不是),這樣的修改,還是該再確認一次吧?!
另一個恐怖的推想是,從一開始二個詞根本就打成了同一個...,

tu 提到...

哎,廖的例子說明了:即使是號稱專業的校對,一不小心也會造成很大的困擾。

嗯,把「丈夫」翻譯為「醫生」?讀者應該看得很頭大吧。(連這麼誇張的事情,都會在現實中發生...)