如果你的主要工作就是開發或測試一個動態國際化Java Web專案，那麼如下圖所示的編碼處理問題想必是“大寶天天見”咯。那麼作為開發和測試人員，面對這樣高頻的事件，又需要怎樣應對呢？本文將嘗試從兩個不同角度來分析在這樣的技術背景下，我們需要注意哪些國際化知識點。

首先對於開發人員來說，需要注意的是：

一、HTML中的metacontent

確保每一個HTML頭部都包含有正確的編碼資訊，通過metacontent欄位進行設定。

<meta http-equiv="Content-Type" content="text/html;charset=utf-8">

二、在JSP中contentType的charset和pageEncoding

務必明示pageEncoding屬性用來確定JSP編譯器使用何種編碼。

<%@ page language="java"contentType="text/html; charset=utf-8"pageEncoding="utf-8"%>

三、Tomcat的server.xml

處理完page content，接下來需要考慮的就是處理client發來的資料。大多數應用程式容器都會將碼錶寫死，例如Apache Tomcat預設的就是ISO-8859-1，所以這裡務必用UTF-8來配置connector來處理GET請求。

<Connector port="8080" maxHttpHeaderSize="8192"
 maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
 enableLookups="false" redirectPort="8443" acceptCount="100"
 connectionTimeout="20000" disableUploadTimeout="true" 
 compression="on" 
 compressionMinSize="128" 
 noCompressionUserAgents="gozilla, traviata" 
 compressableMimeType="text/html,text/xml,text/plain,text/css,text/ javascript,application/x-javascript,application/javascript"
 URIEncoding="UTF-8"
/>
 

這樣一來，Tomcat將所有得到的引數按照UTF-8進行編碼。因此，當用戶將以下地址寫入瀏覽器的位址列時，曼城按照UTF-8編碼將會encode成為%E6%9B%BC%E5%9F%8E。

但需要注意的是POST請求不會因此而改變。

四、Filter

千呼萬喚始出來，終於輪到Filter登場了！除了修改上述內容，作為一個開發人員，我們務必指定一個EncodingFilter來強制webapp用UTF-8來處理所有request+ response。示意程式碼如下：

public class EncodingFilter implements Filter {
	private String encoding = "utf-8";

	public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws IOException, ServletException {
		//設定request編碼
		request.setCharacterEncoding(encoding);
		//設定response編碼
		response.setContentType("text/html;charset=" + encoding);
        response.setCharacterEncoding(encoding);
		filterChain.doFilter(request, response);       
	}

	public void init(FilterConfig filterConfig) throws ServletException {
		String encodingParam = filterConfig.getInitParameter("encoding");
		if (encodingParam != null) {
			encoding = encodingParam;
		}
	}

	public void destroy() {
		
	}
}
 

除此之外，我們還需要把filter新增到web.xml檔案中，這樣就能在每一個request發生之前，filter都會被執行。

<filter>
                <filter-name>EncodingFilter</filter-name>
                <filter-class>
                                com.g11n.filters.EncodingFilter
                </filter-class>
                <init-param>
                                <param-name>encoding</param-name>
                                <param-value>UTF-8</param-value>
                </init-param>
</filter>
 
<filter-mapping>
                <filter-name>EncodingFilter</filter-name>
                <url-pattern>/*</url-pattern>
</filter-mapping> 

五、JDBC connection

一旦需要使用DB，就得配置JDBC連結。進入到context.xml中，新增如下內容。

<Resource name="jdbc/AppDB"
                auth="Container"
                type="javax.sql.DataSource"
                maxActive="20"maxIdle="10" maxWait="10000"
                username="g11n"
                password="***"
                driverClassName="com.mysql.jdbc.Driver"url="jdbc:mysql://localhost:3306/     ID_development?useEncoding=true&characterEncoding=UTF-8"
/>

而關於資料庫方面，也還有一些國際化關注點，但已經超越了本文的範圍，本文不多累述。

換個角度，再來說說測試人員吧。我猜細心的測試人員一定已經準備好了一堆用例來進行驗證，“憑爾幾路來，我只一路去！”。必須承認，這樣傳統的黑盒業務覆蓋測試方法肯定是行之有效的，但不得不說，效率卻相當的低。如果在測試時間被壓縮到很緊的情況下，傳統的方式就不再行的通啦！可是一旦面對這樣的在情況，測試人員要怎麼做呢？

有人說，加班完成唄！呃~~~這位兄臺，您慢走，我就不送了！……但送走這位仁兄後，活兒還在那裡，只增不減啊！怎麼破？這裡提供一種我的解法，供大家參考吧。

1、 首先確保你能讀到產品程式碼。（如否，請回歸傳統黑盒業務覆蓋）

2、 針對本文提到的五點，分別針對其實現程式碼進行驗證，必要時新增單元測試用例。

3、 無需部署真實測試環境，僅對上述五點程式碼進行驗證。任何一點不滿足要求，立刻報bug就是了。

4、 完成對上述五點的測試後，相信專案中不會再有編碼問題出現了。如果此刻時間還有富餘，那麼就可以對layout，format之類的檢查酌情而定了。