高校學生公寓管理系統_外文翻譯(范文)-資料下載頁

【導讀】Loosely,it. isfor.

　　

【正文】 ur sales tracking system with the context path /sales. This allows one servlet container to distinguish between the different applications it serves and dispatch requests like /sales/report?month=Jan to the sales tracking application and /hr/emplist to the human resources application. The remaining URI path is then used within the selected context to decide how to process the request by paring it to pathmapping rules defined by the application39。s deployment descriptor. Rules can be defined to send all requests starting with /report to one servlet and requests starting with /forecast to another. Another type of mapping rule can say that one servlet handles all requests with paths ending with a specific file extension, such as .jsp. shows how the different parts of the URI paths are used to direct the request processing to the right resource through the container and context. Each context is selfcontained and doesn39。t know anything about other applications running in the same container. References between the servlets and JSP pages in the application are monly relative to the context path and, therefore, are referred to as contextrelative paths. By using contextrelative paths within the application, a web application can be deployed using any context path. Finally, a context can hold objects shared by all ponents of the application, such as database connections and other shared resources needed by multiple servlets and JSP pages. 中文翻譯稿 應用技術學院 06 計算機 （ 0616403028）徐鵬程 2020 年 4 月 HTTP 和 Servlet 的基礎知識 讓我們從定義 Web 應用程序這一章開始。我們都看到過一般的客戶端應用軟件，但怎么樣才是一個真正的 Web 應用程序？然而，它可以被定義為一個用于用戶接入的運行在服務器上的程序，通過一個簡單，一般用途的客戶。今天，最常見的客戶端是一種運行在 pc機上的網頁瀏覽器或工作站系統，但其他類型的用戶正在迅速加入，如無線 PDA ，手機，和其他專門設備。 最崇高目標是從你面前的任何類型的設備上獲得你所要的 信息和服務。這意味著同樣的簡單客戶端程序必須能夠與許多不同的服務器應用通話，以及應用程序必須能夠適用于許多不同類型的客戶。為了滿足這一需要，必須制定詳細的客戶端和服務器相互通信的協義。這正是超文本傳輸協議（ HTTP ）的目的。 通信模型所確定的 HTTP 形式的基礎，所有的 Web 應用程序設計。基本了解 HTTP 的關鍵應用，適合發展中國家的限制范圍內的協議，無論哪個服務器端技術的使用。在本章中，我們看一下最重要的細節的 HTTP 您需要了解作為一個 Web 應用程序開發。 另外一個項目：這本書是用 JSP 作為服務器端技術。 JSP 技術是基于 Java Servlet技術。這兩種技術有著大量的術語和概念，所以知道一點 servlets 將幫助你，即使你開發純 JSP 的應用。要真正理解和使用的全部的 JSP ，你需要知道一點 servlets 。因此，我們期待在 servlet 的基本入在最后一章的這一節。 HTTP 請求 /響應模型 所有擴展 HTTP 和基于 HTTP 協議是基于一個非常簡單的通信模式。其工作原理如下：客戶端，通常是一個 Web 瀏覽器，發出了一個請求資源的服務器，服務器發回的響應相應的資源（或響應的錯誤信息，如果它不能處理請求出于 某種原因） 。 A資源是一些事情的數據，如一個簡單的 HTML 文件逐字返回到瀏覽器或程序，動態生成的響應。 這種簡單的模式意味著三個重要的事實你需要了解： HTTP 是一種無狀態協議。這意味著服務器不保留任何信息發出后客戶端的反應，因此，它不能承認，多請求來自同一客戶端可能有親緣關系。 Web 應用程序無法輕易地提供什么樣的即時反饋信息中常見的獨立的圖形用戶界面應用程序，如文字處理機或傳統客戶機 /服務器應用程序。每當它們之間的互動客戶端和服務器需要一個請求 /響應交流時。執行請求 /響應交流當用戶選擇一個項目在一個列 表框或 填寫表單元素通常是過于繁重的帶寬提供給大多數的互聯網用戶。 這里沒有什么協議告訴服務器如何提出要求 。因此，服務器無法在客戶端上區分各種方法觸發的要求。例如，不允許 HTTP Web 服務器來區分一個明確的要求所造成的點擊一個鏈接或提交表單和一個隱含的要求所造成的調整瀏覽器窗口或使用瀏覽器的后退按鈕。此外，超文本傳輸協定不包含任何手段服務器調用客戶端的特定職能，例如回去在瀏覽器歷史記錄列表或發送的反應在一定范圍內。另外，服務器無法檢測什么時候用戶關閉瀏覽器。 多年來，人們已經制定了各種技巧來克服務第一個問題 。HTTP 的無國籍性。其他兩個問題，沒有及時反饋，也沒有詳細說明如何提出要求，更難處理，但有些互動，才能實現所產生的反應，其中包括客戶端代碼（代碼執行的瀏覽器） ，如 JavaScript 或 Java 小程序。 詳敘 Requests 讓我們仔細看看 Requests。用戶發送請求到服務器，通過點擊一個鏈接的網頁上，提交表單時，或輸入一個網頁地址在瀏覽器的地址欄。發送請求后，瀏覽器需要知道與哪些服務器交換數據，并要求得到資源。 URL 必須跟據服務器名詳細描術端口號 ,例如： 第一部分所顯示的 URL 中指定的 Requests 是使用 HTTP 協議的。其次是服務器的名稱，在這種情況下 。 Web 服務器等待請求將在某一特定的 TCP / IP端口。端口號 80是標準端口，用于 HTTP 請求。如果 Web 服務器使用另一個端口， URL 必須跟據服務器名稱指定端口號。例如： 這一請求被發送到一臺服務器，使用端口 8080 而不 是 80 。最后部分的 URL ,/ ,確定了客戶端請求的資源。 網址實際上是一個專業化的統一資源標識符（ URI ，所界定的符合 RFC 2396 規格） 。URl 跟據地址確定部份資源，例如服務器，其中包含的資源。另一種類型的 URI是一個統一資源名稱（ URN） ，這是一個全局唯一標識符 ,無論在什么地方都有效的資源的位置。HTTP 只處理 URL 的不同。該條款的 URI 和 URL 常常被互換，不幸的是，他們有不同的定義略有不同的規格。我試圖使用條款所界定的 HTTP/ 規范（符合 RFC 2616年） ，這是相當接近，以他們是如何也用在 Servlet 和 JSP 規范。因此，我只有當 URI 以 開頭時才使用的 term URl （或 ，為 HTTP 加密連線） ，其次是服務器名稱，并可能有一個端口號，如以前的例子。我使用的 URI 作為一個通用術語的任何字符串，確定了資源，確定位置可以從上下文而不耍要 URI。例如，當請求已被交付給服務器，位置已經定確，只有資源標識符是很重要的。 瀏覽器使用 URL 信息創造的請求消息使用指定的協議發送到指定的服務器。 HTTP 請求消息由三部份組成：一個請求行，請求標頭， 請求體。 請求行以方法名稱的開頭，隨后進行了資源標識符和協議版本所使用的瀏覽器： GET / HTTP/ 最常用的方法是 GET。顧名思義， GET 請求用于從服務器檢索資源。這是默認的請求方法，因此，如果您輸入網址在瀏覽器的地址欄，或者點擊一個鏈接，發送的請求是作為一個 GET 請求到服務器。 標題要求提供額外的信息可以使用服務器來處理請求。郵件正文是只包含在某些類型的 requests，如 POST 請求以后討論。 下面是一個例子，一個有效的 HTTP 請求消息： GET / HTTP/ Host： 用戶代理： Mozilla/ (Windows。 U。 Win 9x 。 enUS。 rv: ) 接受： image/gif, image/jpeg, image/pjpeg, image/png, */* 接受語言： en 接受字符： iso88591,*,utf8 請求行指定的 GET 方法和要求的資源命名 / 使用 HTTP/ 協議返回。不同的頭提供不同的資料。 主機標頭使用 URL告訴服務器主機名 。服務器可能有多個名稱，因此這一信息是用來區分多個虛擬的網絡服務器共享相同的 Web 服務器進程。 user agent 標題包含有關類型的瀏覽器提出請求。服務器可以用它來傳送不同類型的反應，不同類型的瀏覽器。例如，如果服務器知道是使用 Inter Explorer 或 Netscape Navigator，它可以發出一個反應，充分利用每一個瀏覽器的獨特功能。它也可以判斷客戶端以外的 HTML 瀏覽器使用，如無線標記語言（標記語言）的瀏覽器的手機或 PDA 設備，并產生適當的反應。 請求頭提供有關 的語言和文件格式的瀏覽器。這些標題可以用來適應不同功能的瀏覽器和不同的用戶，如使用了一個受支持的圖像格式和首選語言。這些只是一小部分的標題中可以包含請求的信息。 資源標識符（ URI ） ，并不一定對應于一個靜態文件在服務器上。它可以識別一個可執行的程序，記錄在一個數據庫中，或差不多任何 Web 服務器知道。這就是通用術語資源的使用。事實上，就沒有辦法判斷 / 的通用資源識別符對應的文件還是其他什么東西，它只是一個名字，這意味著一些服務器。 Web 服務器被配置為地圖這些指定的名稱對應指定的資源 。 祥敘 response 當 Web 服務器收到請求，在 URI 的其礎上決定，用配置信息來處理它。它可以處理簡單的 HTML 文件，也可以將申請轉交給一些組成部分，負責相應的資源 URI 。這可能是一個程序使用的數據庫信息，例如，動態生成一個適當的反應。在瀏覽器沒有差別時 response是如何處理的 。一切關心的就得到了答復。 在回復郵件看起來類似請求消息。它包括三件事：一個狀態行，響應頭，和一個可選的反應機構。下面是一個例子： HTTP/ 200 OK LastModified: Mon, 20 Dec 2020 23:26:42 GMT Date: Tue, 11 Jan 2020 20:52:40 GMT Status: 200 ContentType: text/html ServletEngine: Tomcat Web Server/ ContentLength: 59 html body h1Hello World!/h1 /body /html 狀態行開頭的名稱協議，其次是狀態代碼，并有簡短的描述狀態代碼。在這里，狀態代碼是 200 ，這 意味著被執行的請求成功。回應郵件標題就像請求消息。在這個例子中，最后修改標題給出的日期和時間，資源最后修改。該瀏覽器可以使用此信息作為一個時間戳在本地緩存 。下一次用戶要求這一資源，他可以向服務器發送它只要當它被更新，因為這是最后一次要求。內容類型標頭講述了什么類型的瀏覽器的反應數據和身體包含的內容長度標題是多么大。其他標題不言自明。一個空行分隔標題的郵件正文。在這里，內容體是一個簡單的 HTML 網頁： html body h1Hello World!/h1 /body /html 當然， body 可以包含一個更為復雜的 HTML 網頁或任何其他類型的內容。例如，請求可能會返回一個 HTML 頁面的 img 要素。當瀏覽器讀取第一個反應時，并認為是 img 要素，它就發出了一個新的要求所確定的資源，往往是在平行。服務器返回一個響應，每幅圖像的要求，與內容類型標題告訴什么類型的影像（例如圖片 /