在javaweb開發(fā)過程中get和post亂碼是一個老生常談的話題了，相信人人都遇到過。網(wǎng)上的文章也很多，但往往是看的越多就越糊涂，有些東西只有自己了然于心才能真正地明白。下面就寫一篇文章，就亂碼產(chǎn)生的過程分析一下。
為什么會產(chǎn)生亂碼？

1.   為什么會產(chǎn)生亂碼？

因為瀏覽器不允許提交非ASCII字符，如果提交了非ASCII，則瀏覽器自動對其進行編碼，將它們轉(zhuǎn)換為ASCII字符。根據(jù)瀏覽器的不同，轉(zhuǎn)換時使用的編碼也不同，比如有些瀏覽器會使用utf-8進行編碼，而有些會使用gbk進行編碼。

2.   瀏覽器為什么不允許提交非ASCII字符？

以下是我個人觀點，僅供參考。

因為瀏覽器和服務器通信，傳輸?shù)亩际亲止?jié)。而我們在頁面提交的都是字符，所以瀏覽器底層就有一個將字符轉(zhuǎn)換為字節(jié)的過程，這個過程涉及到編碼，瀏覽器到底是用utf-8、gbk還是iso-8859-1將字符轉(zhuǎn)換為字節(jié)呢？我想應該是iso-8859-1，因為這是西歐默認使用的編碼。何況，也沒有任何理由使用前兩種編碼格式。但是iso-8859-1編碼是不能識別中文以及其他非ASCII字符的，所以如果字符中存在這類字符，那么將字符轉(zhuǎn)換為字節(jié)的過程中勢必會產(chǎn)生亂碼。為了避免這種情況的發(fā)生，瀏覽器自動對非ASCII字符進行了編碼，將這類字符轉(zhuǎn)換為ASCII字符，這樣就能避免亂碼問題。

3.   GET和POST提交表單，分別根據(jù)什么對非ASCII字符進行編碼？

GET：

情況比較復雜，不同瀏覽器也不一樣，有的使用gbk，有的使用utf-8不好一概而論。

POST：

瀏覽器會根據(jù)網(wǎng)頁編碼對表單中的數(shù)據(jù)編碼。比如我們在jsp頁面第一行所寫的：<%@page contentType="text/html;charset=UTF-8"%>。那么這個網(wǎng)頁響應給客戶端后使用的就是utf-8編碼，那么post時使用的也是這個編碼。

編碼后的格式可以參考java中的URLEncoder.encode方法編碼的結果。

4.   服務器底層如何處理提交的數(shù)據(jù)。

上面2已經(jīng)提到，客戶端和服務器端傳輸?shù)氖亲止?jié)，那么服務器端接收到的原始數(shù)據(jù)就是字節(jié)。但是我們的程序通常需要從服務器獲取字符，而不是字節(jié)，所以服務器端必須將字節(jié)轉(zhuǎn)換為字符。這里也涉及編碼，服務器采取什么編碼方式將字節(jié)轉(zhuǎn)換為字符？我想也是iso-8859-1，這樣和客戶端的編碼方式一致，不會產(chǎn)生亂碼，相當于一個還原字符的過程。這里有個問題，比如客戶端發(fā)送：name=%D6%D0%B9%FA，那么服務器端還原后也是：name=%D6%D0%B9%FA。那么我們使用request.getParameter(“name”)如何能得到正確的值呢？難道要我們自己再進行轉(zhuǎn)換？答案是：NO。根據(jù)Servlet規(guī)范，Servlet中獲取數(shù)據(jù)的方法會按照指定的字符集解碼。指定的字符集是什么？默認是iso-8859-1。正是因為使用了iso-8859-1解碼我們發(fā)送的參數(shù)，導致了亂碼的產(chǎn)生，這里才是產(chǎn)生亂碼的源頭。具體解碼的過程可以看看java的URLDecode.decode方法。既然知道了產(chǎn)生亂碼的原因是因為服務器默認使用iso-8859-1解碼，那我們就得想辦法更改服務器使用的解碼編碼。好在服務器已經(jīng)提供給我們修改的方式了，我們可以在服務器中進行配置，比如Tomcat可以在server.xml中進行配置，比如：URIEncoding="GBK"這樣服務器就會使用gbk編碼解碼，這種方式主要針對GET提交的數(shù)據(jù)，對于POST更常用的是request.setCharacterEncoding(String charset)設置解碼編碼。

5.   為了避免亂碼，客戶端應該如何做？

GET：

對于含有非ASCII字符的URL自己進行編碼，比如使用javascript中的方法進行編碼。這樣就不需要瀏覽器為我們編碼了，從而解決了瀏覽器編碼的不確定性。

POST：

只要正確設置網(wǎng)頁編碼即可。

     摘要: 工作中經(jīng)常遇到java編碼問題，由于缺乏研究，總是無法給出確切的答案，這個周末在網(wǎng)上查了一些資料，在此做些匯總。     問題一：在java中讀取文件時應該采用什么編碼？ Java讀取文件的方式總體可以分為兩類：按字節(jié)讀取和按字符讀取。按字節(jié)讀取就是采用InputStream.read()方法來讀取字節(jié)，然后保存到一個byte[]數(shù)組中，最后經(jīng)常用new Stri...  閱讀全文 Servlet/JSP技術和ASP、PHP等相比，由于其多線程運行而具有很高的執(zhí)行效率。由于Servlet/JSP默認是以多線程模式執(zhí)行的，所 以，在編寫代碼時需要非常細致地考慮多線程的安全性問題。然而，很多人編寫Servlet/JSP程序時并沒有注意到多線程安全性的問題，這往往造成編寫 的程序在少量用戶訪問時沒有任何問題，而在并發(fā)用戶上升到一定值時，就會經(jīng)常出現(xiàn)一些莫明其妙的問題。

　　Servlet的多線程機制

Servlet體系結構是建立在Java多線程機制之上的，它的生命周期是由Web容器負責的。當客戶端第一次請求某個Servlet 時，Servlet容器將會根據(jù)web.xml配置文件實例化這個Servlet類。當有新的客戶端請求該Servlet時，一般不會再實例化該 Servlet類，也就是有多個線程在使用這個實例。Servlet容器會自動使用線程池等技術來支持系統(tǒng)的運行，如圖1所示。

　　

　　圖1 Servlet線程池

　　這樣，當兩個或多個線程同時訪問同一個Servlet時，可能會發(fā)生多個線程同時訪問同一資源的情況，數(shù)據(jù)可能會變得不一致。所以在用Servlet構建的Web應用時如果不注意線程安全的問題，會使所寫的Servlet程序有難以發(fā)現(xiàn)的錯誤。

　　Servlet的線程安全問題

　　Servlet的線程安全問題主要是由于實例變量使用不當而引起的，這里以一個現(xiàn)實的例子來說明。

Import javax.servlet. *;
Import javax.servlet.http. *;
Import java.io. *;
Public class Concurrent Test extends HttpServlet {PrintWriter output;
Public void service (HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {String username;
Response.setContentType ("text/html; charset=gb2312");
Username = request.getParameter ("username");
Output = response.getWriter ();
Try {Thread. sleep (5000); //為了突出并發(fā)問題，在這設置一個延時
} Catch (Interrupted Exception e){}
output.println("用戶名:"+Username+"<BR>");
}
}

該Servlet中定義了一個實例變量output，在service方法將其賦值為用戶的輸出。當一個用戶訪問該Servlet時，程序會正常的運 行，但當多個用戶并發(fā)訪問時，就可能會出現(xiàn)其它用戶的信息顯示在另外一些用戶的瀏覽器上的問題。這是一個嚴重的問題。為了突出并發(fā)問題，便于測試、觀察， 我們在回顯用戶信息時執(zhí)行了一個延時的操作。假設已在web.xml配置文件中注冊了該Servlet，現(xiàn)有兩個用戶a和b同時訪問該Servlet（可 以啟動兩個IE瀏覽器，或者在兩臺機器上同時訪問）,即同時在瀏覽器中輸入：

　　a： http://localhost: 8080/servlet/ConcurrentTest? Username=a

　　b： http://localhost: 8080/servlet/ConcurrentTest? Username=b

　　如果用戶b比用戶a回車的時間稍慢一點，將得到如圖2所示的輸出：

　　

　　圖2 a用戶和b用戶的瀏覽器輸出

從圖2中可以看到，Web服務器啟動了兩個線程分別處理來自用戶a和用戶b的請求，但是在用戶a的瀏覽器上卻得到一個空白的屏幕，用戶a的信息顯示在用 戶b的瀏覽器上。該Servlet存在線程不安全問題。下面我們就從分析該實例的內(nèi)存模型入手,觀察不同時刻實例變量output的值來分析使該 Servlet線程不安全的原因。

　　Java的內(nèi)存模型JMM（Java Memory Model）JMM主要是為了規(guī)定了線程和內(nèi)存之間的一些關系。根據(jù)JMM的設計，系統(tǒng)存在一個主內(nèi)存(Main Memory)，Java中所有實例變量都儲存在主存中，對于所有線程都是共享的。每條線程都有自己的工作內(nèi)存(Working Memory)，工作內(nèi)存由緩存和堆棧兩部分組成，緩存中保存的是主存中變量的拷貝，緩存可能并不總和主存同步，也就是緩存中變量的修改可能沒有立刻寫到 主存中；堆棧中保存的是線程的局部變量，線程之間無法相互直接訪問堆棧中的變量。根據(jù)JMM，我們可以將論文中所討論的Servlet實例的內(nèi)存模型抽象 為圖3所示的模型。

　　

　　圖3 Servlet實例的JMM模型

　　下面根據(jù)圖3所示的內(nèi)存模型，來分析當用戶a和b的線程（簡稱為a線程、b線程）并發(fā)執(zhí)行時，Servlet實例中所涉及變量的變化情況及線程的執(zhí)行情況，如圖4所示。

調(diào)度時刻	a線程	b線程
T1	訪問Servlet頁面
T2		訪問Servlet頁面
T3	output=a的輸出username=a休眠5000毫秒，讓出CPU
T4		output=b的輸出（寫回主存）username=b休眠5000毫秒，讓出CPU
T5	在用戶b的瀏覽器上輸出a線程的username的值,a線程終止。
T6		在用戶b的瀏覽器上輸出b線程的username的值,b線程終止。

　　圖4 Servlet實例的線程調(diào)度情況

從圖4中可以清楚的看到，由于b線程對實例變量output的修改覆蓋了a線程對實例變量output的修改，從而導致了用戶a的信息顯示在了用戶b的 瀏覽器上。如果在a線程執(zhí)行輸出語句時，b線程對output的修改還沒有刷新到主存，那么將不會出現(xiàn)圖2所示的輸出結果，因此這只是一種偶然現(xiàn)象，但這 更增加了程序潛在的危險性。

　　設計線程安全的Servlet

　　通過上面的分析，我們知道了實例變量不正確的使用是造成Servlet線程不安全的主要原因。下面針對該問題給出了三種解決方案并對方案的選取給出了一些參考性的建議。

　　1、實現(xiàn) SingleThreadModel 接口

該接口指定了系統(tǒng)如何處理對同一個Servlet的調(diào)用。如果一個Servlet被這個接口指定,那么在這個Servlet中的service方法將不 會有兩個線程被同時執(zhí)行，當然也就不存在線程安全的問題。這種方法只要將前面的Concurrent Test類的類頭定義更改為：

Public class Concurrent Test extends HttpServlet implements SingleThreadModel {
…………
}

　　2、同步對共享數(shù)據(jù)的操作

　　使用synchronized 關鍵字能保證一次只有一個線程可以訪問被保護的區(qū)段，在本論文中的Servlet可以通過同步塊操作來保證線程的安全。同步后的代碼如下：

…………
Public class Concurrent Test extends HttpServlet { …………
Username = request.getParameter ("username");
Synchronized (this){
Output = response.getWriter ();
Try {
Thread. Sleep (5000);
} Catch (Interrupted Exception e){}
output.println("用戶名:"+Username+"<BR>");
}
}
}

　　3、避免使用實例變量

　　本實例中的線程安全問題是由實例變量造成的，只要在Servlet里面的任何方法里面都不使用實例變量，那么該Servlet就是線程安全的。

　　修正上面的Servlet代碼，將實例變量改為局部變量實現(xiàn)同樣的功能，代碼如下：

……
Public class Concurrent Test extends HttpServlet {public void service (HttpServletRequest request, HttpServletResponse
Response) throws ServletException, IOException {
Print Writer output;
String username;
Response.setContentType ("text/html; charset=gb2312");
……
}
}

對上面的三種方法進行測試，可以表明用它們都能設計出線程安全的Servlet程序。但是，如果一個Servlet實現(xiàn)了 SingleThreadModel接口，Servlet引擎將為每個新的請求創(chuàng)建一個單獨的Servlet實例，這將引起大量的系統(tǒng)開銷。 SingleThreadModel在Servlet2.4中已不再提倡使用；同樣如果在程序中使用同步來保護要使用的共享的數(shù)據(jù)，也會使系統(tǒng)的性能大大 下降。這是因為被同步的代碼塊在同一時刻只能有一個線程執(zhí)行它，使得其同時處理客戶請求的吞吐量降低，而且很多客戶處于阻塞狀態(tài)。另外為保證主存內(nèi)容和線 程的工作內(nèi)存中的數(shù)據(jù)的一致性，要頻繁地刷新緩存,這也會大大地影響系統(tǒng)的性能。所以在實際的開發(fā)中也應避免或最小化 Servlet 中的同步代碼；在Serlet中避免使用實例變量是保證Servlet線程安全的最佳選擇。從Java 內(nèi)存模型也可以知道，方法中的臨時變量是在棧上分配空間，而且每個線程都有自己私有的棧空間，所以它們不會影響線程的安全。

　　小結

Servlet的線程安全問題只有在大量的并發(fā)訪問時才會顯現(xiàn)出來，并且很難發(fā)現(xiàn)，因此在編寫Servlet程序時要特別注意。線程安全問題主要是由實 例變量造成的,因此在Servlet中應避免使用實例變量。如果應用程序設計無法避免使用實例變量，那么使用同步來保護要使用的實例變量，但為保證系統(tǒng)的 最佳性能，應該同步可用性最小的代碼路徑。

原文出處:http://www.feeten.cn/html/jsp/01/20090102181631103402.html
作者:佚名