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

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

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

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

以下是我個(gè)人觀點(diǎn)，僅供參考。

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

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

GET：

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

POST：

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

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

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

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

5.   為了避免亂碼，客戶端應(yīng)該如何做？

GET：

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

POST：

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

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

　　Servlet的多線程機(jī)制

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

　　

　　圖1 Servlet線程池

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

　　Servlet的線程安全問(wèn)題

　　Servlet的線程安全問(wèn)題主要是由于實(shí)例變量使用不當(dāng)而引起的，這里以一個(gè)現(xiàn)實(shí)的例子來(lái)說(shuō)明。

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ā)問(wèn)題，在這設(shè)置一個(gè)延時(shí)
} Catch (Interrupted Exception e){}
output.println("用戶名:"+Username+"<BR>");
}
}

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

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

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

　　如果用戶b比用戶a回車的時(shí)間稍慢一點(diǎn)，將得到如圖2所示的輸出：

　　

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

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

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

　　

　　圖3 Servlet實(shí)例的JMM模型

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

調(diào)度時(shí)刻	a線程	b線程
T1	訪問(wèn)Servlet頁(yè)面
T2		訪問(wèn)Servlet頁(yè)面
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實(shí)例的線程調(diào)度情況

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

　　設(shè)計(jì)線程安全的Servlet

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

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

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

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

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

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

…………
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、避免使用實(shí)例變量

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

　　修正上面的Servlet代碼，將實(shí)例變量改為局部變量實(shí)現(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");
……
}
}

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

　　小結(jié)

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

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

File類是用來(lái)構(gòu)造文件或文件夾的類,在其構(gòu)造函數(shù)中要求傳入一個(gè)String類型的參數(shù),用于指示文件所在的路徑.以前一直使用絕對(duì)路徑作為參數(shù),其實(shí)這里也可以使用相對(duì)路徑.使用絕對(duì)路徑不用說(shuō),很容易就能定位到文件,那么使用了相對(duì)路徑jvm如何定位文件的呢?

按照jdk Doc上的說(shuō)法”絕對(duì)路徑名是完整的路徑名，不需要任何其他信息就可以定位自身表示的文件。相反，相對(duì)路徑名必須使用來(lái)自其他路徑名的信息進(jìn)行解釋。默認(rèn)情況下，java.io 包中的類總是根據(jù)當(dāng)前用戶目錄來(lái)分析相對(duì)路徑名。此目錄由系統(tǒng)屬性 user.dir 指定，通常是 Java 虛擬機(jī)的調(diào)用目錄.”

相對(duì)路徑顧名思義,相對(duì)于某個(gè)路徑,那么究竟相對(duì)于什么路徑我們必須弄明白.按照上面jdk文檔上講的這個(gè)路徑是”當(dāng)前用戶目錄”也就是”java虛擬機(jī)的調(diào)用目錄”.更明白的說(shuō)這個(gè)路徑其實(shí)是我們?cè)谀睦镎{(diào)用jvm的路徑.舉個(gè)例子:

假設(shè)有一java源文件Example.java在d盤根目錄下,該文件不含package信息.我們進(jìn)入命令行窗口,然后使用”d:”命令切換到d盤根目錄下,然后用”javac Example.java”來(lái)編譯此文件,編譯無(wú)錯(cuò)后,會(huì)在d盤根目錄下自動(dòng)生成”Example.class”文件.我們?cè)谡{(diào)用”java Example”來(lái)運(yùn)行該程序.此時(shí)我們已經(jīng)啟動(dòng)了一個(gè)jvm,這個(gè)jvm是在d盤根目錄下被啟動(dòng)的,所以此jvm所加載的程序中File類的相對(duì)路徑也就是相對(duì)這個(gè)路徑的,即d盤根目錄:D:\.同時(shí)” 當(dāng)前用戶目錄”也是D:\.在System.getProperty(“user.dir”);系統(tǒng)變量”user.dir”存放的也是這個(gè)值.

我們可以多做幾次試驗(yàn),把”Example.class”移動(dòng)到不同路徑下,同時(shí)在那些路徑下,執(zhí)行”java Example”命令啟動(dòng)jvm,我們會(huì)發(fā)現(xiàn)這個(gè)”當(dāng)前用戶目錄”是不斷變化的,它的路徑始終和我們?cè)谀膯?dòng)jvm的路徑是一致的.

搞清了這些,我們可以使用相對(duì)路徑來(lái)創(chuàng)建文件,例如:

File file = new File(“a.txt”);

File.createNewFile();

假設(shè)jvm是在”D:\”下啟動(dòng)的,那么a.txt就會(huì)生成在D:\a.txt;

此外,這個(gè)參數(shù)還可以使用一些常用的路徑表示方法,例如”.”或”.\”代表當(dāng)前目錄,這個(gè)目錄也就是jvm啟動(dòng)路徑.所以如下代碼能得到當(dāng)前目錄完整路徑:

File f = new File(“.”);

String absolutePath = f.getAbsolutePath();

System.out.println(absolutePath);//D:\

最后要說(shuō)說(shuō)在eclipse中的情況:

Eclipse中啟動(dòng)jvm都是在項(xiàng)目根路徑上啟動(dòng)的.比如有個(gè)項(xiàng)目名為blog,其完整路徑為:D:\work\IDE\workspace\blog.那么這個(gè)路徑就是jvm的啟動(dòng)路徑了.所以以上代碼如果在eclipse里運(yùn)行,則輸出結(jié)果為” D:\work\IDE\workspace\blog.”

Tomcat中的情況.

如果在tomcat中運(yùn)行web應(yīng)用,此時(shí),如果我們?cè)谀硞€(gè)類中使用如下代碼:

File f = new File(“.”);

String absolutePath = f.getAbsolutePath();

System.out.println(absolutePath);

那么輸出的將是tomcat下的bin目錄.我的機(jī)器就是” D:\work\server\jakarta-tomcat-5.0.28\bin\.”,由此可以看出tomcat服務(wù)器是在bin目錄下啟動(dòng)jvm的.其實(shí)是在bin目錄下的” catalina.bat”文件中啟動(dòng)jvm的.

通常所說(shuō)的cookie實(shí)際上可以分為2種,一種是由Cookie對(duì)象產(chǎn)生的保存在客戶端硬盤上的持久化的cookie,另一種就是由session對(duì)象產(chǎn)生的保存在瀏覽器內(nèi)存里的session cookie.session cookie的組成是形如: JSESSIONID=0EB8CEDE030A4B6FB5366317D8BF1978(tomcat下).Session cookie何時(shí)產(chǎn)生?當(dāng)新創(chuàng)建一個(gè)session對(duì)象時(shí)產(chǎn)生session cookie.當(dāng)使用request.getSession()或request.getSession(true)方法時(shí),如果請(qǐng)求范圍內(nèi)根據(jù)jsessionid能夠找到一個(gè)對(duì)應(yīng)的session對(duì)象,則不產(chǎn)生session cookie也不返回給客戶端保存,找不到則新創(chuàng)建一個(gè)session cookie并生成一個(gè)形如JSESSIONID=0EB8CEDE030A4B6FB5366317D8BF1978(tomcat下)的session cookie并放在本次響應(yīng)頭信息中返回給客戶端保存,客戶端之前保存的session cookie也將被這個(gè)session cookie所代替.與session cookie不同的是,如果服務(wù)器端明確使用Cookie類來(lái)生成的持久化cookie將在每次響應(yīng)中返回給客戶端保存,不管客戶端是否存在這個(gè)cookie.當(dāng)瀏覽器接受cookie后(不管是持久化cookie還是session cookie),在對(duì)同一站點(diǎn)進(jìn)行訪問(wèn)時(shí),會(huì)自動(dòng)把這些cookie信息放在請(qǐng)求頭信息中一起發(fā)送給服務(wù)器端.這樣服務(wù)器端就能得到這些cookie來(lái)跟蹤會(huì)話.向服務(wù)器端發(fā)送cookie這個(gè)過(guò)程對(duì)用戶來(lái)是完全透明的,是瀏覽器自動(dòng)進(jìn)行的.

以上討論是在瀏覽器接受cookie的情況下,下面談?wù)劄g覽器禁用cookie的情況.

如果瀏覽器禁用了cookie,那么瀏覽器不會(huì)接收保存服務(wù)器端存在響應(yīng)頭中的cookie信息(ie6有bug,會(huì)保存session cookie).瀏覽器再次訪問(wèn)同一站點(diǎn)時(shí),請(qǐng)求頭信息里也不會(huì)攜帶任何cookie信息的(因?yàn)闉g覽器根禁止了該功能).正因如此,服務(wù)器端接收不到客戶端的cookie信息,也就無(wú)法識(shí)別客戶端的身份,從而把它當(dāng)作一個(gè)新的客戶對(duì)待,也就會(huì)丟失以前的會(huì)話信息.在這種情況下服務(wù)器端使用request.getSession()或request.getSession(true)方法時(shí)將會(huì)重新創(chuàng)建一個(gè)session.

那么如何在用戶禁用了cookie的情況下維護(hù)會(huì)話呢?以上討論我們已經(jīng)知道,服務(wù)器端判斷是新的會(huì)話還是舊的會(huì)話是根據(jù)請(qǐng)求頭中是否有一個(gè)jsessionid的.由于瀏覽器禁用了cookie從而不會(huì)自動(dòng)向服務(wù)器發(fā)送這個(gè)參數(shù),那么要維持會(huì)話就需要我們自己每次服務(wù)器發(fā)送請(qǐng)求時(shí)帶上這個(gè)參數(shù).url重寫正是這樣一種技術(shù),只要在我們的代碼中把所有向服務(wù)器發(fā)送請(qǐng)求的地方用response.encodeRedirectUrl(String arg0)包裝一下,這樣我們請(qǐng)求的url就會(huì)自動(dòng)加上當(dāng)前session對(duì)象產(chǎn)生的jsessionid.服務(wù)器端也能取得這個(gè)值從而識(shí)別客戶端.     splice方法是javascript中數(shù)組的一個(gè)方法,其功能是:可向數(shù)組刪除并加入新的元素.其方法聲明如下:
index:必選項(xiàng).指定在哪個(gè)位置加入/刪除元素,必須是數(shù)字.
howmany:必選項(xiàng).指定有多少元素應(yīng)該被刪除,必須是數(shù)字,可以是"0".
element1:可選.指定要加入到數(shù)組中的新元素.
elementX:可選.可以加入多個(gè)元素.
說(shuō)明:如果howmany為0或"0",則該數(shù)組中將沒(méi)有元素被刪除,那么element1至elementX個(gè)參數(shù)將從index指定的位置插入到該數(shù)組中,數(shù)組中原位置的元素將后移.如果howmany不為0,則從index指定位置開始刪除howmany個(gè)元素(包括index位置的元素),然后再?gòu)膇ndex開始插入element1至elementX個(gè)參數(shù),數(shù)組中原位置的元素將后移.
例1:
輸出結(jié)果為:
例2:
輸出結(jié)果為:
例3:
輸出結(jié)果為:
        終于到了要離開的一天,畢業(yè)之后來(lái)到這家公司,從一個(gè)畢業(yè)生成長(zhǎng)為一個(gè)程序員,經(jīng)歷過(guò)許多辛酸與磨煉,回想往事,眼前浮現(xiàn)出曾經(jīng)那一張張熟悉的面孔.謝謝曾經(jīng)給過(guò)我?guī)椭耐屡c朋友,沒(méi)有你們也沒(méi)有今天的我,希望大家越來(lái)越好,也希望公司越來(lái)越好,也希望自己能有個(gè)美好的未來(lái).         眾所周知,javascript中的繼承是通過(guò)原型對(duì)象(prototype)來(lái)實(shí)現(xiàn)的.原型對(duì)象是由函數(shù)的構(gòu)造函數(shù)創(chuàng)建,它所擁有的屬性能被所有對(duì)象共享.初始時(shí)原型對(duì)象指向一個(gè)Object對(duì)象,并且定義了一個(gè)constructor屬性,該屬性指向定義該原型對(duì)象的構(gòu)造函數(shù)本身,上述過(guò)程可以理解為以下代碼:
因?yàn)樵蛯?duì)象的所有屬性能被構(gòu)造函數(shù)創(chuàng)建對(duì)象共享,所以創(chuàng)建的對(duì)象可以訪問(wèn)這里的constructor屬性:
由于對(duì)象本身也可以自定義屬性,所以在讀取對(duì)象屬性時(shí)js先檢查該對(duì)象是否定義了該屬性,如果已經(jīng)定義了則使用該屬性,如果沒(méi)有定義則再?gòu)钠湓蛯?duì)象中讀取該屬性,所以如果對(duì)象自定義的屬性和其原型中的屬性存在重名則自定義屬性"隱藏"了其原型對(duì)象中的同名屬性.例:
加入上述代碼之后再次調(diào)用c.constructor(),則會(huì)打印出"This is c".這是因?yàn)閏已自定義constructor屬性"隱藏"了其原型對(duì)象中的constructor屬性.當(dāng)然js保證了讀寫的不對(duì)稱性,也就是說(shuō)讀取一個(gè)對(duì)象的屬性時(shí)有可能要從其原型對(duì)象中去讀取,但寫一個(gè)對(duì)象的屬性時(shí)卻從不涉及其原型對(duì)象,無(wú)論在一個(gè)對(duì)象加入或修改多少屬性這都不影響其原型對(duì)象中屬性的本來(lái)面目.比如這里c自定義了constructor屬性,但這一行為并不影響其原型對(duì)象中constructor指向其構(gòu)造函數(shù)這一事實(shí),如果再創(chuàng)建一個(gè)對(duì)象且不自定義constructor屬性,再調(diào)用constructor則依然調(diào)用對(duì)象的構(gòu)造函數(shù),例:

很容易理解js為什么這樣做,因?yàn)橐粋€(gè)對(duì)象的行為不能影響到其他對(duì)象,否則將會(huì)造成混亂.
        理解上述規(guī)則之后讓我們看看js中是如何通過(guò)原型對(duì)象實(shí)現(xiàn)繼承的.當(dāng)我們創(chuàng)建一個(gè)對(duì)象時(shí),可以把該對(duì)象看成是由2部分組成的,一部分存儲(chǔ)了該對(duì)象自己定義的屬性(稱為A部分),而另一個(gè)部分則存儲(chǔ)了其構(gòu)造函數(shù)所定義的原型對(duì)象引用(稱為B部分),例如這里的BaseClass.prototype.當(dāng)讀取對(duì)象的屬性時(shí)可以分為以下2步:
1.js先檢查該對(duì)象引用所指向的內(nèi)存區(qū)域的A部分是否存在該屬性,如果存在則讀出.
2.如果沒(méi)有則再?gòu)腂部分存儲(chǔ)的引用(BaseClass.prototype)所指向的內(nèi)存區(qū)域中讀取該屬性.

從步驟2開始這就是個(gè)不斷往上尋找的過(guò)程,因?yàn)锽aseClass.prototype所指向的內(nèi)存區(qū)域也會(huì)分為A和B兩個(gè)部分,如果再A部分也不存在該屬性,則又會(huì)從其B部分所指向的內(nèi)存區(qū)域去尋找該屬性,而該內(nèi)存區(qū)域也有A和B兩個(gè)部分,如果A部分仍然不存在,則還要從B部分所指向的內(nèi)存區(qū)域去尋找該屬性,直到達(dá)到最頂層的Object類.所以在無(wú)形當(dāng)中就形成了一條鏈,也就是我們常說(shuō)的原型鏈.如果理解了這個(gè)過(guò)程我想也就能了解原型對(duì)象了.下面簡(jiǎn)單分析下b.constructor();的調(diào)用過(guò)程便于加深理解.
1.js會(huì)在b所指向的內(nèi)存區(qū)域A部分讀取constructor屬性.
2.當(dāng)發(fā)現(xiàn)沒(méi)有該屬性后再?gòu)钠漕惖臉?gòu)造函數(shù)原型對(duì)象引用所指向的內(nèi)存區(qū)域讀取該屬性.因?yàn)樵蛯?duì)象引用初始時(shí)指向一Object對(duì)象內(nèi)存區(qū)域(BaseClass.prototype = new Object();)
3.再?gòu)拇薕bject對(duì)象的A部分尋找constructor屬性.
4.沒(méi)有找到該屬性則從其類的原型對(duì)象即Object.prototype中去尋找constructor.
5.如果找到該屬性則調(diào)用.
6.否則,到達(dá)鏈的頂端,返回.
到此能很清楚的知道js中是如何實(shí)現(xiàn)繼承的,如果我們自定義的類不想繼承自O(shè)bject,則可以修改其prototype的指向,可以讓其指向任意一個(gè)類,這樣也就實(shí)現(xiàn)了繼承自定義類,但js中所有的類都繼承自O(shè)bject類,所以原型鏈的關(guān)系仍然存在.

    項(xiàng)目中經(jīng)常使用createDelegate()方法來(lái)創(chuàng)建代理函數(shù),從而改變當(dāng)前函數(shù)中this的作用域.看下了源碼,發(fā)現(xiàn)是通過(guò)js中的apply()方法來(lái)實(shí)現(xiàn),想想也只能通過(guò)apply()或者call()方法來(lái)實(shí)現(xiàn),因?yàn)閖s中只有這2個(gè)方法提供了改變當(dāng)前函數(shù)內(nèi)部this作用域的功能.此外,Ext中很多地方用到了call()和apply()方法,要想看懂源碼,則必須先搞清這2個(gè)方法的用法.
    createDelegate方法聲明為: 其中obj表示函數(shù)內(nèi)部this作用域的范圍,args是數(shù)組,appendArgs是"Boolean或Number",如果appendArgs是Boolean型的且值為true,那么args參數(shù)將跟在調(diào)用代理方法時(shí)傳入的參數(shù)后面組成數(shù)組一起傳入當(dāng)前方法,否則只傳入args,如果appendArgs為Number型,那么args將插入到appendArgs指定的位置.
注意點(diǎn):
1.函數(shù)內(nèi)部的arguments關(guān)鍵字是函數(shù)執(zhí)行時(shí)動(dòng)態(tài)創(chuàng)建的,用來(lái)存儲(chǔ)調(diào)用函數(shù)時(shí)所傳入?yún)?shù).這里第4行的arguments   并不指調(diào)用createDelegate方法所傳入的參數(shù)(obj,args,appendArgs),而是指調(diào)用return function()時(shí)所傳入的參數(shù),即調(diào)用代理函數(shù)時(shí)所傳入的參數(shù).而args和appendArgs就是調(diào)用createDelegate方法時(shí)所傳入的參數(shù).總的來(lái)說(shuō),函數(shù)是在定義它的作用域中執(zhí)行,而不是在調(diào)用它的作用域中執(zhí)行.但也有特殊,比如這里的arguments.
2.call和apply的區(qū)別.
二者的第一個(gè)參數(shù)都是函數(shù)內(nèi)部this的作用域,call的參數(shù)只能作為一串參數(shù)傳入,而apply可以傳入數(shù)組或arguments對(duì)象.如
fun.call(window,args0,args1,.....);
fun.apply(window,[1,2,3]);
但要注意的是apply方法傳遞到函數(shù)內(nèi)部的參數(shù)實(shí)際也是作為一個(gè)個(gè)參數(shù)傳遞的.如果在fun內(nèi)部測(cè)試arguments.length的話,則長(zhǎng)度為3.同樣,我們可以采用arguments[0],arguments[1],arguments[2]來(lái)分別引用1,2,3三個(gè)參數(shù),而不是用arguments[0][0],arguments[0][1],arguments[0][2]來(lái)引用3個(gè)參數(shù).這樣才能解釋11行的代碼.