[編碼]Java Web的編碼問題

 一陣子沒有寫中文的部落格文章了，不過，這篇主要是放在中文編碼上，所以還是寫了一篇許久未寫的中文文章，來回饋一下。先講一下我遇到的情況，主要是把一個舊專案的Big 5編碼轉成UTF-8，這中間還需要處理，難字、弱掃的問題。基本上UTF-8應該已經算是web的標準編碼了，不過，在專案公司上班，後端工程師，總是會遇到一些歷史包袱不輕的案子。

再大概講一下基本觀念，基本上，Java的字串是UTF-16，所以各字串轉到Java處理時，都會進行編碼，而轉出時也會再次進行編碼，而難字的部分是預留空間可以使用的自訂義編碼，MS950(for 微軟)和CP950(for Linux)都是Big5的擴充字集了，不過這幾個擴充的字集大小我不太確定那個比較多，不過，可以確定的是UTF-8是提供比Big5更多的字集，不過，當遇到不支援的文字時，都是需要另建字檔，每台電腦上需要安裝這個字檔，不過，這塊有專門的廠商在做了，也只是最常用的解決方案之一就是了。

http://smallken.com/blog/wp-content/uploads/2010/06/Untitleddrawing2.png

AP Server上到底有幾個地方要設定呢?其實我試過很多地方的設定，但，我最後確定的是主要有幾個，第一個是URL Encoding, 第二個是Filter，第三個是File Encoding，第四個是JSP的開頭的部分，不過1, 3JBoss有不一同的設定方式，可以參考下面 JEAP 5&6 — 編碼設定問題 (Encoding) 、使用 CharacterEncodingFilter 解決 Java Web 的編碼問題 這二篇。不過，第三個我是沒設就是了，其它三個是一定要設定就是了。其它有的沒的設定可以拿掉看看，至於信良哥的編碼文章，因為我也沒有特別去試，我覺得還是先試這四個設定都不行了，再去看那些細部設定就好了。

最後簡單說一下遇到的坑吧: 1. url的部分中文傳到後端還是會變亂碼，我是使用encodeURIComponent這個js function來解決這個問題，不知道為何傳到後端會幫你自動解成正確的中文QQ。2. JSP檔案的編碼需要是UTF-8，其實原本檔案是Big5，但在我local是可以正常運行的，放到server就是亂碼，不過因為檔案有點多，我是用mac的iconv來轉，如果使用windows的朋友，可以用uniconv(沒用過，不掛保證XD)。3. ESAPI也需要設定編碼，如果弱掃需要使用這個資安的套件，主要在ESAPI.properties可以設定編碼Encryptor.CharacterEncoding=UTF-8和HttpUtilities.ResponseContentType=text/html; charset=UTF-8。

參考資料:

你的原始碼是什麼編碼？

UniConv - 超強轉碼工具 BIG5/GB/UTF8/Unicode

http://www.importnew.com/19791.html

JavaScript 的 encodeURIComponent() 會將字串轉換成 UTF-8 編碼 - Tsung's Blog

Big5、UTF-8、難字、外字解決方案選擇

JEAP 5&6 - 編碼設定問題 (Encoding)

使用 CharacterEncodingFilter 解決 Java Web 的編碼問題

亂碼 1/2

Java基礎-常用API(上)

為什麼要寫這篇呢?因為吃飽太閒嗎，當然不是=_=，因為人的記憶力是有限的，好啦，其實是我的記憶力是有限的 冏，有些東西真的是每天用，很自然就會記得了，比如if和for，但，有些大概一個星期用到一次，或是一陣子沒用…就很自然的忘記了，不過，有些人記憶力是真的蠻好的就是了，但，我不行，所以整理了一下，我覺得常用的Java API。

不過呢，Java是物件導向的程式語言，何謂物件導向呢…其實，這個問題可以說三天三夜，但，不是這裏的重點，重點是，相同類別的function，很可能會被記到同一個類別上，所以，常常會利用IDE的auto instance功能，來協助查詢可用的api，不過，基本上這樣也就夠了嘛，要用再查嘛，但，其實另一個重點就是速度，天下武功，唯快不破(根本在亂用XD)，要當一個產值高的Progamer還是記一下常用的API吧 冏

大概列一下我覺得常用的API類型好了
型別轉換-
在強型別的世界，應該是幾乎每天都在使用吧，但，我也常常一沒寫就忘光光了 冏

日期運算-
沒那麼常用，但我敢保證，如果你有在寫程式，你這輩子一定會用到

正規化-
就我個人的經驗，不常用，有的人可能不會用到，但，我每次用都要重查，也蠻麻煩的=_=

IO處理-
這個嘛，常用到，但通常的情況是，用過一次之後，就掛在那邊了XD

Package naming

package主要的目的是避免相同名稱的Class發生衝突，因此可以避免開發上麻煩

不過，基本上大部分的人都是重視類別、方法、變數上的命名，不過也是因為套件的命名

其實也蠻少會做什麼特別的變動 

基本上，我以前也是亂命名套件的名稱，比如tw.bill.xxx

但，現在覺得tw的意思不大，如果是公司的話應該用com，組織的話就org，個人的話…

有想到pri，但如果是要推個人做的產品的話，目前還沒有想到好的單字，可能就還是先用pri吧，而第二個單字，一般就是公司名，或是省略，直接接產品名

再來呢，就會區分功能區塊了，而功能區塊下，

又會根據其特性，再進行細分，基本上就是這樣啦

另外，至於interface和實作是否要分開，個人會比較覺得分開會比較好，而實作再跟據其對應的對像進行package的分類，不過，這也只是我比較常遇到的清況，

也可以根據功能進行package區分就好，然後Interface和實作可以放在一起，看那種方式最適合實際情況吧

另一個情況要思考的是，關於繼承關系的package分類，這個可以參考一下java api的分類方式，可以看以我個人最常用的ArrayList和其父介面Collection，

http://docs.oracle.com/javase/7/docs/api/java/util/Collection.html

http://docs.oracle.com/javase/7/docs/api/java/util/ArrayList.html

嗯…都放在同一個package中，或許這是一個最簡單的作法

思考過多，反而會造成使用上的困難，但這是對外公開的介面，實際上或許package內部，也隱藏著不為人知的祕密吧XD