Beyond the Void
BYVoid
編碼自動識別工具 uchardet

最近在給OpenCC做圖形界面,遇到一個問題:OpenCC默認只能轉換utf-8文本,其他編碼像GB18030,BIG5只能轉換成utf-8以後,纔能用OpenCC轉換。這個問題說大不大,說小也不小。我完全可以增加一個選項,在打開的時候讓用戶選擇文本編碼,然後再轉換就行了,但這卻給用戶非常糟糕的體驗,因為很多非專業用戶根本不知道什麼是文本編碼,更別說辨別了。GB18030/BIG5硬要用utf-8打開的話,肯定會遇到亂碼。由於Windows默認是GB18030/BIG5編碼,一般情況下文本會被保存成默認編碼,這樣更大大增加了用戶遇到亂碼的概率。爲了提高體驗,我計劃實現文本編碼的自動檢測。

最早接觸到編碼是從做網站開始的,記得如果忘了在head中顯式地向瀏覽器指定編碼,就經常會出現亂碼,但亂碼也並不總是出現,這是怎麼回事呢?瀏覽器還是有自動識別的能力的。發現Firefox瀏覽器中有一個編碼選項,裏面有「自動檢測」,使用它絕大多數時候都能正確識別。

事實上純文本的編碼檢測是一個非常複雜的問題,甚至理論上根本不可能實現。確切地說,「檢測」應該叫「探測」或者「推測」纔更恰當。自動編碼探測的實現原理主要是統計學的方法,每個編碼會有一定的特徵,首先檢測特徵是否符合,再使用常用的匹配,類似於蒙特卡羅法。具體方法可以參考Mozilla

mozilla在很多年前就做了一個非常優秀的編碼檢測工具,叫chardet,後來有發佈了算法更加優秀的universalchardet,用於Firefox的自動編碼識別。我想,這麼出名的一個工具,應該肯定已經有不少人在用了。有意思的是,我在網上找到了chardet和universalchardet的各種移植:

惟一沒有的,竟然是C/C++的接口封裝。debian更是收錄了python-chardet和ruby-rchardet,卻沒有libchardet或者libuniversalchardet。莫非沒有C/C++的應用在使用chardet嗎?用強大的Google代碼搜索,發現的確有,但幾乎都是把chardet的代碼內嵌到了項目中,耦合十分緊密。更有直接調用python-chardet的,實現不夠純淨。

總覺不該是這樣,但經過反復確認,真的沒有一個獨立的universalchardet的C函數庫封裝。還是自己動手好了,我從mozilla上面取下來了代碼,做了一點點補丁,寫了一個接口和命令行界面,取名uchardet,大功告成。測試了一些GB18030和UTF8的文本,感覺準確率非常高,而且速度很快。但是當我試圖識別幾個字節的短文本的時候,卻出現了識別錯誤,開始以為是我的錯,後來發現我用Firefox直接打開,也是無法識別的,而且錯誤識別的編碼一樣。看來是上游的問題,應該是算法本身的缺陷吧。想想看,畢竟文本越短歧義的可能性越強。不過既然能達到和Firefox同樣的水平,一般應用也就够了。

項目主頁在Google code上:

http://code.google.com/p/uchardet/

代碼在github上:

https://github.com/BYVoid/uchardet

我爲什麽用universalchardet?其實編碼自動識別的解決方案不止一個,有icu提供的解決方案,IE也有API,還有已經在很多Linux發行版中的enca。我之所以用universalchardet,是因為它是最合適的。IE的API不能跨平臺,icu實現太龐大,enca是GPL(注意不是LGPL),使用它意味著我也要讓我的所有源碼使用GPL,而不是更加開放的Apache。universalchardet是MPL的,和LGPL差不多寬鬆,使用它是沒有問題的。我非常不喜歡以GPL發佈的函數庫,這給開發者的限制太大了。


上次修改時間 2017-03-16

相關日誌