| 對DisplayTag、Tomcat中編碼問題的總結
關于AppFuse中使用中文編碼的問題
這2個月一直被DisplayTag折騰，如果DisplayTag的鏈接或者排序的列中有漢字，那么排序或者翻頁都會查詢不到結果或報錯（如果你處理的好，可能會顯示沒有可以顯示的數據）。
我一直以為這個問題是因為DisplayTag的開發者們沒有考慮到中文的問題，因為項目進度很緊，所以就把排序的功能給屏蔽了，雖然經過了大量的測試，但都沒有發現翻頁時候也存在這個問題（AppFuse自動生成的頁面的默認顯示25行，如果超過25行會自動分頁），直到前天，測試人員才發現這個問題，按照我的理解要修改DisplayTag的源碼，后來又想通過自己寫過濾器試試，幸運的是在我動手干之前，先和倦兔聊了幾句，結果倦兔說他也遇到過這個問題，指出如果在server.xml中添加URIEncoding="GBK"就可以解決問題，我試了一下，果然可以，但這是為什么呢？
在AppFuse中有一個Spring的過濾器，對請求的編碼進行轉換，這種做法很通用，即使是在以前，我們自己寫這個過濾器也不麻煩，而且這個代碼在網上隨處可見，難道是Spring的過濾器沒有起作用嗎?也不是，如果沒起作用，那么我在Struts中的Action中通過request.getParmeter接收到參數應該是亂碼？而且我記得這種做法在Tomcat4.1.24中沒有任何問題，那是為什么？和倦兔討論了一下，我們都沒有找到答案。
于是，我就通過google搜索"URIEncoding",找到一堆文章，我讀了幾篇文章，其中有一篇提到：Tomcat5中對Post和Get請求不再采用相同的處理策略了，而在Tomcat4中采用的處理策略是相同的。于是我想："我的提交的請求明明是Post，我又沒有用Get請求，那Spring的過濾器就應該起作用，為什么結果會這樣呢？"，我的一個jsp中的Form的代碼如下：
<html:form action="editGj" method="post" styleId="gjForm"
focus="mc" onsubmit="return validateGjForm(this)">
看，我的代碼明明是使用的是Post方法，為什么結果不正確呢？
我的跳轉到下一頁的代碼是：
<a href="?d-449687-p=2&mc=%D7%A8%D2%B5&;
excelname=%D7%A8%D2%B5%C3%FB%B3%C6.xls">下一頁</a>
加粗的部分就是我的翻頁的鏈接。如果你立刻就看出了我的問題，那么你就可以不用往下看了，呵呵。如果你沒有看出問題，請繼續，Come On Baby！！！
我采用的真的是Post方法嗎？我的form的提交采用的是Post方法，這是沒錯的，那么鏈接采用的是Post方法嗎？
不是！！！！它采用的是Get方法進行提交的，這就是問題的答案了!
Post和Get提交有什么區別嗎？
簡單的說：Post是將地址傳送一次，將form的數據單獨提交，而Get則是將地址和參數一起傳送，傳送的不止是form的數據，但傳送的數據的長度有字節限制，另外還有安全問題。如果感興趣，你可以用google搜一下，會找到很多資料。 當我想到這個區別時，我又檢查了一下我的顯示列表的頁面，發現這個頁面沒有form，只有，這說明我的提交的確是Get的，于是，Tomcat5對我的Get請求執行的是另外的處理方式，和Post的處理方式不再一樣了！
Tomcat5對Get請求是怎么處理的？
默認情況下，Tomcat對請求采用的默認編碼是ISO-8859-1，我們的JSP頁面上聲明的
和
<meta http-equiv="Content-Type" content="text/html; charset=GBK"/>
只在顯示漢字時有用，而且這2種寫法的作用在理論上應該時一致的，但是由于各個軟件廠商對Web標準都按照自己的理解進行了修改，所以，常常這2種寫法作用就不一致了，使我們在開發Web程序時備感混亂。如果你想了解詳情，請查看《網站重構》一書。
這樣我們提交的漢字被認為是ISO-8859-1的編碼，所以在程序中接收時顯示亂碼，如果使用過濾器，在過濾器中調用request.setCharacterEncoding("GBK")的話，那么Post上來的漢字將被認為是GBK編碼，而Tomcat5對于Get請求上來的編碼并不根據過濾器的設定辨認編碼方式，默認的依然是ISO-8859-1，Tomcat5中處理Get請求的源代碼如下：
上面的代碼中，enc代表Tomcat5中server.xml中Connector部分的URIEnocodeing項設定的值，可以看出，如果沒有設定URIEncoding項的話，那么Tomcat5也并沒有使用默認的ISO-8859-1編碼，而是一段fast conversion，所以，即使你的頁面使用默認的編碼方式進行編碼，然后使用ISO-8859-1進行解碼，得到的結果也不對，這可能是Tomcat5的一個Bug。如果想繞過這個Bug，那么只有在server.xml的Connector部分設定URIEncoding的值，根據編碼方式指定自己的值，在我的程序中我使用的是GBK，所以我修改后的部分如下： acceptCount="100"
connectionTimeout="20000"
disableUploadTimeout="true"
port="80"
redirectPort="8443"
enableLookups="false"
minSpareThreads="25"
maxSpareThreads="75"
maxThreads="150"
maxPostSize="0"
URIEncoding="GBK">
這個問題我參考了這篇文章：
http://www.javaworld.com.tw/jute/post/view?age=0&bid=9&ppg=1&sty=1&id=44042&tpg=1 http://www.javaworld.com.tw/jute/post/view?age=0&bid=9&ppg=1&sty=1&id=44042&tpg=1
另外，對于編碼解碼的問題，我還有一句要說，理論上，如果編碼的charset和解碼的charset是一致的話，那么就應該沒有亂碼的問題，但是，對于某些特殊的字符來說，如果采用的charset不對，則可能在解碼的時候不能顯示，所以要選擇好字符集，我推薦在處理簡體漢字的時候使用GBK。網上也有推薦UTF-8的，具體使用哪種依情況而定。
以上是我的總結，若有錯誤，請指正，謝謝！
明天，我就放假了，祝我的朋友們春節快樂，萬事勝意！
兔八哥
2005年2月4日14:04
另外，我昨晚看了看Tomcat5自帶的Servlet Example中過濾器的實現，其中就有關于處理編碼的過濾器SetCharacterEncodingFilter，還有另外一個是處理用戶輸入的過濾器，叫HTMLFilter，用于將用戶輸入的字符轉化為HTML格式的字符，如將">"轉換為">"，這個過濾器稍加修改就可以用在自己的項目上了，呵呵！ |