servlet后台如何接受multpartfile_Servlet进阶教程（你不得不知道的Servlet知识点）
“ 人生的游戲不在于拿了一副好牌，而在于怎樣去打好壞牌，世上沒有常勝將軍，勇于超越自我者才能得到最后的獎杯?！?br />你好，我是夢陽辰！快和我一起學(xué)習(xí)吧！
精彩回放：
Servlet入門詳細(xì)教程(你不得不知道的Servlet知識點(diǎn))
文章目錄
01.適配器模式
02.GET和POST
????保證前端請求方式和后端程序處理方式一致
????HttpServlet原理
03.HttpServletRequest接口
????Servlet線程安全問題
04.登錄
05.Cookie
????關(guān)于路徑的總結(jié)
06.HttpSession
07.實(shí)現(xiàn)記錄登錄狀態(tài)
01.適配器模式
1.適配器模式(Adapter Pattern)是作為兩個不兼容的接口之間的橋梁。這種類型的設(shè)計(jì)模式屬于結(jié)構(gòu)型模式，它結(jié)合了兩個獨(dú)立接口的功能。
**2.意圖：**將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。適配器模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。
**3.主要解決：**主要解決在軟件系統(tǒng)中，常常要將一些"現(xiàn)存的對象"放到新的環(huán)境中，而新環(huán)境要求的接口是現(xiàn)對象不能滿足的。
我們可以在適配器中提供大量的方法，子類繼承后，可以在子類中直接使用。
4.例如：
1、系統(tǒng)需要使用現(xiàn)有的類，而此類的接口不符合系統(tǒng)的需要。
2、想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作，這些源類不一定有一致的接口。
3、通過接口轉(zhuǎn)換，將一個類插入另一個類系中。(比如老虎和飛禽，現(xiàn)在多了一個飛虎，在不增加實(shí)體的需求下，增加一個適配器，在里面包容一個虎對象，實(shí)現(xiàn)飛的接口。)
當(dāng)然我們也可以讓適配器實(shí)現(xiàn)接口，然后將部分需要的方法改為抽象方法。子類繼承后，只需要實(shí)現(xiàn)抽象方法。代碼不會出現(xiàn)冗余。
使用適配器的優(yōu)點(diǎn)：
1、可以讓任何兩個沒有關(guān)聯(lián)的類一起運(yùn)行。
2、提高了類的復(fù)用。
3、增加了類的透明度。
4、靈活性好。
缺點(diǎn)：
1、過多地使用適配器，會讓系統(tǒng)非常零亂，不易整體進(jìn)行把握。
比如，明明看到調(diào)用的是 A 接口，其實(shí)內(nèi)部被適配成了 B 接口的實(shí)現(xiàn)，一個系統(tǒng)如果太多出現(xiàn)這種情況，無異于一場災(zāi)難。因此如果不是很有必要，可以不使用適配器，而是直接對系統(tǒng)進(jìn)行重構(gòu)。
2.由于 JAVA 至多繼承一個類，所以至多只能適配一個適配者類，而且目標(biāo)類必須是抽象類。
例如：如果當(dāng)前程序中A,B，C類只需要使用CommonIn接口中的m1,m2,m3方法。讓這些類直接事先這個接口，需要實(shí)現(xiàn)更多的方法。當(dāng)只要使用其中部分方法時，這樣做，代碼冗余。
解決方案：
1.寫一個類F，實(shí)現(xiàn)這個接口。(類F即為適配器)
并將部分需要用的方法，用abstract修飾。(即抽象方法)。
2.A,B，C類繼承F類即可。
設(shè)計(jì)模式的分類：
創(chuàng)建型:解決對象的創(chuàng)建問題。
行為型：該模式與方法，行為，算法有關(guān)的設(shè)計(jì)模式。
結(jié)構(gòu)型：更多類，更多對象組合成更大的結(jié)構(gòu)解決某個特定的問題。
常見的設(shè)計(jì)模式：
Gof95:(1995年，四人組提出的23種設(shè)計(jì)模式)
單例模式
工廠模式
適配器模式
迭代模式【集合】
策略模式【集合】
裝飾器模式【IO流】
了解更多
JavaEE模式
**【問題描述】**我們之前所有的Servlet類直接實(shí)現(xiàn)了javax.servlet。Servlet接口。但是這個接口有很多方法是目前不需要的，我們可能只需要編寫service方法。直接實(shí)現(xiàn)Servlet接口代碼，使得代碼冗余，有必要在中間添加一個適配器。以后所有的Servlet類不再直接實(shí)現(xiàn)Servlet接口，應(yīng)該去繼承適配器類。
若在初始化的時候需要執(zhí)行一段特殊的程序，建議重寫參數(shù)的init方法。
02.GET和POST
1.HTTP協(xié)議的詳細(xì)內(nèi)容。
1.1什么是HTTP協(xié)議？
超文本傳輸協(xié)議。
瀏覽器和服務(wù)器之間的一種通訊協(xié)議。
該協(xié)議是W3C負(fù)責(zé)指定的，其實(shí)本質(zhì)上就是數(shù)據(jù)傳送格式提前制定好了。瀏覽器和服務(wù)器都必須按照這種數(shù)據(jù)格式進(jìn)行接收和發(fā)送。
1.2HTTP協(xié)議包括幾部分？
請求協(xié)議：從Browser發(fā)送到Server的時候采用的數(shù)據(jù)傳送格式。
響應(yīng)協(xié)議：從Server發(fā)送到Browser的時候采用的數(shù)據(jù)傳送格式。
1.3請求協(xié)議
請求協(xié)議包括四部分
請求行
消息報頭
空白行
請求體
請求行包括：請求方式 ，URI ，協(xié)議版本號
空白行：專門用來分離消息報頭和請求體的。
1.4響應(yīng)協(xié)議
響應(yīng)協(xié)議包括四部分：
狀態(tài)行
響應(yīng)報頭
空白行
響應(yīng)體
狀態(tài)行:協(xié)議版本號、狀態(tài)碼、狀態(tài)描述信息(狀態(tài)碼：200響應(yīng)正常結(jié)束，404資源為找到，500服務(wù)器內(nèi)部錯誤…)
空白行：分離響應(yīng)報頭和響應(yīng)體2.GET請求和POST請求的區(qū)別。
2.1?什么情況下瀏覽器發(fā)送的請求是GET請求。什么情況下瀏覽器發(fā)送的去請求是POST請求。
只有當(dāng)使用表單from,并且將from標(biāo)簽的method屬性設(shè)置為method="post"才是POST請求，其余剩下所有請求方式都是基于GET請求方式。
2.2?GET請求在請求行上提交數(shù)據(jù)，格式：uri?name=value&name=value
這種提交方式最終提交的數(shù)據(jù)會顯示到瀏覽器的地址欄上。
2.3?POST請求在請求其中提交數(shù)據(jù)，相對安全，提交格式：name=value&name=value…
這種提交方式最終不會再瀏覽器地址欄上顯示。
2.4?POST請求再請求體中提交數(shù)據(jù)，所以POST請求提交數(shù)據(jù)沒有長度的限制【POST可以提交大數(shù)據(jù)】
2.5?GET請求在請求行上提交數(shù)據(jù)，所以GET請求提交的數(shù)據(jù)長度有限制。
2.6?GET請求只能提交字符串?dāng)?shù)據(jù)，POST請求可以提交任何類型的數(shù)據(jù)，包括視頻…,所以文件上傳必須使用POST請求提交。
2.7?GET請求最終的結(jié)果，會被瀏覽器緩存收納。
3 POST請求和GET請求該如何選擇？
有敏感數(shù)據(jù)，必須使用POST
傳送數(shù)據(jù)不是普通字符串，必須使用POST
傳送的數(shù)據(jù)非常多，使用POST
這個請求是為了修改服務(wù)器端資源，使用POST
GET請求多數(shù)情況下是從服務(wù)器讀取資源，這個讀取的資源在短時間之內(nèi)是不會發(fā)生變化的，所以GET請求最終的結(jié)果瀏覽器緩存起來了。
POST請求是為了修改服務(wù)器端的資源，而每一次修改的結(jié)果都是不同的，最終結(jié)果沒有必要被瀏覽器緩存。
數(shù)據(jù)和請求以問號隔開，數(shù)據(jù)之間以&符號連接。
4.安裝httpwatch工具，進(jìn)行HTTP協(xié)議的監(jiān)測。
5.緩存的解決方案
瀏覽器將資源緩存之后，緩存的資源是和某個特定的路徑綁定在一起的，只要瀏覽器再發(fā)送這個相同的請求路徑，這個時候回去緩存中獲取資源，不再訪問服務(wù)器，以這種方式降低服務(wù)器的壓力，提高用戶的體驗(yàn)。但是有的時候，我們不希望走緩存，希望每一次都訪問服務(wù)器，可以在請求路徑后面添加時間戳。
例如：
http://ip:port/xxx/xxx?timestamp=23423424JS怎么獲取毫秒：new Date().getTime();
保證前端請求方式和后端程序處理方式一致
1.前端的頁面發(fā)送的請求方式應(yīng)當(dāng)和服務(wù)器端需要的請求方式一致。
服務(wù)器需要前端發(fā)送POST請求，那前端就應(yīng)該發(fā)送POST請求，若發(fā)送GET請求，服務(wù)器端應(yīng)當(dāng)提示錯誤信息。
服務(wù)器需要前端發(fā)送GET請求，那前端就應(yīng)該發(fā)送GET請求，若發(fā)送POST請求，服務(wù)器應(yīng)當(dāng)提示錯誤信息。
如何完成以上的請求？
在javaweb程序中想辦法獲取該請求是什么類型的請求，POST？還是GET?
當(dāng)我們獲取到請求方式之后，在javaweb程序中可以使用java語言中if語句進(jìn)行判斷。
if(“POST”.equals(method)){
}else if(“GET”.equals(method)){
}
如何獲取請求方式呢？
HTTP的請求協(xié)議全部信息被全部封裝到j(luò)avax.servlet.http.HttpServletRequest對象中。
在HttpServletRequest接口類型中有一個方法叫做：String getMethod();可以獲取請求方式。
public interface javax.servlet.http.HttpServletRequest extends ServletRequest{
}
代碼示例：
public class LoginServlet extends GenericServlet {@Override
public void service(ServletRequest request, ServletResponse response) throws ServletException, IOException {
//將ServletRequest,ServletResponse強(qiáng)制類型轉(zhuǎn)換成帶有Http的接口類型
HttpServletRequest request1 =(HttpServletRequest)request;
HttpServletResponse response1 =(HttpServletResponse)response;
response1.setContentType("text/html;charset=UTF-8");
PrintWriter out = response1.getWriter();
//獲取瀏覽器的請求方式
String method=request1.getMethod();
//LoginServlet是處理登錄的，要求必須發(fā)送POST請求
if("GET".equals(method)){
//后臺報出錯誤，前臺報出錯誤
out.print("你應(yīng)該發(fā)送POST請求！");
throw new RuntimeException("405-你應(yīng)該發(fā)送POST請求");
}
if("POST".equals(method)) {
out.print("正在登錄！");
}
//若程序執(zhí)行到這里說明用戶發(fā)送的是PUT請求，程序應(yīng)該正常執(zhí)行
out.print("當(dāng)前使用的是"+method+"請求！");
}
}
HttpServlet原理
以上代碼每一個Servlet類都需要編寫，怎樣才能封裝一下，以后在每一個具體的servlet類中，不寫這樣的代碼了。
自己封裝：這個HttpServlet類，sun公司替我們寫好了，直接繼承就好了。
總結(jié)servlet編程(重點(diǎn))
1.剛開始我們需要實(shí)現(xiàn)servlet接口。
2.后面我們開始使用適配器Adapter(GenericServlet,自定義的父類。)
3.現(xiàn)在我們使用開始繼承HttpServlet類。重寫什么方法取決于你的請求方式。
因此我們編寫一個類應(yīng)當(dāng)繼承HttpServlet,get請求重謝doGet方法，post請求重謝doPost方法。
doPost/doGet方法可以等同看做main方法。
405狀態(tài)表示前后臺請求方式不同。
比如我們用POST請求方式。模板方法設(shè)計(jì)模式
Servlet規(guī)范中的：HttpServlet
HttpServlet是一個典型的模板方法設(shè)計(jì)模式。
其中的service(HttpServletRequest,HttpServletResponsee方法是典型的模板方法。
該方法定義了核心算法骨架,doGet,DoPost…具體的實(shí)現(xiàn)延遲到子類中完成。
模板類一般是抽象類。
模板方法設(shè)計(jì)模式可以做到，在不改變算法的前提下，可以重新定義算法步驟的具體實(shí)現(xiàn)。模板方法設(shè)計(jì)模式的主要作用：
1.核心算法得到保護(hù)。
2.核心算法得到復(fù)用。
3.在不改變算法的前提之下，卻可以重新定義算法步驟的具體實(shí)現(xiàn)。
03.HttpServletRequest接口
1.繼承關(guān)系：
pulbic interface HttpServletRequest extends ServletRequest{
}
2.HttpServletRequest接口的實(shí)現(xiàn)類是WEB容器負(fù)責(zé)實(shí)現(xiàn)的。Tomcat服務(wù)器有自己的實(shí)現(xiàn)。程序員只需要面向接口調(diào)用方法。
3.HttpServletRequest這個對象封裝了哪些信息呢？
封裝了HTTP請求協(xié)議的全部內(nèi)容。
如：
請求方式
URI
協(xié)議版本號
表單提交的數(shù)據(jù)
…4.HttpServletRequest一般變量的名字叫做：request,表示請求。
HttpServletRequest對象代表一次請求。一次請求對應(yīng)一個request對象。所以request對象的生命周期是短暫的。
5.什么是一次請求。
網(wǎng)頁上點(diǎn)擊超鏈接，到最終網(wǎng)頁停下來。如輸入地址訪問。
6.HttpServletRequest接口常用的方法。
表單提交的數(shù)據(jù)，會自動被封裝到request對象中，request對象中有Map集合存儲這些數(shù)據(jù)，Map集合的key是name,value是一個字符串類型的一維數(shù)組。
String getParameter(String name)
//2.獲取整個Map對象
Map<String,String[]> getParameterMap()
//3.獲取整個Map集合中的所有key
Enumeration<String> getParameterNames()
//4.通過Map集合key獲取value.
String[] getParameterValues(String name)
public class SaveUserServlet extends HttpServlet {
@Override
protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// TODO Auto-generated method stub
//獲取用戶信息，表單提交的這些數(shù)據(jù)被自動封裝到request對象中
//從request獲取這些信息
//表單數(shù)據(jù)是這樣提交的，POST請求，在請求體中提交，數(shù)據(jù)格式：username=admin&password=123...
/* Map
* key value
* ---------------------------
*username {"admin"}
*password {"134"}
*interest {"sport","music"}
*......
* */
String username= request.getParameter("username");
String password= request.getParameter("password");
String sex=request.getParameter("sex");
//String interest=request.getParameter("interest");
String grade= request.getParameter("grade");
String introduce=request.getParameter("introduce");
System.out.println(username);
System.out.println(password);
System.out.println(sex);
//System.out.println(interest);
System.out.println(grade);
System.out.println(introduce);
//獲取所有的興趣愛好
String[] interest=request.getParameterValues("interest");
for(String in:interest) {
System.out.println(in);
}
//獲取整個參數(shù)Map集合
Map<String,String[]>parameterMap=request.getParameterMap();
Set<String> names=parameterMap.keySet();
for(String name:names) {
String[] values = parameterMap.get(name);
System.out.println(name+"=");
for(String value :values) {
System.out.print(value+" ");
}
System.out.println();
}
//獲取參數(shù)Map集合所有的key
Enumeration<String> names1=request.getParameterNames();
while(names1.hasMoreElements()) {
String name=names1.nextElement();
System.out.println(name);
}
}
}
HttpServletRequest是一個怎樣的范圍呢？
HttpServletRequest類型的變量通常命名為：request，代表當(dāng)前的本次請求一次請求對應(yīng)一個request對象，100個請求對應(yīng)100個請求對象。
請求范圍是極小的，request只能完成在同一次請求中傳遞數(shù)據(jù)。
ServletContext 應(yīng)用范圍，可以跨用戶傳遞數(shù)據(jù)。
ServletRequest 請求范圍，只能在同一個請求中傳遞數(shù)據(jù)【可以跨Servlet傳遞數(shù)據(jù)，但是這個Servlet必須在同一個請求中】優(yōu)先選擇request范圍。
解決項(xiàng)目中的中文亂碼問題：
1.亂碼出現(xiàn)在什么位置？
數(shù)據(jù) “傳遞”過程中的亂碼
數(shù)據(jù) “展示”過程中的亂碼
數(shù)據(jù) “保存”過程中的亂碼
2.數(shù)據(jù)保存過程中的亂碼
最終保存到數(shù)據(jù)庫表中的時候，數(shù)據(jù)出現(xiàn)亂碼。
導(dǎo)致數(shù)據(jù)保存過程中的亂碼包括以下兩種情況：
第一種情況：在保存之前，數(shù)據(jù)本身是亂碼，保存到數(shù)據(jù)表中的時候一定是亂碼。
第二種情況：保存之前，數(shù)據(jù)不是亂碼，但是由于數(shù)據(jù)庫不支持中文，保存后出現(xiàn)亂碼。
3.數(shù)據(jù)展示過程中的亂碼：
顯示數(shù)據(jù)出現(xiàn)亂碼。
解決方案：
設(shè)置響應(yīng)的內(nèi)容類型，以及對應(yīng)的字符編碼方式：
response.setContextType(“text/html;charset=UTF-8”);
如果沒有執(zhí)行java程序的html
設(shè)置為
4.數(shù)據(jù)傳遞過程中的亂碼：
將數(shù)據(jù)從瀏覽器發(fā)送給服務(wù)器的時候，服務(wù)器接收到的數(shù)據(jù)是亂碼。
“市場部”對應(yīng)的ISO-8859-1的編碼：%E5%B8%…
ISO-8859-1是國際標(biāo)準(zhǔn)編碼，不支持中文編碼，兼容ASCII碼，又被稱為latin1編碼。
不管哪個國家的文章，在瀏覽器發(fā)送給服務(wù)器的時候，都會采用ISO-8859-1的編碼方式發(fā)送。
發(fā)送給web服務(wù)器之后，web服務(wù)器不知道這些數(shù)據(jù)之前是什么類型的文字。所以會出現(xiàn)亂碼。
解決數(shù)據(jù)傳遞過程中的亂碼：第一種解決方案：萬能方式，既能夠解決POST請求亂碼，又能解決GET請求亂碼。
先將服務(wù)器中接受到的數(shù)據(jù)采用ISO-8859-1的方式解碼，回歸原始狀態(tài)，再給定一種支持簡體中文的編碼方式重新編碼組裝。第二種解決方式：
調(diào)用request的setCharacterEncoding方法，但只適合POST
request.setCharacterEncodeing(“UTF-8”)；
String dname =request.getParameter(“dname”);
System.out.println(dname);
Servlet線程安全問題
1.Servlet是單實(shí)例多線程環(huán)境下運(yùn)行的。
2.什么時候程序存在線程安全問題。
多線程并發(fā)
有共享的數(shù)據(jù)
共享數(shù)據(jù)有修改操作
3.在JVM中，哪些數(shù)據(jù)可能會存在線程安全問題？
局部變量內(nèi)存空間不共享，一個線程一個棧，局部變量在棧中存儲，局部變量不會存在線程安全問題
常量不會被修改，所以常量不會存在線程安全問題。
所有的線程共享一個堆。
堆內(nèi)存中new出來的對象在其中存儲，對象內(nèi)部有“實(shí)例變量”，所以“實(shí)例變量”的內(nèi)存多線程是共享的。實(shí)例變量多線程共同訪問，并且涉及到修改操作的時候就會存在線程安全問題。
所有線程共享一個方法區(qū)
方法區(qū)中有靜態(tài)變量，靜態(tài)變量的內(nèi)存也是共享的，若涉及到修改操作，靜態(tài)變量也存在線程安全問題。
**4.線程安全問題不止是體現(xiàn)在JVM中，**還有可能發(fā)生在數(shù)據(jù)庫中，例如：多個線程共享同一張表，并且同時去修改表中的記錄，那么就存在線程安全問題。
怎么解決數(shù)據(jù)庫表中數(shù)據(jù)的線程安全問題？
第一種方案：使用synchronized關(guān)鍵字
第二種方案：行級鎖【悲觀鎖】
第三種方案：事務(wù)隔離級別，如：串行化
第四種方案：樂觀鎖。
5.怎么解決線程安全問題？
不使用實(shí)例變量，盡量使用局部變量。
若必須使用實(shí)例變量給，那么我們可以考慮將該對象變成多例對象，一個線程一個java對象，實(shí)例變量的內(nèi)存也不會共享。
若必須使用單例，那就只能使用synchronized線程同步機(jī)制，線程一旦排隊(duì)執(zhí)行，則吞吐量降低，降低用戶體驗(yàn)。
6.Servlet怎么解決線程安全問題？
不使用實(shí)例變量，盡量使用局部變量。
Servlet必須是單例的，所以剩下的方式只能考慮synchronized，線程同步機(jī)制。
關(guān)于web系統(tǒng)中資源跳轉(zhuǎn)
跳轉(zhuǎn)包括兩種方式：
轉(zhuǎn)發(fā)：forward
重定向：redirect
轉(zhuǎn)發(fā)：(你向朋友借錢，朋友沒錢，他去借錢然后給你)
從一個java源程序轉(zhuǎn)到另一個源程序。
重定向：將路徑中心發(fā)送給了瀏覽器( 相當(dāng)于一個超鏈接)轉(zhuǎn)發(fā)和重定向的區(qū)別：
**相同點(diǎn)：**都可以完成資源跳轉(zhuǎn)。不同點(diǎn)：
轉(zhuǎn)發(fā)是request對象觸發(fā)的
重定向是response對象觸發(fā)的。
轉(zhuǎn)發(fā)是一次請求，瀏覽器地址欄上的地址不會變化。
重定向是兩次請求，瀏覽器地址欄上的地址發(fā)生變化。
重定向的路徑需要加webapp的根路徑
轉(zhuǎn)發(fā)是在本項(xiàng)目內(nèi)部完成資源跳轉(zhuǎn)。
重定向可以完成跨app跳轉(zhuǎn)資源。
跳轉(zhuǎn)的下一個資源可以是什么？
web服務(wù)器任何資源。什么時候采用轉(zhuǎn)發(fā)，什么時候采用重定向？
若想跨app跳轉(zhuǎn)，必須使用重定向。
希望在下一個資源中從request范圍中將數(shù)據(jù)取出，必須使用轉(zhuǎn)發(fā)。
重定向可以解決瀏覽器刷新問題。重定向的原理是什么？
解決瀏覽器刷新問題
重定向可以解決頁面刷新的問題：刷新只會刷新第二個請求：執(zhí)行第二條請求語句。
而轉(zhuǎn)發(fā)刷新的是第一個請求。
04.登錄
完成用戶登錄
練習(xí)：完成網(wǎng)頁端員工信息的增刪改查。
05.Cookie
1.什么是 Cookie？
Cookie，有時也用其復(fù)數(shù)形式 Cookies。類型為“小型文本文件”，是某些網(wǎng)站為了辨別用戶身份，進(jìn)行Session跟蹤而儲存在用戶本地終端上的數(shù)據(jù)(通常經(jīng)過加密)，由用戶客戶端計(jì)算機(jī)暫時或永久保存的信息。
Cookie 是一些數(shù)據(jù), 存儲于你電腦上的文本文件中。
當(dāng) web 服務(wù)器向?yàn)g覽器發(fā)送 web 頁面時，在連接關(guān)閉后，服務(wù)端不會記錄用戶的信息。
Cookie 的作用就是用于解決 “如何記錄客戶端的用戶信息”:
當(dāng)用戶訪問 web 頁面時，他的名字可以記錄在 cookie 中。
在用戶下一次訪問該頁面時，可以在 cookie 中讀取用戶訪問記錄。
Cookie 以名/值對形式存儲，如下所示:
當(dāng)瀏覽器從服務(wù)器上請求 web 頁面時， 屬于該頁面的 cookie 會被添加到該請求中。服務(wù)端通過這種方式來獲取用戶的信息。
也可以將數(shù)據(jù)保存在服務(wù)器端，但是需要用戶登錄。
2.網(wǎng)站上的十天免登錄功能：
將賬戶信息保存在客戶端硬盤上，并且壽命為10天。
網(wǎng)吧有還原卡，進(jìn)行還原。無需擔(dān)心。
3.Cookie的保存位置
Cookie是保存在瀏覽器客戶端上的
Cookie也可以保存在瀏覽器的緩存中，瀏覽器關(guān)閉Cookie消失。
Cookie也可以保存在客戶端的硬盤文件中，瀏覽器關(guān)閉Cookie還在，除非Cookie失效。
4.Cookie只有在javaweb中才有嗎?
Cookie不止在javaweb中存在。
只要是web開發(fā)，只要是B/S架構(gòu)的系統(tǒng)，只要是HTTP協(xié)議，就有Cookie的存在。
Cookies這種機(jī)制是Http協(xié)議規(guī)定的。
5.Cookie實(shí)現(xiàn)的功能，常見的有哪些？
十天免登錄
購物車數(shù)據(jù)等。
6.Java中Cookie被當(dāng)作類來處理，使用new運(yùn)算可以創(chuàng)建Cookie對象，而且Cookie由兩部分組成，分別是Cookie的name和value，name和value都是字符串類型String。
7.java程序中怎么創(chuàng)建Cookie?
Cookie cookie=new Cookie(String CookieName,String cookieValue);
8.服務(wù)器可以一次向?yàn)g覽器發(fā)送多個Cookie.
9.默認(rèn)情況下，服務(wù)器發(fā)送Cookie給瀏覽器之后，瀏覽器將Cookie保存在緩存中，只要不關(guān)閉瀏覽器，Cookie永遠(yuǎn)存在，并且有效。當(dāng)瀏覽器關(guān)閉之后，緩存中的Cookie被清除了。
10.在瀏覽器客戶端無論是硬盤文件中還是緩存中保存的Cookie,什么時候會再次發(fā)送給服務(wù)器呢？
瀏覽器會不會提交發(fā)送這些Cookie給服務(wù)器，和請求路徑有關(guān)系。
不同的路徑會發(fā)送提交不同的Cookie。
11.默認(rèn)情況下Cookie會和哪些路徑綁在一起？
/webapps/test/xxx
請求服務(wù)器，服務(wù)器生成Cookie，并將Cookie發(fā)送給瀏覽器客戶端。
這個瀏覽器中的Cookie會默認(rèn)和“test/”這個路徑綁定在一起。
也就是說，以后只要發(fā)送“test/”請求，Cookie一定自動提交給服務(wù)器。
如果是：/webapps/test
請求服務(wù)器，服務(wù)器生成Cookie，并將Cookie發(fā)送給瀏覽器客戶端。
這個瀏覽器中的Cookie會默認(rèn)和“webapps/”這個路徑綁定在一起。
也就是說，以后只要發(fā)送“webapps/”請求，Cookie一定會提交給服務(wù)器。
12.其實(shí)路徑可以指定的，可以通過java程序進(jìn)行設(shè)置，保證Cookie和某個特定的路徑綁定在一起。
指定路徑后，Cookie將和指定路徑綁定在一起。13.默認(rèn)情況下，沒有設(shè)置Cookie的有效時間，該Cookie被默認(rèn)保存在瀏覽器的緩存中，只要瀏覽器不關(guān)閉Cookie存在 ，只要關(guān)閉瀏覽器Cookie消失，我們可以通過設(shè)置Cookie的有效時長，以保證Cookie保存在硬盤文件當(dāng)中。但是這個有效時長必須是>0的，換句話說，只要設(shè)置Cookie的有效時長大于0，則該Cookie會被保存在客戶端硬盤文件中。有效時長過去后，硬盤中的，則硬盤當(dāng)中的Cookie失效。
Cookie有效時長=0不會直接被刪除，Cookie有效時長<0不會被存儲，Cookie有效時長>0存儲在硬盤文件當(dāng)中。設(shè)置Cookie的有效時長
Cookie1.setMaxAge(6060);
Cookie2.setMaxAge(6060*24); 1小時有效
14.瀏覽器提交Cookie給服務(wù)器，服務(wù)器怎么接收Cookie？
從request對象中獲取所有提交的Cookie。
Cookie[] cookies = request.getCookies()；if(cookies!=null)
for(Cookie cookie :cookies){
String cookieName=cookie.getName();
String cookieValue=cookie.getValue();
System.out.println(cookieName+"="+cookievalue);
}
15.cookies存在有效時間，決定了存放位置，瀏覽器可以禁用Cookie。
表示服務(wù)器發(fā)送過來的Cookie，瀏覽器不做處理。
關(guān)于路徑的總結(jié)
1.關(guān)于url-pattern的編寫方式和路徑的總結(jié)
1.路徑的編寫形式：
<a href="/項(xiàng)目名/資源路徑"></a>
//表單
<form action="/項(xiàng)目名/資源路徑"></form>
//重定向
response.sendRedirect("項(xiàng)目名/資源路徑");
//轉(zhuǎn)發(fā)
request.getRequestDispatcher("/資源路徑").forward(request,response);
//歡迎頁面
<welcome-file-list>
<welcome-file>資源路徑</welcome-file>
</welcome-file-list>
//servlet路徑
<servlet>
<servlet-name>hello</servlet-name>
<servlet-class>part1.Helloservlet<servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>hello<servlet-name>
<url-pattern>/資源路徑</url-pattern>
</servlet-mapping>
//Cookie設(shè)置Path
cookie.setPath("/項(xiàng)目名/資源路徑");
//ServletContext
ServletContext application =config.getServletContext();
application.getRealPath("/WEB-INF/Classes/db.properties");
application.getRealPath("/資源路徑");
2.url-pattern路徑的編寫方式
1.url-pattern可以編寫多個精確匹配的方式
<servlet-name>hello<servlet-name>
<url-pattern>/hello</url-pattern>
<url-pattern>/system/hello</url-pattern>
</servlet-mapping>
擴(kuò)展匹配的方式
以abc開始的即可。
后綴匹配
<url-pattern>*.action</url-pattern>全部匹配
<url-pattern>/*06.HttpSession
HttpSession簡介
HttpSession是Java平臺對session機(jī)制的實(shí)現(xiàn)規(guī)范，因?yàn)樗鼉H僅是個接口，具體到每個web應(yīng)用服務(wù)器的提供商，除了對規(guī)范支持之外，仍然會有一些規(guī)范里沒有規(guī)定的細(xì)微差異。
JSP利用servlet提供的HttpSession接口來識別一個用戶，存儲這個用戶的所有訪問信息。
默認(rèn)情況下，JSP允許會話跟蹤，一個新的HttpSession對象將會自動地為新的客戶端實(shí)例化。禁止會話跟蹤需要顯式地關(guān)掉它，通過將page指令中session屬性值設(shè)為false來實(shí)現(xiàn)
1.Session表示會話，不止是在javaweb中存在，只要是web開發(fā)，都有會話這種機(jī)制。
2.在java中會話對應(yīng)的類型是：javax.servlet.http.HttpSession,簡稱session
3.Cookie可以將會話保存在客戶端，HttpSession可以將會話狀態(tài)保存在服務(wù)器端。
4.HttpSession對象是一個會話級別的對象，一次會話對應(yīng)一個HttpSession對象。
5.什么是一次會話？
可以理解為：打開瀏覽器發(fā)送多次請求，直到瀏覽器關(guān)閉。
6.在會話過程中，web服務(wù)器一直為當(dāng)前這個用戶維護(hù)著一個會話對象/HttpSession
7.在WEB容器中，WEB容器維護(hù)了大量的HttpSession對象，換句話說，在WEB容器中應(yīng)該有一個"session列表"。
思考：為什么當(dāng)前會話中的每一次請求可以獲取到屬于自己的會話對象？
瀏覽器首次發(fā)送請求，服務(wù)器會創(chuàng)建一個HttpSession對象，該對象代表一次會話。
同時生成HttpSesion對象對應(yīng)的Cookie對象，并且Cookie對象的name是JSESSIONID。Cookie的value是32位長度的字符串。
服務(wù)器將Cookie的value和HttpSession對象綁定到session列表中。
服務(wù)器將Cookie完整的發(fā)送給瀏覽器客戶端。
瀏覽器客戶端將Cookie保存到緩存中，只要瀏覽器不關(guān)閉，Cookie不會消失，當(dāng)再次發(fā)送請求的時候，會自動提交緩存當(dāng)中的Cookie.服務(wù)器收到Cookie，驗(yàn)證Cookie的的name確實(shí)是：JSESSIONID,獲取Cookie的value,通過Cookie的value區(qū)檢索session列表。
瀏覽器發(fā)送Cookie給服務(wù)器，通過Cookie的值去找session對象。
8.和HttpSession對象關(guān)聯(lián)的這個Cookie的name是比較特殊的，在java中叫做：jsessionid。
** 9.瀏覽器禁用Cookie會出現(xiàn)什么問題？怎么解決？**
瀏覽器禁用Cookie,則瀏覽器緩存中不再保存Cookie。
導(dǎo)致在同一個會話中，無法獲取到對應(yīng)的會話的對象。每次獲取的會話對象都是新的。
瀏覽器禁用Cookie之后，若還想拿到Session對象，必須重寫URL機(jī)制，怎么重寫URL?
URL;jsessionid=xxxxxxxxxxxxxxxxx重寫URL會給編程帶來難度。所以盡量不要禁用。10.瀏覽器關(guān)閉之后，服務(wù)器對應(yīng)的session對象會被銷毀嗎？為什么？
不會！
因?yàn)锽/S架構(gòu)的系統(tǒng)基于HTTP協(xié)議，而HTTP協(xié)議是一種無連接/無狀態(tài)的協(xié)議。
請求的瞬間和服務(wù)器之間的通道是打開的，請求響應(yīng)結(jié)束后，通道關(guān)閉。
這樣做的目的是降低服務(wù)器的壓力。
11.session對象在什么時候被銷毀？
web系統(tǒng)中引入session超時的概念。
當(dāng)很長一段時間(這個時間可以配置)沒有用戶在訪問該session對象，此時session對象超時，web服務(wù)器自動回收session對象。
12.什么是一次會話？
一般講：瀏覽器打開進(jìn)行一些操作后，關(guān)閉瀏覽器。
本質(zhì)上：瀏覽器session被創(chuàng)建到session對象超時之后銷毀。
web.xml設(shè)置超時時間，默認(rèn)為30分鐘
<session-config><session-timeout>120</session-timeout>
</session-config>
13.HttpSession接口常用的方法
//獲取當(dāng)前的session，獲取不到則新建sessionHttpSession session = request.getSession();
//獲取當(dāng)前的session，獲取不到，則新建session
HttpSession session = request.getSession(true);
//獲取當(dāng)前的session,獲取不到，則返回null
HttpSession session = request.getSession(flase);
//
void setAttribute(String name Object value);
//
Object getAttribut(String name)
//
void removeAttribute(String name);
//銷毀session
void invalidate();
14.ServletContext,HttpSession,HttpServletRequest接口的對比：
14.1 以上都是范圍對象：
ServletContext application;是應(yīng)用范圍。
HttpSession session是會話范圍。
HttpServletRequest request；是請求范圍。
14.2 三個范圍的排序
application>session>request
14.3 application完成跨會話共享數(shù)據(jù)、session完成跨請求傳遞數(shù)據(jù)，但是這些請求必須在同一個會話當(dāng)中。
request完成跨Servlet共享數(shù)據(jù)，但是這些Servlet必須在同一個請求當(dāng)中【轉(zhuǎn)發(fā)】。
14.4 使用的原則：從小到大嘗試，優(yōu)先使用小范圍。
如：登入成功這個狀態(tài)保存至sessoin對象中。
登錄成功狀態(tài)不能保存到request范圍中，因?yàn)橐淮握埱髮?yīng)一個新的request對象。
登錄成功狀態(tài)也不能保存到application范圍中，因?yàn)榈卿洺晒顟B(tài)是屬于會話級別的，不能所有用戶共享。
“ 生活是不公平的，不管你的境遇如何，你只能全力以赴。任何時候，不要過分去糾結(jié)公平與否，全力以赴，無怨無悔，輕松笑對得與失?！蔽沂菈絷柍?#xff0c;與你共進(jìn)退！別忘記素質(zhì)三連哦！
總結(jié)
以上是生活随笔為你收集整理的servlet后台如何接受multpartfile_Servlet进阶教程（你不得不知道的Servlet知识点）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： unfold3d自动展uv_Maya20
- 下一篇： 带冲突检测的载波监听多路访问的原理_通信