今天無意中突然對get請求時中文亂碼的解決方法有了興趣，以前只是會用，卻不知道其中的原理，於是自己研究了一番，先來看後臺程式碼

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		// TODO Auto-generated method stub
		PrintWriter pw = response.getWriter();
		pw.append("getContextPath: ").append(request.getContextPath()).append("\n");
		pw.append("getServletPath: ").append(request.getServletPath()).append("\n");
		pw.append("getRealPath: ").append(request.getServletContext().getRealPath("/")).append("\n");
		pw.append("getRequestURI: ").append(request.getRequestURI()).append("\n");
		pw.append("getRequestURL: ").append(request.getRequestURL()).append("\n");
	}
 

第一種請求方式： 那麼返回的結果是：
資料解析編碼：指的是html頁面form表當資料提交時候的編碼方式，這個編碼方式和頁面編碼是統一的，這裡設定為UTF-8，GET請求的的請求資料，並不在請求體體中，而是在請求行中的？之後。而整個請求資料，包括請求行，請求頭，請求體都會通過http協議傳送到服務端去處理。（HTTP協議時不支援中文的，預設編碼：ISO8859-1） 對比post請求，post請求的的請求資料都包含在請求體中，當傳送了了服務端的時候，通過設定request.setCharacterEncoding("UTF-8"),就能夠使得資料傳輸到服務端的時候，能夠將其解析成utf-8的資料。 但是，這樣的設定編碼的操作對請求行中的資料缺失無效的。 前面說了資料時通過http協議的方式傳送到服務端，而請求行的資訊（原始狀態下是UTF-8編碼）經過http協議進行傳輸的時候，http協議對其進行了預設編碼的編碼操作。併發送到了服務端，而服務端類似post請求的處理方式，對其有沒有作用。 （亂碼產生的核心本質：源編碼和讀取顯示的編碼不一致） 思路：找到源編碼的二進位制，然後重新用UTF-8進行解碼就可以了。 所以這種方式可以解決問題：String name1 = new String(request.getParameter("name").getBytes("ISO-8859-1"),"UTF-8"); 而第二種和第三種輸出的還不是UTF-8的編碼方式，所以仍然亂碼。 第二種請求方式： 將中文進行兩次encodeURI,位址列中直接輸入： 返回結果：
只有name2可以正常顯示中文，也就是請求時進行了兩次encodeURI的那個顯示出來了中文，為什麼請求的時候要編碼兩次那？這是因為在呼叫getParameter的時候會呼叫一次decode，這個decode不管用的什麼字符集(utf-8，iso-8859-1，gbk)，都可以得到utf-8的三個位元組，在獲取到引數後，再進行decode一次，就獲取到頁面請求的中文啦。 還有一種解決get請求亂碼的方法，是修改tomcat的URIEncoding為UTF-8 <Connector port="8080" protocol="HTTP/1.1"                connectionTimeout="20000"                redirectPort="8443" URIEncoding="UTF-8" /> maven的tomcat外掛配置uriEncoding <plugin> <groupId>org.apache.tomcat.maven</groupId> <artifactId>tomcat7-maven-plugin</artifactId> <version>2.2</version> <configuration> <port>8080</port> <path>/test</path> <uriEncoding>UTF-8</uriEncoding> <server>tomcat7</server> </configuration> </plugin>