JSP／Servlet開發——第二章 JSP數據交互（一）

時間 2019-12-05

標籤 jsp servlet 開發第二數據交互欄目 JSP 简体版

原文原文鏈接

一、 JSP內置對象：JSP內置對象是 Web 容器建立的一組對象；css

　　●JSP經常使用的內置對象：out、request、application、session、response等；html

　　●內置對象不須要實例化的緣由：java

　　　　 ★由Web容器加載的一組Servlet API的實例，這些實例由 JSP 規範進行了默認的初始化操做，能夠直接在JSP中使用，特別要注意的是JSP內置對象名稱均是JSP的保留字，不得看成自定義變名使用；web

二、JSP的內置對象out：數據庫

●out對象是JspWriter類的實例；數組
●out 內置對象是在 JSP 開發過程當中使用最爲頻繁的對象，out 對用於向瀏覽器輸出數據，其經常使用的方法是 print( ) , 該方法用於在頁面中顯示字符串信息。瀏覽器 eg：在頁面上顯示「Hello JSP'：緩存 <%安全 out.print(「Hello JSP」);服務器 %>
●out經常使用的方法：
方法名稱	說明
void print(Object c)	向客戶端打印數據（將各類類型的數據轉換成字符串）
void println(Object c)	向客戶端打印數據（將各類類型的數據轉換成字符串）並換行（在html源代碼裏表現爲回車，但在頁面渲染爲空格）
void write(charset)	向客戶端打印數據（只能打印：字符、字符數組、字符串）

三、 JSP 內置對象 request：

　　●request對象是最經常使用的 JSP 內置對象之一 , 其中包含了有關瀏覽器請求的信息；

　　　　工做原理：

●request對象經常使用方法：

方法名稱	說明
String getParameter(String name)	根據頁面表單組件名稱獲取頁面提交數據
String[ ] getParameterValues(String name)	獲取一組相同名稱名命的表單組件提交的數據（表單組件對應多個值時的請求數據）
void setCharacterEncoding(String charset)	指定每一個請求的編碼
RequestDispatcher getRequestDispatcher(String path)	返回一個javax.servlet.RequestDispatcher對象，該對象的forward( )方法用於轉發請求

eg：編碼實現學員的註冊功能：

註冊reginput . jsp頁面的jsp：

<body>

         <div align="center">請輸入註冊信息

                  <form name="form1" method="post" action="reginfo.jsp">

              <table  border="0" align="center">

                                <tr>

                            <td>用戶名：</td>

                            <td><input type="text" name="name"></td>

                              </tr>

                                   <tr>

                                  <td height="19">密碼：</td>

                                  <td height="19"><input type="password" name="pwd"></td>

                                   </tr>

                                   <tr>

                            <td>信息來源：</td>

                            <td>

                                           <input type="checkbox" name="channel" value="報刊">報刊

                                           <input type="checkbox" name="channel" value="網絡">網絡<br/>

                                           <input type="checkbox" name="channel" value="朋友推薦">朋友推薦

                                           <input type="checkbox" name="channel" value="電視">電視

                                      </td>

                              </tr>

                              <!-- 如下是提交、取消按鈕 -->

                              <tr >

                            <td colspan="2" align="center" >

                                            <input type="submit" name="Submit" value="提交">

                                            <input type="reset" name="Reset" value="取消">

                            </td>

                              </tr>

              </table>

                </form>

         </div>

      </body>

eg：提交reginfo . isp頁面的jsp：

<body>

       <%

           request.setCharacterEncoding("UTF-8");

           String name = request.getParameter("name");

           String pwd = request.getParameter("pwd");

           String[] channels = request.getParameterValues("channel");

       %>

       <div align="center">你輸入的註冊信息

              <table border="0" align="center">

                  <tr>

                      <td width="80" height="20">用戶名:</td>

                      <td><%=name%></td>

                  </tr>

                  <tr>

                      <td height="20">密碼:</td>

                      <td><%=pwd%></td>

                  </tr>

                  <tr>

                      <td height="20">信息來源:</td>

                      <td >

                      <%

                          if (channels != null) {

                              for (String channel: channels) {

                                  out.print(channel+"&nbsp;");

                              }

                          }

                      %>

                      </td>

                  </tr>

              </table>

       </div>

       </body>

代碼分析：

★request的getParameter()方法是最爲經常使用的，使用此方法能夠得到請求中所提交的參數值，

　　例如，註冊頁面 (reginput . jsp) 經過 HTML 表單爲註冊提交頁面 (reginfo . isp) 提交了兩個參數，名稱分別爲name 和 pwd,經過調用 request .getParameter( "name' ) 和 request.getParameter 就能夠獲取這兩個參數的值；

★在註冊頁面中，出現了多個複選框複選框的名稱都是 channel, 在註冊提交頁面中使用getParameterValues(「channel」) 方法就能夠獲取一個字符串數組，該數組中存儲的是全部選中的複選框對應的值。若是沒有選擇任何選項，請求中不包含名爲channel的參數. 則該方法返回null；

★request 對象的 setCharacterEncodlrig ( ) 方法用於設置字符集，能夠用來解決中文亂碼問題，經常使用字符集編碼有 ASCll 、ISO-8859-1 、GB23十二、GBK、Unicode、UTF-8等，java在其內部使用 Unicode字符集來表示字符，這樣就存在 Unicode 字符集和本地字符集進行換的過程，左Web 應用中, 一般都包括了瀏覽器、Web 服務器、Web 應用程序和數據庫等部分，每一部分都有可能使用不一樣的字符集，從而致使字符數據在各類不一樣的字符集之間轉換時，出現亂碼的問題；

　　　　　　●亂碼可能的緣由：

　　　　　　　　1、JSP頁面自己的編碼：

　　　　　　　　　　 ★pageEncoding：頁面自己的編碼；

　　　　　　　　　　 ★瀏覽器渲染頁面時採用的編碼格式；

　　　　　　　　　　★一旦制定了一種編碼格式，另外一種編碼格式若是不進行指定的話，默認都採用已經指定的編碼格式；

　　　　　　　　2、瀏覽器渲染頁面採用的編碼

　　　　　　　　三、服務器保存數據採用的編碼（request）

●對於中文亂碼問題，根據產生的緣由，主要有如下幾種解決方案：

▲以POST 方法提交的表單數據中有中文字符時：

　　◆Tomcat對請求數據默認採用ISO-8859-1字符集進行解碼，request 對象的 getParameter方法獲得的字符串是以 ISO-8859-1 轉換而來的，因此在獲取請求參數值以前，調用setCharacterEncoding ( "UTF-8「 )方法，將請求的解碼方式設定爲 UTF-8。注意：頁面和瀏覽器發請求也應一導致用 UTF-8 編碼，經過 JSP 頁面設置 page 指令的 contentType屬性，指定頁面內容的編碼格式以下：

　　　　 <% page contentType=」text/html;charset=UTF-8」%>

　　　　　　☆注：cententType和pageEncoding的區別：cententType定義響應的資源類型，也能夠包含JSP頁面和響應內容的字符集;pageEncoding 指定JSP文件的字符集及默認的 contentType字符集；

▲以 GET方法提交的表單數據中有中文字符時：

　　◆當採用GET方式提交表單時，提交的數據做爲查詢字符串被附加到URL的末端發送到服務器，對於這部分數據，在服務器調用setCharacterEnCoding ( ) 方法是不起做用的，咱們須要獲得請求參數值後，進行編碼轉換，在上面的示例中，將表單的提交方式改成 method= 'get'，則在註冊提交頁reginfo中將得到用戶名的代碼修改：

　　 String name = request.getParameter("name");

　　　　name=new String(name.getBytes(「ISO-8859-1」),」UTF-8」)；

　　　　　　☆其中，nama.getBytes(「ISO-8859-1」)是按照「ISO-8859-1」字符集編碼把 name 字符串轉換爲btye數組，再經過new String()方法,使用指定的」UTF-8」字符集把 byte 數組構造爲一個新的String；

▲在 Tomcat 中設置字符集：

　　◆當表單採用 GET 方法提交時，雖然能夠經過構造一個新的String 的方式解決中文亂碼問題，可是當獲取多個參數值時.每一個參數都進行從新編碼，操做比較煩瑣，效率也不高。這時能夠經過Tomcat中設置字符集的方式解決，配置方式以下：找到 Tomcat 目錄結構\conf\server . xml 文件，<Connector>元素中添加 URIEncoding 屬性,將它的值設置爲「UTF-8 「；

　　<Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" URIEncoding =「UTF-8」/>

　　　　　☆在 Tomcat 中設置了字符集編碼，對於瀏覽器以 GET 方式提交的數據則無須在 JSP頁面中再進行從新編碼處理 (注意瀏覽器需以 UTF-8,編碼發送 URL);

四、JSP內置對象response：

　　●與request對象相對應的是response對象，response對象用於響應客戶請求並向客戶端輸出信息；

　　●工做原理：

　　●response對象經常使用的方法：

addCookie(Cookie cookie)	向客戶端添加Cookie；
setContentType(String type)	設置HTTP響應的contentType類型
setCharacterEncoding(String charset)	設置響應所採用字符編碼類型
sendRedirect(String location)	將請求從新定位到一個新的URL上

　　　　　　　　 ◆最經常使用的方法：sendRedirect(String location)：客戶端將從新發送請求到指定的URL；

5、轉發與重定向：

●轉發：從程序運行的角度理解. 即當客戶端發送一個請求到服務器後， Web 服務器在容器內部完成求跳轉，而後將最終的結果發送給瀏覽器，整個過程都是在容器內部完成的，而對應到客戶端，不管服務器內部如何處理，做爲瀏覽器都只是提交了一個請求，於是客戶端的 URL 地址不會發生改變；

☆轉發的實現很簡單，使用 request 的 getRequestDispatcher ( ) 方法獲得 RequestDispatcher 對象,此對象用於封裝一個由路徑所標識的服務器資源，而後用這個對象調用 forward )方法，將請求傳遞服務器上另外的 JSP 頁面或者 HTML 文件；

☆轉發能夠在多個頁面交互過程當中實現請求數據的共享；

●重定向：當用戶登陸成功後. 使用的是 response 對象的 sendRedirect ( ) 方法。那麼該方法行的結果是客戶端從新向服務器請求一個地址連接，因爲是發送新的請求 , 於是上次請求中的數將隨之丟失這種行爲稱爲重定向。因爲服務器從新定向了URL，於是在客戶端瀏覽器中顯示的新的 URL 地址, 因此重定向能夠理解爲瀏覽器至少提交了兩次請求

●轉發和重定向有什麼區別：轉發和重定向都可以實現頁面的跳轉，不一樣之處表如今如下幾方面：

　　◆轉發過程：Web 服務器內部將一個 request 請求的處理權交給另一個資源，屬於同一個訪問請求和響應過程，因此 request對象的信息不會丟失，

　　　　★轉發是在服務器端發揮做用，經過 RequestDispatcher 對象的forward( ) 方法將交信息在多個頁面間進行傳遞；

　　　　★轉發是在服務器內部控制權的轉移，客戶端瀏覽器的地址欄不會顯示出轉向的地址。

　　◆重定向過程：Web 服務器向瀏覽器返回一個響應，瀏覽器接受此響應後再發一個新的 http請求到服務器，這屬於兩次不一樣的請求，則上一次請求的 request信息將丟失；

　　　　★重定向是在客戶端發揮做用，經過請求新的地址實現頁面轉向。其經過瀏覽器從新請求地址，在地址欄中能夠顯示轉向後的地址。

●若是須要在重定向的狀況下將簡單數據（值類型、字符串）傳遞到目標頁面；也以使用查詢字符串（Query String）實現：

　　response.sendRedirect(「welcome.jsp?username=」+name」);

　　查詢字符串以名值對方式存儲數據，經過「？」鏈接在URL的後面，多個名值對可使用「&」進行分隔；

●查詢字符串的應用：

eg：選擇頁面

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8" %>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

    <head>

        <title>選擇喜歡的顏色</title>

    </head>

    <body>

         請從如下7種顏色中,選擇你最喜歡的顏色<br/>

        <a href="color.jsp?color=赤色">赤色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=橙色">橙色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=黃色">黃色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=綠色">綠色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=青色">青色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=藍色">藍色</a>&nbsp;&nbsp;

        <a href="color.jsp?color=紫色">紫色</a>

    </body>

</html>

eg：展現頁面

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

    <head>

        <title>我喜歡的顏色</title>

    </head>

    <body>

    <%  

             //已在Tomcat中設置字符集爲「UTF-8」

        String color = request.getParameter("color");

    %>

        你最喜歡的顏色是:<%=color%>

    </body>

</html>

分析：經過上面的代碼, 能夠發現數據傳遞成功了：代碼中的a標籤部分，在跳轉頁面的後面都有一個 '?'. 以及一個參數名 'color',每個參數的值就是所選擇的顏色。而在結果頁面中使用 request 對象的 getParameter ) 方法 , 就可取到參數 'color" 的值,達到了數據的傳遞效果；

注：使用超連接進行數據傳遞時: 採用的是 GET 方式提交請求，若是在傳遞裁據中存中文，使用 request 對象直接獲取時，容易產生亂碼

問題。所以，須要對數據進行從新編碼。

　　▲可使用 String 對象的方法實現數椐從新編碼；

　　　　★語法：new String ( 須要編碼的數據.getBytes(「 ISO-8859-1「 )，「 UTF-8「 )；

　　▲也能夠經過設置 Tomcat 字符集實現：

　　　　★當傳遞多個數據時，可用「&」鏈接。

　　　　　　eg：<a href=「 color.jsp?color=赤色&id=1>赤色</a>, 在荻取數據時，依然能夠經過參數名「id」讀取參數值「1」;

六、JSP 內置對象 session：

　　●會話：

session：原義是指善始善終的一系列動做；

　　eg：打電話時，甲方拿起電話撥通乙方電話這一系列的過程就能夠稱爲一個會話，電話掛斷時會話結束；

★對Web開發來講，一個會話就是在一段時間內一個用戶與 Web 服務器的一連串相關的交互過程，它可包含瀏覽器與服務器之間的屢次請求，響應過程：在一次會話中，用戶可能會屢次請求訪問一網頁，也有可能請求訪問同一個服務器的其餘資源；

▲下圖描述了瀏覽器與服務器的一個會話過程：

★會話機制是一種服務器端的機制，當用戶向服務器發出第一次請求時，服務器會爲該用戶建立惟一的會話，會話將一直延續到用戶訪問結束；

★當服務器接收到客戶端的請求時，服務器首先會判斷是否已經建立了與該客戶端對應的會話，若是已經建立就將該請求與此會話相關聯，若是沒有包建，則會建立一個新會話，此客戶端以後發送的請求將關聯到該會話；

★而服務器判斷是否建立了相關會話，是經過一個惟一的標識 sessionid來實現的。若是在客戶端請求中包含了一個sessionid，則說明在此前已經爲客戶端建立了會話，服務器就會根據這個 sessionid將對應的會話對象讀取出來；不然就會建立一個新的會話對象並生成一個 sessionid，並將 sessionid在本次晌應的過程返回客戶端保存；

★sessionid會返回客戶端，那麼在客戶端 sessionid 會保存在什麼位置？

　　回答：在客戶端保存用戶信息使用的是 cookie, 所以保存 sessionid 的方式也是使cookoe來實現的，在客戶端的 cookie 中，保存 sessionid 的名稱是 JSESSIONID， segsionid 的值是由一串複雜字符串組成的；

　　　　eg：JSESSIONID=2A 11D30C7B32329D7C8BF16DC598C509 , 其中等號後面的字符串就是分配的 scssionid 對應的值；

七、 session對象：

　　●session 對象做爲JSP提供的內置對象之一 , session 對象容許用戶訪問會話的相關信息，以及綁定數據到話（在服務器端使用相似於哈希表的結構來保存信息)。綁定到會話的數據能夠在屢次請求之間持續有效；

　　　　◆ session對象的經常使用方法：

方法名稱	說明
String getId()	獲取sessionid
void setMaxInactiveInterval(int interval)	設定session的非活動時間
int getMaxInactiveInterval()	獲取session的有效非活動時間(以秒爲單位)
void invalidate()	設置session對象失效
void setAttribute(String key, Object value)	以key/value的形式將對象保存對到session中
Object getAttribute(String key)	經過key獲取session中保存的對象值
void removeAttribute(String key)	從session中刪除指定名稱(key)所對應的對象

　　　　●session與窗口的關係：

　　　　　　　　◆每一個session對象都與一個瀏覽器窗口對應，從新開啓一個瀏覽器窗口，能夠從新建立一個session對象（不一樣版本瀏覽器可能有所差異）

　　　　　　　　◆經過超連接打開的新窗口，新窗口的session與其父窗口的session相同

八、使用 session 對象實現權限控制：

　　　　eg：用戶經過登陸頁面登網站，若是該用戶是已註冊用戶 . 系統會保存該用戶的登陸信息. 並讓用戶進入其欲訪問的頁面；

　　　　　　 用戶直接訪問網站的某個頁面. 系統會查詢是否保存有該用戶的登陸信息，若是有則顯示該頁面的內容；若是沒有，則轉入登陸頁面. 要求用戶登陸網站

　　●這裏要實現的權限訪問控制是基於 session 對象來完成的。

　　　　eg：使用 session 爲新聞發佈系增長訪問控制，要求新聞發佈系統中全部針對新聞的操做，如發佈新聞、修改新聞、發佈新聞標題、修改新聞標題，都只能由管理員才能完成。普通用戶沒有權限進行訪問，訪問控制流程如圖：

　　　　★根據新聞發佈系統的訪問控制流程，實現訪問控制的流程以下：

1、在登錄頁面輸入用戶名和密碼；

2、在登錄處理頁面進行登錄驗證；

3、在會話中，保存用戶信息，若是用戶登陸成功，則跳轉到管理員頁面；

4、在管理員頁面讀取會話中的用戶信息，並進行校驗；

5、驗證失敗，返回登錄頁面；

eg：登錄處理頁面jsp的代碼：

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

<title>登陸處理頁面</title>

</head>

<body>

    <%

        request.setCharacterEncoding("UTF-8");

        //獲取請求數據,並去除空格

        String name = request.getParameter("userName").trim();

        String pwd = request.getParameter("pwd").trim();

        boolean valid = false;  //判斷用戶驗證是否成功

        if("admin".equals(name)&&"admin".equals(pwd)){

             valid = true;

             //設置用戶登陸信息

             session.setAttribute("login", name);

             //設置session過時時間

             session.setMaxInactiveInterval(10*60);

        }

        if (valid) {

            request.getRequestDispatcher("admin.jsp")

                .forward(request,response);

        } else {

                response.sendRedirect("index.jsp");

        }

    %>

    </body>

</html>

分析：接下來在管理員操做頁面加入登陸驗證。此時要完成的任務是，從 session 中提取用戶的信息，若是用戶信息存在，則能夠進行操做；若是用戶信息不存在 . 則跳轉到登陸頁面。這一步實現了問的控制；

eg：在管理員界面加入以下代碼：

<%@ page language="java" import="java.util.*" pageEncoding="UTF-8"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

  <head>  

    <title>管理員</title>

  </head>

 

  <body>

    <%

           String login = (String) session.getAttribute("login");

           if (login == null){

               response.sendRedirect("index.jsp");

               return;

           }

    %>

    您好，歡迎您！

  </body>

</html>

分析：在登陸處理頁面中，已經實現了對用戶的身份驗證，爲何在此處還要再進驗證。緣由很簡單.，若是用戶不經過登陸方式，而是直接在瀏覽器地址欄中輸入管理員頁面的地址這樣將會直接繞過登陸限制而訪問成功。因此須要在管理員操做界面再添加控制語句，以免此狀況的發生。

◆至此：此示例的訪問控制已經基本實現了；

　　▲驗證訪問控制效果的具體步驟以下：

　　　　1、直接在瀏覽器地址欄中輸入URL，訪問管理員操做頁面；

　　　　2、經過登陸頁面進入管理員操做頁面；

　　　　3、從新開啓一個瀏覽器窗口，直接訪問管理員操做頁面；

◆按照以上步驟運行，觀察每一個步驟會發生什麼樣的結果 , 並思考爲何會產生這樣的結果。下面對此進行分析:

　　☉如釆直接在瀏覽器地址欄中輸入管理員操做頁面的 URL, 系統會跳入登陸頁面 , 提示用戶進行登陸。這個緣由很簡單，由於咱們在管理員操做頁面中加入了訪問控制，只有正確登錄後，進入管理員操做界面，會話中才會存儲用戶登陸成功的狀態信息，才能夠正常訪問管理員操做頁面；

　　☉若是從新開啓一個瀏覽器窗口，直接訪問管理員操做頁面，無論在其餘窗口中是否登錄，所進入的確定是登陸頁面，這是咱們常常遇到的問題，即 session 與瀏器窗口的關係；

　　☉每一個 session 對象都與瀏覽器一一對應，也就是說，從新開啓一個瀏覽器窗口，至關於新建立一個 scssion 對象。可是須要注意的是，因爲瀏覽器或版本不一樣，即便從新開啓個瀏覽器窗口，也會認爲是同一個 session 對象，也就是所謂的出現會話共享問題；

　　　　☆以 IE8爲例，能夠在瀏覽器上執行 "文件」 — "新建會話’ 命令新建一個會話窗口。

　　　　☆另外，提供兩種取消瀏覽器窗口共享 session 的辦法：

　　　　　　　　1、修改 IE8 的快捷方式：右擊 IE8快捷方式圖標，在彈出的快捷菜單中選擇 ’屬性" —「目標’ 選項，末尾添加「- nomerge"，修改後如"C:\Program Files\Itemet Explorer\iexplorc.exe" -nomerge;

　　　　　　　　2、使用命令參數 "iexpldre.exe -nomerge' 打開IE

　　☉如今就可解釋爲何在登陸成功後，從新開啓一個瀏覽器窗口直接訪問管理員操做頁便可進入登陸頁面了，在其餘瀏覽器窗口中保存的登陸信息與新的瀏覽器窗口徹底無關，因此係統會斷定還沒有登陸，跳轉進入登陸頁面；

九、會話的失效：

●會話也是有時效的，使會話失效的方式有兩種：一種是會話超時；另外一種是手動調用方法設置失效；

●會話超時是指兩次請求的時間間隔超過了服務器容許的最大時間間隔；

●會話的超時間隔可經過三種方法設置：

　　◆經過 session 對象的setMaxInactiveInterval( )方法設置，單位是秒；

      <%

　　　　　　session.setAttribute("login","admin");

　　　　　　//參數 600 的單位是秒， 表示在 10 分鐘後 session對象失效；

　　　　　　session.setMaxInactiveInterval(600);

　　　　　　response.sendRedirect("admin.jsp");

　　　　　%>

　　◆在項目的web.xml中設置，單位是分鐘，設置爲0或負數，表示永不超時；　　

        <session-config>

       　　　　 <session-timeout>10</session-timeout>

　　　　　</session-config>

　　◆在應用服務器中設置，在 Tomcat目錄下的/conf/web.xml文件中找到<sesston-config>元素, 其中<sesston-config>元素中的 30 就是默認的時間，單位是分鐘，能夠修改其值；

　　◆項目A：web.xml，Tomcat：web.xml；

　　★Tomcat：web.xml：全局配置，項目A：web.xml：針對項目的配置；若是有重複的選項，調用項目A的web.xml；

　　 ★項目調用的是：項目A：web.xml + Tomcat：web.xml；

　　★修改Tomcat：web.xml對全部的項目都有影響；

　　☉動調用方法設置失效是經過調用 session 對象的 invalidate（）方法實現的，主要應用於用戶註銷的場合，但若是隻想清空會話中綁定的某個數據對象，則能夠調用 session . removeAttribute (String key)方法，將指定的對象從會話中清除，而會話仍然有效；

十、 include指令：

　　●文件引用指令include，將一些能夠重用的內客寫入一個單獨的文件，而後經過 include 指令引用該文件，從而緩解代碼的冗餘問題, 而且修改時也更方便；

　　●include 指令的基本語法：以<%@ 開始，以 %> 結束。

　　　　 語法：<%@ include file="應用文件路徑 " %>

　　● Include 指令表示，在 JSP 編譯時插入一個包含文本或代碼的文件，這個包含的過程是靜態的，包含的文件能夠是 JSP 頁面、HTML 網頁、文本文件等。

　　●include 指令只有一個 fi1e 屬性 , 表示被包含的文件路徑；

十一、狀態碼：

狀態碼	含義
100	客戶端應當繼續發送請求。這個臨時響應是用來通知客戶端它的部分請求已經被服務器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者若是請求已經完成，忽略這個響應。服務器必須在請求完成後向客戶端發送一個最終響應。
101	服務器已經理解了客戶端的請求，並將經過Upgrade消息頭通知客戶端採用不一樣的協議來完成這個請求。在發送完這個響應最後的空行後，服務器將會切換到在Upgrade消息頭中定義的那些協議。　　只有在切換新的協議更有好處的時候才應該採起相似措施。例如，切換到新的HTTP版本比舊版本更有優點，或者切換到一個實時且同步的協議以傳送利用此類特性的資源。
102	由WebDAV（RFC 2518）擴展的狀態碼，表明處理將被繼續執行。
200	請求已成功，請求所但願的響應頭或數據體將隨此響應返回。
201	請求已經被實現，並且有一個新的資源已經依據請求的須要而創建，且其URI已經隨Location頭信息返回。假如須要的資源沒法及時創建的話，應當返回'202 Accepted'。
202	服務器已接受請求，但還沒有處理。正如它可能被拒絕同樣，最終該請求可能會也可能不會被執行。在異步操做的場合下，沒有比發送這個狀態碼更方便的作法了。　　返回202狀態碼的響應的目的是容許服務器接受其餘過程的請求（例如某個天天只執行一次的基於批處理的操做），而沒必要讓客戶端一直保持與服務器的鏈接直到批處理操做所有完成。在接受請求處理並返回202狀態碼的響應應當在返回的實體中包含一些指示處理當前狀態的信息，以及指向處理狀態監視器或狀態預測的指針，以便用戶可以估計操做是否已經完成。
203	服務器已成功處理了請求，但返回的實體頭部元信息不是在原始服務器上有效的肯定集合，而是來自本地或者第三方的拷貝。當前的信息多是原始版本的子集或者超集。例如，包含資源的元數據可能致使原始服務器知道元信息的超級。使用此狀態碼不是必須的，並且只有在響應不使用此狀態碼便會返回200 OK的狀況下才是合適的。
204	服務器成功處理了請求，但不須要返回任何實體內容，而且但願返回更新了的元信息。響應可能經過實體頭部的形式，返回新的或更新後的元信息。若是存在這些頭部信息，則應當與所請求的變量相呼應。　　若是客戶端是瀏覽器的話，那麼用戶瀏覽器應保留髮送了該請求的頁面，而不產生任何文檔視圖上的變化，即便按照規範新的或更新後的元信息應當被應用到用戶瀏覽器活動視圖中的文檔。　　因爲204響應被禁止包含任何消息體，所以它始終以消息頭後的第一個空行結尾。
205	服務器成功處理了請求，且沒有返回任何內容。可是與204響應不一樣，返回此狀態碼的響應要求請求者重置文檔視圖。該響應主要是被用於接受用戶輸入後，當即重置表單，以便用戶可以輕鬆地開始另外一次輸入。　　與204響應同樣，該響應也被禁止包含任何消息體，且以消息頭後的第一個空行結束。
206	服務器已經成功處理了部分GET請求。相似於FlashGet或者迅雷這類的HTTP下載工具都是使用此類響應實現斷點續傳或者將一個大文檔分解爲多個下載段同時下載。　　該請求必須包含Range頭信息來指示客戶端但願獲得的內容範圍，而且可能包含If-Range來做爲請求條件。　　響應必須包含以下的頭部域：　　Content-Range用以指示本次響應中返回的內容的範圍；若是是Content-Type爲multipart/byteranges的多段下載，則每一multipart段中都應包含Content-Range域用以指示本段的內容範圍。假如響應中包含Content-Length，那麼它的數值必須匹配它返回的內容範圍的真實字節數。　　Date　　ETag和/或Content-Location，假如一樣的請求本應該返回200響應。　　Expires,Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。　　假如本響應請求使用了If-Range強緩存驗證，那麼本次響應不該該包含其餘實體頭；假如本響應的請求使用了If-Range弱緩存驗證，那麼本次響應禁止包含其餘實體頭；這避免了緩存的實體內容和更新了的實體頭信息之間的不一致。不然，本響應就應當包含全部本應該返回200響應中應當返回的全部實體頭部域。　　假如ETag或Last-Modified頭部不能精確匹配的話，則客戶端緩存應禁止將206響應返回的內容與以前任何緩存過的內容組合在一塊兒。　　任何不支持Range以及Content-Range頭的緩存都禁止緩存206響應返回的內容。
207	由WebDAV(RFC 2518)擴展的狀態碼，表明以後的消息體將是一個XML消息，而且可能依照以前子請求數量的不一樣，包含一系列獨立的響應代碼。
300	被請求的資源有一系列可供選擇的回饋信息，每一個都有本身特定的地址和瀏覽器驅動的商議信息。用戶或瀏覽器可以自行選擇一個首選的地址進行重定向。　　除非這是一個HEAD請求，不然該響應應當包括一個資源特性及地址的列表的實體，以便用戶或瀏覽器從中選擇最合適的重定向地址。這個實體的格式由Content-Type定義的格式所決定。瀏覽器可能根據響應的格式以及瀏覽器自身能力，自動做出最合適的選擇。固然，RFC 2616規範並無規定這樣的自動選擇該如何進行。　　若是服務器自己已經有了首選的回饋選擇，那麼在Location中應當指明這個回饋的URI；瀏覽器可能會將這個Location值做爲自動重定向的地址。此外，除非額外指定，不然這個響應也是可緩存的。
301	被請求的資源已永久移動到新位置，而且未來任何對此資源的引用都應該使用本響應返回的若干個URI之一。若是可能，擁有連接編輯功能的客戶端應當自動把請求的地址修改成從服務器反饋回來的地址。除非額外指定，不然這個響應也是可緩存的。　　新的永久性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。　　若是這不是一個GET或者HEAD請求，所以瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。　　注意：對於某些使用HTTP/1.0協議的瀏覽器，當它們發送的POST請求獲得了一個301響應的話，接下來的重定向請求將會變成GET方式。
302	請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。　　新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。　　若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。　　注意：雖然RFC 1945和RFC 2068規範不容許客戶端在重定向時改變請求的方法，可是不少現存的瀏覽器將302響應視做爲303響應，而且使用GET方式訪問在Location中規定的URI，而無視原先請求的方法。狀態碼303和307被添加了進來，用以明確服務器期待客戶端進行何種反應。
303	對應當前請求的響應能夠在另外一個URI上被找到，並且客戶端應當採用GET的方式訪問那個資源。這個方法的存在主要是爲了容許由腳本激活的POST請求輸出重定向到一個新的資源。這個新的URI不是原始資源的替代引用。同時，303響應禁止被緩存。固然，第二個請求（重定向）可能被緩存。　　新的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。　　注意：許多HTTP/1.1版之前的瀏覽器不能正確理解303狀態。若是須要考慮與這些瀏覽器之間的互動，302狀態碼應該能夠勝任，由於大多數的瀏覽器處理302響應時的方式偏偏就是上述規範要求客戶端處理303響應時應當作的。
304	若是客戶端發送了一個帶條件的GET請求且該請求已被容許，而文檔的內容（自上次訪問以來或者根據請求的條件）並無改變，則服務器應當返回這個狀態碼。304響應禁止包含消息體，所以始終以消息頭後的第一個空行結尾。　　該響應必須包含如下的頭信息：　　Date，除非這個服務器沒有時鐘。假如沒有時鐘的服務器也遵照這些規則，那麼代理服務器以及客戶端能夠自行將Date字段添加到接收到的響應頭中去（正如RFC 2068中規定的同樣），緩存機制將會正常工做。　　ETag和/或Content-Location，假如一樣的請求本應返回200響應。　　Expires,Cache-Control，和/或Vary，假如其值可能與以前相同變量的其餘響應對應的值不一樣的話。　　假如本響應請求使用了強緩存驗證，那麼本次響應不該該包含其餘實體頭；不然（例如，某個帶條件的GET請求使用了弱緩存驗證），本次響應禁止包含其餘實體頭；這避免了緩存了的實體內容和更新了的實體頭信息之間的不一致。　　假如某個304響應指明瞭當前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，而且重複發送不包含限制條件的請求。　　假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映全部在響應中被更新的字段的值。
305	被請求的資源必須經過指定的代理才能被訪問。Location域中將給出指定的代理所在的URI信息，接收者須要重複發送一個單獨的請求，經過這個代理才能訪問相應資源。只有原始服務器才能創建305響應。　　注意：RFC 2068中沒有明確305響應是爲了重定向一個單獨的請求，並且只能被原始服務器創建。忽視這些限制可能致使嚴重的安全後果。
306	在最新版的規範中，306狀態碼已經再也不被使用。
307	請求的資源如今臨時從不一樣的URI響應請求。因爲這樣的重定向是臨時的，客戶端應當繼續向原有地址發送之後的請求。只有在Cache-Control或Expires中進行了指定的狀況下，這個響應纔是可緩存的。　　新的臨時性的URI應當在響應的Location域中返回。除非這是一個HEAD請求，不然響應的實體中應當包含指向新的URI的超連接及簡短說明。由於部分瀏覽器不能識別307響應，所以須要添加上述必要信息以便用戶可以理解並向新的URI發出訪問請求。　　若是這不是一個GET或者HEAD請求，那麼瀏覽器禁止自動進行重定向，除非獲得用戶的確認，由於請求的條件可能所以發生變化。
400	一、語義有誤，當前請求沒法被服務器理解。除非進行修改，不然客戶端不該該重複提交這個請求。　　二、請求參數有誤。
401	當前請求須要用戶驗證。該響應必須包含一個適用於被請求資源的WWW-Authenticate信息頭用以詢問用戶信息。客戶端能夠重複提交一個包含恰當的Authorization頭信息的請求。若是當前請求已經包含了Authorization證書，那麼401響應表明着服務器驗證已經拒絕了那些證書。若是401響應包含了與前一個響應相同的身份驗證詢問，且瀏覽器已經至少嘗試了一次驗證，那麼瀏覽器應當向用戶展現響應中包含的實體信息，由於這個實體信息中可能包含了相關診斷信息。參見RFC 2617。
402	該狀態碼是爲了未來可能的需求而預留的。
403	服務器已經理解請求，可是拒絕執行它。與401響應不一樣的是，身份驗證並不能提供任何幫助，並且這個請求也不該該被重複提交。若是這不是一個HEAD請求，並且服務器但願可以講清楚爲什麼請求不能被執行，那麼就應該在實體內描述拒絕的緣由。固然服務器也能夠返回一個404響應，假如它不但願讓客戶端得到任何信息。
404	請求失敗，請求所但願獲得的資源未被在服務器上發現。沒有信息可以告訴用戶這個情況究竟是暫時的仍是永久的。假如服務器知道狀況的話，應當使用410狀態碼來告知舊資源由於某些內部的配置機制問題，已經永久的不可用，並且沒有任何能夠跳轉的地址。404這個狀態碼被普遍應用於當服務器不想揭示到底爲什麼請求被拒絕或者沒有其餘適合的響應可用的狀況下。
405	請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow頭信息用以表示出當前資源可以接受的請求方法的列表。　　鑑於PUT，DELETE方法會對服務器上的資源進行寫操做，於是絕大部分的網頁服務器都不支持或者在默認配置下不容許上述請求方法，對於此類請求均會返回405錯誤。
406	請求的資源的內容特性沒法知足請求頭中的條件，於是沒法生成響應實體。　　除非這是一個HEAD請求，不然該響應就應當返回一個包含可讓用戶或者瀏覽器從中選擇最合適的實體特性以及地址列表的實體。實體的格式由Content-Type頭中定義的媒體類型決定。瀏覽器能夠根據格式及自身能力自行做出最佳選擇。可是，規範中並無定義任何做出此類自動選擇的標準。
407	與401響應相似，只不過客戶端必須在代理服務器上進行身份驗證。代理服務器必須返回一個Proxy-Authenticate用以進行身份詢問。客戶端能夠返回一個Proxy-Authorization信息頭用以驗證。參見RFC 2617。
408	請求超時。客戶端沒有在服務器預備等待的時間內完成一個請求的發送。客戶端能夠隨時再次提交這一請求而無需進行任何更改。
409	因爲和被請求的資源的當前狀態之間存在衝突，請求沒法完成。這個代碼只容許用在這樣的狀況下才能被使用：用戶被認爲可以解決衝突，而且會從新提交新的請求。該響應應當包含足夠的信息以便用戶發現衝突的源頭。　　衝突一般發生於對PUT請求的處理中。例如，在採用版本檢查的環境下，某次PUT提交的對特定資源的修改請求所附帶的版本信息與以前的某個（第三方）請求向衝突，那麼此時服務器就應該返回一個409錯誤，告知用戶請求沒法完成。此時，響應實體中極可能會包含兩個衝突版本之間的差別比較，以便用戶從新提交歸併之後的新版本。
410	被請求的資源在服務器上已經再也不可用，並且沒有任何已知的轉發地址。這樣的情況應當被認爲是永久性的。若是可能，擁有連接編輯功能的客戶端應當在得到用戶許可後刪除全部指向這個地址的引用。若是服務器不知道或者沒法肯定這個情況是不是永久的，那麼就應該使用404狀態碼。除非額外說明，不然這個響應是可緩存的。　　410響應的目的主要是幫助網站管理員維護網站，通知用戶該資源已經再也不可用，而且服務器擁有者但願全部指向這個資源的遠端鏈接也被刪除。這類事件在限時、增值服務中很廣泛。一樣，410響應也被用於通知客戶端在當前服務器站點上，本來屬於某個我的的資源已經再也不可用。固然，是否須要把全部永久不可用的資源標記爲'410 Gone'，以及是否須要保持此標記多長時間，徹底取決於服務器擁有者。
411	服務器拒絕在沒有定義Content-Length頭的狀況下接受請求。在添加了代表請求消息體長度的有效Content-Length頭以後，客戶端能夠再次提交該請求。
412	服務器在驗證在請求的頭字段中給出先決條件時，沒能知足其中的一個或多個。這個狀態碼容許客戶端在獲取資源時在請求的元信息（請求頭字段數據）中設置先決條件，以此避免該請求方法被應用到其但願的內容之外的資源上。
413	服務器拒絕處理當前請求，由於該請求提交的實體數據大小超過了服務器願意或者可以處理的範圍。此種狀況下，服務器能夠關閉鏈接以避免客戶端繼續發送此請求。　　若是這個情況是臨時的，服務器應當返回一個Retry-After的響應頭，以告知客戶端能夠在多少時間之後從新嘗試。
414	請求的URI長度超過了服務器可以解釋的長度，所以服務器拒絕對該請求提供服務。這比較少見，一般的狀況包括：　　本應使用POST方法的表單提交變成了GET方法，致使查詢字符串（Query String）過長。　　重定向URI「黑洞」，例如每次重定向把舊的URI做爲新的URI的一部分，致使在若干次重定向後URI超長。　　客戶端正在嘗試利用某些服務器中存在的安全漏洞攻擊服務器。這類服務器使用固定長度的緩衝讀取或操做請求的URI，當GET後的參數超過某個數值後，可能會產生緩衝區溢出，致使任意代碼被執行[1]。沒有此類漏洞的服務器，應當返回414狀態碼。
415	對於當前請求的方法和所請求的資源，請求中提交的實體並非服務器中所支持的格式，所以請求被拒絕。
416	若是請求中包含了Range請求頭，而且Range中指定的任何數據範圍都與當前資源的可用範圍不重合，同時請求中又沒有定義If-Range請求頭，那麼服務器就應當返回416狀態碼。　　假如Range使用的是字節範圍，那麼這種狀況就是指請求指定的全部數據範圍的首字節位置都超過了當前資源的長度。服務器也應當在返回416狀態碼的同時，包含一個Content-Range實體頭，用以指明當前資源的長度。這個響應也被禁止使用multipart/byteranges做爲其Content-Type。
417	在請求頭Expect中指定的預期內容沒法被服務器知足，或者這個服務器是一個代理服務器，它有明顯的證據證實在當前路由的下一個節點上，Expect的內容沒法被知足。
421	從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。
422	從當前客戶端所在的IP地址到服務器的鏈接數超過了服務器許可的最大範圍。一般，這裏的IP地址指的是從服務器上看到的客戶端地址（好比用戶的網關或者代理服務器地址）。在這種狀況下，鏈接數的計算可能涉及到不止一個終端用戶。
422	請求格式正確，可是因爲含有語義錯誤，沒法響應。（RFC 4918 WebDAV）423 Locked　　當前資源被鎖定。（RFC 4918 WebDAV）
424	因爲以前的某個請求發生的錯誤，致使當前請求失敗，例如PROPPATCH。（RFC 4918 WebDAV）
425	在WebDav Advanced Collections草案中定義，可是未出如今《WebDAV順序集協議》（RFC 3658）中。
426	客戶端應當切換到TLS/1.0。（RFC 2817）
449	由微軟擴展，表明請求應當在執行完適當的操做後進行重試。
500	服務器遇到了一個不曾預料的情況，致使了它沒法完成對請求的處理。通常來講，這個問題都會在服務器的程序碼出錯時出現。
501	服務器不支持當前請求所須要的某個功能。當服務器沒法識別請求的方法，而且沒法支持其對任何資源的請求。
502	做爲網關或者代理工做的服務器嘗試執行請求時，從上游服務器接收到無效的響應。
503	因爲臨時的服務器維護或者過載，服務器當前沒法處理請求。這個情況是臨時的，而且將在一段時間之後恢復。若是可以預計延遲時間，那麼響應中能夠包含一個Retry-After頭用以標明這個延遲時間。若是沒有給出這個Retry-After信息，那麼客戶端應當以處理500響應的方式處理它。　　注意：503狀態碼的存在並不意味着服務器在過載的時候必須使用它。某些服務器只不過是但願拒絕客戶端的鏈接。
504	做爲網關或者代理工做的服務器嘗試執行請求時，未能及時從上游服務器（URI標識出的服務器，例如HTTP、FTP、LDAP）或者輔助服務器（例如DNS）收到響應。　　注意：某些代理服務器在DNS查詢超時時會返回400或者500錯誤
505	服務器不支持，或者拒絕支持在請求中使用的HTTP版本。這暗示着服務器不能或不肯使用與客戶端相同的版本。響應中應當包含一個描述了爲什麼版本不被支持以及服務器支持哪些協議的實體。
506	由《透明內容協商協議》（RFC 2295）擴展，表明服務器存在內部配置錯誤：被請求的協商變元資源被配置爲在透明內容協商中使用本身，所以在一個協商處理中不是一個合適的重點。
507	服務器沒法存儲完成請求所必須的內容。這個情況被認爲是臨時的。WebDAV(RFC 4918)
509	服務器達到帶寬限制。這不是一個官方的狀態碼，可是仍被普遍使用。
510	獲取資源所須要的策略並無沒知足。（RFC 2774）