么么茶的工作簿

今日無意中發現在中文系統使用良好的中文頁面在移植到英文系統后出現了亂碼，多方查找發現，出現亂碼的頁面是使用的jstl標簽的c:url和c:param標簽生成的URL通過c:import嵌入網頁的，所以懷疑可能是c:param在進行Base64編碼是使用的編碼有問題。通過查找JSTL的源碼發現在org.apache.taglibs.standard.tag.common.core.ParamSupport類即c:param的實現類中有這樣一行代碼：

   parent.addParameter(URLEncoder.encode(name), URLEncoder.encode(value))

其中URLEncoder.encode是問題所在。在JDK的API文檔中已經標明URLEncoder.encode(String)這個方法已經deprecated了，而應該在編碼時指定編碼字符集。找到這里之后，再來看看URLEncoder.encode(String)的實現：

   public static String encode(String s){
      String str = null;

      try {
         str = encode(s, dfltEncName);
      } catch (UnsupportedEncodingException e) {
      }

      return str;
   }

可以看到默認使用了dfltEncName的字符集，那么這個dfltEncName又是如何得到的呢？從源碼中找到如下：

   dfltEncName = (String) AccessController.doProivileged(new GetPropertyAction("file.encoding"))

看到這里就一目了然了，JVM是從系統變量file.encoding中讀取了默認編碼的字符集。
之后，寫了一個簡單的測試程序，分別從中英文系統中取了一次默認的字符集，中文沒問題是GBK，但是英文的就很奇怪，居然是Cp1252（好像是Latin I，按說應該是ISO8859-1才是）。看了一下英文系統的區域設置，Location選的是Englist(United States)，改成PRC就完事大吉了。
為了防止這種問題的發生，最后還是決定采用最保險的辦法，在Tomcat的啟動參數中加入-Dfile.encoding=GBK，強制將缺省的字符集設為GBK，這樣就一勞永逸了。