Big5, GB2312 and UTF-8-ization

這算是個由來已久的問題，現在看來，一開始錯誤的決定的確是會造成後面無數的困擾。

三年前這個系統開始需要作簡體中文版的時候，我們的team裡面有過一段討論，就是關於後台的DB到底應該用UTF-8還是使用 locale encoding。我們做 client 的人微言輕, arch leader 以『所謂的localization就是要讓使用者不可以輸入任何 local encoding 以外的字符』為理由，還是把後台的DB 設定成 Big5 (Oracle 還沒有MS950咧!) 或是 GB2312。

現在的問題來了，常常發生在台北開發的 code 移過來，卻發生 encoding 的問題，輸入到後台的東西也常常因為 iconv error 莫名奇妙掛掉(後來發現可以 /IGNORE，不過這是patch不是solution)。如果後台完全都是 UTF-8，那這些就不需要擔心了。

前端的 Java 一直以來都是 full UTF-8 capable，所以在 text component 裡面輸入任意文字都沒有問題，內部都當作 UTF-8 來處理。但是這裡有個小陷阱。如果某個輸入的String encoding==local encoding(internally UTF-8，但是以locale encoding去parse沒有錯誤的話)，那個getBytes.length 會是以 local encoding 的長度來計算的。比如用在繁體中文Windows下輸入"只許成功不許失敗"，然後去getBytes，結果會是16。但是同樣的 input string如果放在簡體中文Windows下用繁體中文輸入法輸入，得到的getBytes會 >= 16。因為此時用local encoding去parse有問題，只好用UTF-8的getBytes長度了。

所以現在測試人員如果用繁體中文環境來測試簡體中文的client，輸入的字串長度常常會因為這個問題，造成誤判，結果超出檢核的上限。會需要檢核上限，也是因為DB裡面設定的欄位寬度是以 latin-1 char 計算，其實通通改用 NCHAR, NVARCHAR2，檢核的時候也已 UTF-8 的 char 數來檢覈，就可以解決了。