么么茶的工作簿

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

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

其中URLEncoder.encode是問題所在。在JDK的API文檔中已經(jīng)標(biāo)明URLEncoder.encode(String)這個(gè)方法已經(jīng)deprecated了，而應(yīng)該在編碼時(shí)指定編碼字符集。找到這里之后，再來看看URLEncoder.encode(String)的實(shí)現(xiàn)：

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

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

      return str;
   }

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

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

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