Servlet相關

Servlet請求路徑

具體請求路徑:(經常使用這種,其餘的架構師經常使用)

瀏覽器請求的地址與當前Servlet中的<url-pattern>中內容徹底一致
以'/'開頭

前置請求路徑:

<url-pattern>/abc/*</url-pattern>(例子)
'*'是一個通配符,表任意長度字符串

後置請求路徑:

<url-pattern>*.do</url-pattern>(例子)

通配符請求路徑:

<url-pattern>/*</url-pattern>(全部網址均可訪問)

請求路徑優先級:具體>前置>通配符>後置

Servlet實例對象的生命週期

1. 項目中全部的Servlet實例對象都由tomcat負責建立,開發人員無權建立

2. 建立時機:

   1. 默認狀況下,第一次訪問時,tomcat建立實例對象
   2. 人工干預,在tomcat啓動的時候建立.在配置文件中的Servlet標籤中加入load-on-startup標籤,裏面放一個大於0的整數就行
   3. 在tomcat運行期間,一個Servlet實現類只能被建立一個實例對象
   4. 在tomcat關閉時,由tomcat負責銷燬全部Servlet實例對象

---

Servlet開發時使用的五種工具對象

1. HttpServletResponse接口:負責將運行結果寫入到響應包
2. HttpServletRequest接口:讀取請求協議包信息
3. ServletContext接口:可爲當前網站中的全部Servlet提供共享數據
4. Cookie:在一次會話過程當中,存儲瀏覽器在服務端產生的私人數據
5. HttpSession接口：在一次會話過程當中，存儲瀏覽器在服務端產生的私人數據

HttpServletResponse接口:

1. 來自Servlet規範中的接口,實現類由tomcat負責提供
2. 其修飾的對象通常稱爲"響應對象"
3. 將相關數據寫入到響應頭和響應體

如何將"英文字符串"寫入到響應體
String str="hello";
從響應對象得到一個"輸出流"
PrintWriter out =Response.getWriter();
out.write(str);

若是將字符串替換成int 50呢?網頁結果是2.
out.write()方法只能將"字符串"或"unicode碼"寫入到響應體
值爲50的unicode碼對應的字符串"2"
此時換用print()方法.可將任意類型數據寫入到響應體中並保持原有類型

String str="明天休息";
out.write(str);
結果顯示亂碼

瀏覽器是根據響應頭中設置的字符集對接收內容進行解碼
在默認狀況下響應頭的字符集爲ISO-8859-1
在得到輸出流以前設置響應頭中字符集
String str="下課休息";
response.setCharacterEncoding("GBK");
response.getWriter().writer(str);

String str="apple<br/>oranger<br/>egg";
通常瀏覽器默認狀況下響應頭中[內容類型]是test
設置響應頭內容類型
response.setcontentType("text/html;charset=GBK");

寫一個Servlet用來經過JDBC查詢表,並把表信息寫入到響應體中

HttpServletRequest接口:

其修飾對象request,稱爲響應對象.可讀取請求協議包相關信息,相似於Scanner
request.getRequestURL();獲取請求地址
request.getMethod();獲取請求方法
request.getParameterNames();獲取請求頭(體)中的請求參數名
request.getParameter("請求參數名");返回一個字符串(單個請求參數)
request.getParameterValues("請求參數名");返回一個數組(多個同名參數)複選框做爲參數時

請求對象和響應對象的生命週期

1. 每當Tomcat收到一個請求協議包時,會爲其建立一對請求對象和響應對象
2. 一次請求對應一對請求對象和響應對象
3. Servlet被請求時,Tomcat將兩個對象做爲參數傳入到服務方法中(doGet/doPost)
4. 服務方法工做完畢後,Tomcat負責銷燬兩個對象
5. Tomcat負責將響應包推送到瀏覽器上

當瀏覽器以Get方式發送請求時,請求參數存放在請求頭,在請求協議包到達服務端時,請求頭的內容由Tomcat解析,Tomcat9.0在解析數據時,默認採用的字符集是utf-8.此時瀏覽器發送的中文參數不會再服務端出現亂碼問題
以Post方式發送請求時,請求參數存放在請求體中,到達服務端時由對應的請求對象負責解析,request對象默認使用ISO-8859-1字符集,此時請求出現中文字符會出現亂碼問題
方案:在request對象解析數據前,從新設置使用字符集
request.setCharacterEncoding("utf-8");
String value=request.getParameter("參數");

---

ServletContext接口

1.servlet規範中的一個接口,接口實現類由Tomcat負責提供
2.爲當前工程中的全部servlet提供共享數據
3.習慣將其修飾對象稱爲全局做用域對象

在Tomcat啓動時, 由其建立全局做用域對象,一個網站只能有一個全局做用域對象,當網站關閉時,由Tomcat負責銷燬
向Tomcat索要當前工程的全局做用域對象
ServletContext application = request.getServletContext();


共享數據的來源
1.開發人員添加到web.xml中
    <context-param>
        <param-name>共享數據名稱</param-name>
        <param-value>共享數據內容</param-value>
    </context-patam>
    共享數據內容=application.getInitParameter("共享數據名稱");
    此時共享數據只能讀取,不能修改.
2.由某個servlet將數據寫入全局做用域對象中,其餘servlet可使用
    寫入:application.serAttribute("共享數據名",共享數據內容); 數據可任意類型
    獲取:application.getAttribute("共享數據名");
    此時servlet的數據能夠被修改,一樣使用setAttribute將共享數據名覆蓋便可

---

會話

瀏覽器和服務端一次完整的交流
特色:

1. 一次會話經歷屢次請求和響應
2. 一次會話訪問多個不一樣的servlet

cookie 和 HttpSession

Cookie

是servlet規範提供的一個工具類
在參與一次會話的servlet之間實現數據共享
Cookie存儲在瀏覽器上,保存本次會話的共享數據

原理:(A和B均表明不一樣的servlet)
    瀏覽器訪問A時,A負責將數據保存到cookie,再有response響應到瀏覽器,當瀏覽器再訪問B時,須要無條件將已存在的cookie推送給B,這樣A和B之間就實現了數據共享
    
Cookie的使用:一個cookie只能存儲一個鍵值對,並只能存儲String類型數據
    建立
    Cookie c1=new Cookie("key","value");
    寫入
    response.addCookie(c1);
    讀取
    Cookie array[]=request.getCookies();
    cookie.getName();讀取關鍵字
    cookie.getValue();讀取數據內容
生命週期:
    cookie是存儲在瀏覽器中的,因此通常狀況下,瀏覽器關閉時,cookie會被銷燬
    人工干預存活時間:
    cookie.setMaxAge(以秒爲單位);設定cookie在硬盤上存活的時間

HttpSession

來自servlet規範的一個接口,實現類來自Tomcat
其修飾對象爲會話做用域對象,或session對象

與cookie的區別:
    cookie存儲在客戶端的瀏覽器或硬盤當中,
    session存儲在服務端的內存中
    
    cookie只能存儲String數據
    session能夠存儲任意類型的數據
    
    一個cookie只能存儲一個鍵值對
    一個session能夠存儲任意數量的鍵值對
    
使用:
    瀏覽器來訪時,Tomcat不會主動建立相應的HttpSession對象,須要servlet提出要求
    HttpSession session=request.getSession();
    HttpSession session=request.getSession(true);
    若當前瀏覽器在服務端已有一個session對象,Tomcat將此session返回,若沒有則新建一個session對象返回(如來訪用戶身份已獲得確認)
    HttpSession session=request.getSession(false);
    如有則返回,若沒有則返回null(當用戶身份未獲得確認)
    
    session.setAttribute("key",共享數據);
    session.getAttribute("key");
原理:
在Tomcat建立了一個SESSION對象時，爲SESSION對象生成一個惟一編號而後將這個編號保存到cookie中，推送到當前的瀏覽器內存中
等到瀏覽器再次發送請求時，Tomcat就能夠經過讀取瀏覽器返回的cookie來判斷瀏覽器在服務端中是否有session對象

---

Http狀態碼

Http狀態碼通知瀏覽器在收到響應包以後的行爲,及告知瀏覽器,服務端沒法提供本次服務的緣由
1xx:通知瀏覽器本次返回資源文件並不完整,須要瀏覽器向服務端再次發送請求
2xx:傳送文件完整
    200:正常狀態碼,瀏覽器和服務端進行了一次完美的通訊
3xx:服務器給瀏覽器推送的是一個網址,瀏覽器在接收到該網址後要馬上向該網址發送請求
    response.sendRedirect("地址");
4xx:通知瀏覽器,服務端沒法提供本次服務的緣由,是因爲服務端沒有相應資源
    400:服務端沒有相應的資源
    405:服務端有處理本次請求的servlet,但該servlet不支持當前瀏覽器的請求方式.如瀏覽器已get方式請求服務端,但相應servlet沒有重寫doGet方法.
5xx:通知瀏覽器,服務端未能提供本次服務的緣由,是被調用servlet在運行時出現了異常

默認歡迎資源文件

瀏覽器向服務器發送了默認請求,沒有指定索要的文件的時候
http://localhose/555
手動在web.xml配置
    <welcome-file-list>
        <welcome-file>one.html</welcome-file>
    </welcome-file-list>
當web.xml文件中沒有的時候
    Tomcat回到本身的config文件下有個web.xml文件,裏面寫的有默認的文件名

---

多個servlet來處理一次請求方案

1.重定向方案

在第一個servlet工做完畢後,將第二個servlet的地址發給瀏覽器,瀏覽器自動請求第二個servlet
response.sendRedirect(第二個servlet的地址)
發生位置:客戶端瀏覽器上,請求屢次,地址欄內容會發生改變,請求方式必定是get,可訪問內網和外網的資源

適用場景:添加,刪除,更新後調用查詢功能

2.請求轉發方案

第一個servlet工做完畢後,代替瀏覽器向Tomcat申請調用第二個servlet
1.建立一個資源申請報告對象
    RequestDispatcher report=request.getRequestDispatcher("第二個servlet的地址")
2.將申請報告推送給Tomcat,並將第一個servlet的response和request一併發送
    report.forward(request,response)
 
 請求轉發時爲何將第一個Servelt中request和response交給Tomcat：
    Tomcat在調用第二個Serelt時須要爲其提供運行時須要【request】和【response】
    可是，本次請求是由第一個Servelt來發送的，沒有對應的【請求協議包】
    所以致使Tomcat在接受到請求後，不會建立【request】和【response】,
    爲了解決這個問題，須要將第一個Servlet的request和response交給第二個Servlet來使用。
發生位置在服務端,瀏覽器只向服務器發送了一次請求,只能訪問內部的資源,請求方式始終和第一個servlet保持一致
適用於查詢servlet調用jsp