為什麼你不應該用 ICONV 編碼 做 UTF8 繁簡轉換

每個網站都需要語言轉換

Programming Language
Programming Language

因應國際化每個網站都有內建一堆語言包切換,
但是有些自己研發、開發網站的團隊,
在設計初期沒有將網站語系模組化,導致需要靠後台程式來自動翻譯。

或是用 Google 翻譯幫忙轉換 ? —-> 結案!
這篇文章重點其實不是教你如何做網站翻譯。

主要是探討 繁簡轉換 為什麼不應該用編碼的方式做。

我們今天不是探討翻譯、翻譯太難了,
先考慮比較簡單的問題:編碼轉換。

我們來考慮最簡單的需求 PHP 簡繁轉換吧!

Google 第一頁長這樣:

Google : PHP 簡繁轉換
Google : PHP 簡繁轉換

看得出來每一個連結我都點過了

因為我的環境底下沒有一個可以用!

演算法大概長得如下:

function TW2CN($zhTW) {

  $big5 = iconv('UTF-8', 'BIG5', $zhTW);

  $gb= iconv('BIG5', 'GB2312', $big5);

  $utf8= iconv('GB2312', 'UTF-8', $gb);

  return $utf8;

}

有兩個例外是用瀏覽器端的 JS 的方法(非 PHP),直接內建好 繁體 BIG5 對應 簡體 UTF8 的表,直接解決的好方法。有興趣可以研究一下人家怎麼做:
Big5 to GB :: 簡繁轉換
http://www.j4.com.tw/big-gb/

簡繁轉換表
簡繁轉換表

 

簡單說明原因

  1. 利用 PHP iconv 的內建方法來間接轉換
    繁簡編碼 UTF8 -> BIG5 / GBK / GB2312 -> UTF8
  2. 我的 PHP iconv 版本太舊
  3. 然後就爆炸了!

附上我的 iconv 版本

iconv 版本
iconv 版本

詳細說明原因

我環境 Mac 上舊版的 iconv 的 UTF8 對應 GB2312 。會發生幾種問題:

  1. UTF8 轉 GB2312 。比較大的字庫對應比較小的字庫對應不到掉字 -> 小事
    多對一都有這樣的問題。問題是今天如果你是 CMS based 的 Blog 服務,
    長篇文章可能就會掉幾百字,校稿的人力消耗很大。
  2. 如果選擇相對較大的 GBK 字庫,我會發生 UTF8 的繁體字對應到 GBK 編碼的繁體字,這真得太神奇了!不會產生繁轉簡的效果 其實這才是正確的。

    iconv 是只改變編碼而不改變編碼代表的文字
    比如說 123 = Apple (編碼X) 且 246 = Apple (編碼Y)

     iconv('編碼X', '編碼Y', 'Apple')

    就是幫你把 123 轉成 246

    翻譯是只改變文字不改變文字代表的意義
    比如說 Apple (英文) 轉成 蘋果 (中文)

  3. BIG5 對應 GBK 產生亂碼
  4. 即使是新版的 iconv,如果編碼輸入含有 阿拉伯文、俄文、特殊符號等,非繁體、英文、ASCII 可以辨識的字元,在編碼過程中都會掉字或產生亂碼。

綜合以上幾點,

因此非常不建議用編碼來做翻譯的事。

而且網站最好統一編碼,比如說 UTF8。
來降低維護的困難。比如說同一個資料庫不應該存放不同編碼的表單。
應該優先考慮將不同編碼分成不同的資料庫。

後台業務邏輯才不會一直在做轉換編碼來符合網站編碼的一致性。

目前比較好的簡繁轉換法都是在同一個編碼底下的簡繁對應。

比如說好東西:

MediaWiki 的 ZHConverter
https://www.openhub.net/p/mediawiki-zhconverter

它是一個類似維基百科的開源專案,上面連結的作者將裡面的翻譯功能剝離出來。
裡面除了 UTF-8 每一個繁體字對應的簡體字之外,還維護一個字典。類似下圖:

中國台灣用語對應
中國台灣用語對應

https://zh.wikipedia.org/wiki/汉语地区用词差异列表

中國與台灣的用語差異已經不是單純一個簡體字對應一個繁體字了,

比如說:

公交 (中國) -> 公車 (台灣)
隨身碟 (中國) -> U 盤 (台灣)
內存 (中國) -> 記憶體 (台灣)

使用 MediaWiki 的 ZHConverter 你可以維護自己的一個字典表,
也不用擔心繁簡轉換的同時影響其他的字元。

如果你的需求真得需要做網站翻譯呢?

電腦翻譯這件事情一直都不是一件很簡單的問題,
因為不只是不同語言字跟字的對應,
翻譯還涉及文法、或是一些不合文法的變化型 (一些火星文、特殊用法)。

在完美、嚴格規則下的文法簡單的翻譯,就像是程式語言。這個用編譯器技術好解決。

在現實生活當中的語言,目前實務上、研究上都是以資料驅動的模型勝出,
也就是資料統計戰勝了文法規則。這個要用機器學習技術來做比較好。

所以一開始用 Google 翻譯問題就解決了嗎?

它是一個不錯及格的選擇,但不是最好的選擇。

其實 Google 翻譯也不是盡善盡美,所以翻譯領域一直有空間可以進步。
文件翻譯工作者也不會說馬上就失業。

有興趣的話可以參考這兩本好書

[1]  Introduction to Information Retrieval, Christopher D. Manning, Prabhakar Raghavan and Hinrich Schutze

中譯本叫做:資訊檢索導論 Introduction to Information Retrieval

[2] 數學之美, 吳軍

這兩本書都是許多網友推薦的好書、我都有買,我也蠻推薦的。

做個總結

不要用編碼來做簡繁翻譯。

用同個編碼底下的繁簡對應表翻譯是還不錯的方法。

真得要一邊編碼、一邊繁簡轉換,就自己建一對一的表或者用別人的一對一表。這句話的意思是編碼跟繁簡對應表是一對一的關係。比如說: 一個 BIG5 繁體字碼 對應 一個 GB2312 簡體字碼。

翻譯是一個很難的問題。

 

以上,十分感謝你的撥空閱讀。

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *