計(jì)算機(jī)專業(yè)外文翻譯（中英文）---http和servlet的基礎(chǔ)知識(shí)

上傳人：奔*** IP屬地：河北更新時(shí)間：2024-03-01 格式：docx 頁(yè)數(shù)：24 大?。?9.00KB 人氣指數(shù)：12 舉報(bào) 版權(quán)申訴

2023年全國(guó)碩士研究生考試考研英語(yǔ)一試題真題（含答案詳解+作文范文）_第1頁(yè)

已閱讀1頁(yè)，還剩23頁(yè)未讀，繼續(xù)免費(fèi)閱讀

版權(quán)說(shuō)明：本文檔由用戶提供并上傳，收益歸屬內(nèi)容提供方，若內(nèi)容存在侵權(quán)，請(qǐng)進(jìn)行舉報(bào)或認(rèn)領(lǐng)

文檔簡(jiǎn)介

1、　　附錄A 譯文　　HTTP和Servlet的基礎(chǔ)知識(shí)　　讓我們從定義Web應(yīng)用程序這一章開(kāi)始。我們都看到過(guò)一般的客戶端應(yīng)用軟件，但怎么樣才是一個(gè)真正的Web應(yīng)用程序？然而，它可以被定義為一個(gè)用于用戶接入的運(yùn)行在服務(wù)器上的程序，通過(guò)一個(gè)簡(jiǎn)單，一般用途的客戶。今天，最常見(jiàn)的客戶端是一種運(yùn)行在pc機(jī)上的

2、網(wǎng)頁(yè)瀏覽器或工作站系統(tǒng)，但其他類型的用戶正在迅速加入，如無(wú)線PDA ，手機(jī)，和其他專門設(shè)備。最崇高目標(biāo)是從你面前的任何類型的設(shè)備上獲得你所要的信息和服務(wù)。這意味著同樣的簡(jiǎn)單客戶端程序必須能夠與許多不同的服務(wù)器應(yīng)用通話，以及應(yīng)用程序必須能夠適用于許多不同類型的客戶。為了滿足這一需要，必須制定詳細(xì)的客戶端和服務(wù)器相互通信的協(xié)義。這正是超文本傳輸協(xié)議（ HTTP ）的目的。通信模型所確定的HTTP形式的基礎(chǔ)，所有的Web應(yīng)

3、用程序設(shè)計(jì)。基本了解HTTP的關(guān)鍵應(yīng)用，適合發(fā)展中國(guó)家的限制范圍內(nèi)的協(xié)議，無(wú)論哪個(gè)服務(wù)器端技術(shù)的使用。在本章中，我們看一下最重要的細(xì)節(jié)的HTTP您需要了解作為一個(gè)Web應(yīng)用程序開(kāi)發(fā)。另外一個(gè)項(xiàng)目：這本書(shū)是用JSP作為服務(wù)器端技術(shù)。 JSP技術(shù)是基于Java Servlet技術(shù)。這兩種技術(shù)有著大量的術(shù)語(yǔ)和概念，　　Last-Modified: Mon, 20 Dec 2002 23:26:

4、42 GMT　　Date: Tue, 11 Jan 2003 20:52:40 GMT　　Status: 200　　Content-Type: text/html　　Servlet-Engine: Tomcat Web Server/5.0<

5、p>　　Content-Length: 59　　<html>　　<body>　　<h1>Hello World!</h1>

6、　</body>　　</html>　　狀態(tài)行開(kāi)頭的名稱協(xié)議，其次是狀態(tài)代碼，并有簡(jiǎn)短的描述狀態(tài)代碼。在這里，狀態(tài)代碼是200 ，這意味著被執(zhí)行的請(qǐng)求成功。回應(yīng)郵件標(biāo)題就像請(qǐng)求消息。在這個(gè)例子中，最后修改標(biāo)題給出的日期和時(shí)間，資源最后修改。該瀏覽器可以使用此信息作為一個(gè)時(shí)間戳

7、在本地緩存;下一次用戶要求這一資源，他可以向服務(wù)器發(fā)送它只要當(dāng)它被更新，因?yàn)檫@是最后一次要求。內(nèi)容類型標(biāo)頭講述了什么類型的瀏覽器的反應(yīng)數(shù)據(jù)和身體包含的內(nèi)容長(zhǎng)度標(biāo)題是多么大。其他標(biāo)題不言自明。一個(gè)空行分隔標(biāo)題的郵件正文。在這里，內(nèi)容體是一個(gè)簡(jiǎn)單的HTML網(wǎng)頁(yè)：html>　　<body>　　<h

8、1>Hello World!</h1>　　</body>　　</html>　　當(dāng)然，人體可以包含一個(gè)更為復(fù)雜的HTML網(wǎng)頁(yè)或任何其他類型的內(nèi)容。例如，請(qǐng)求可能會(huì)返回一個(gè)HTML頁(yè)面的img要素。當(dāng)

9、瀏覽器讀取第一個(gè)反應(yīng)時(shí)，并認(rèn)為是img要素，它就發(fā)出了一個(gè)新的要求所確定的資源，往往是在平行。服務(wù)器返回一個(gè)響應(yīng)，每幅圖像的要求，與內(nèi)容類型標(biāo)題告訴什么類型的影像（例如圖片/ gif格式），體內(nèi)含有字節(jié)構(gòu)成的類型。　　2.1.3請(qǐng)求參數(shù) 除了URI和標(biāo)題，一個(gè)請(qǐng)求消息可以包含更多信息的形式參數(shù)。如果確定了的URI服務(wù)器端程序顯示天氣信息，例如，請(qǐng)求參數(shù)可以提供有關(guān)城市的用戶希望看到一個(gè)

10、預(yù)測(cè)。電子商務(wù)的應(yīng)用，開(kāi)放的我們可能會(huì)確定一個(gè)程序，處理訂單，與用戶的客戶數(shù)量和名單所要采購(gòu)的物品轉(zhuǎn)移作為參數(shù)。參數(shù)可以發(fā)出兩種方式之一：匯價(jià)上的URI形式的查詢字符串或發(fā)出的一部分，請(qǐng)求郵件正文。這是一個(gè)例子，一個(gè)網(wǎng)址的查詢字串：http://www.weather.com/forecast?city=Hermosa+Beach&state=CA 查詢字符串開(kāi)始問(wèn)號(hào)（？），由名稱/值對(duì)分隔符號(hào)（＆

11、）。這些名稱和值必須是URL編碼，也就是說(shuō)，特殊字符，如空格，問(wèn)號(hào)，符號(hào)，以及所有其他nonalphanumeric字符編碼，以便它們不會(huì)混淆字符用于分離名稱/值對(duì)和其他部分的URI 。在這個(gè)例子中，之間的空間荷摩莎和沙灘被編碼為一個(gè)加號(hào)。其他特殊字符的編碼為相應(yīng)的十六進(jìn)制ASCII值，例如，一個(gè)問(wèn)號(hào)被編碼為％ 3樓。參數(shù)時(shí)，發(fā)送的一部分機(jī)構(gòu)的要求，他們按照同樣的語(yǔ)法; URL編碼名稱　　&l

12、t;a href="/forecast?city=Hermosa+Beach&state=CA">　　Hermosa Beach weather forecast　　</a>　　當(dāng)您使用的一種形式發(fā)送用戶輸入到服務(wù)器，您可以指定是

13、否使用GET或POST方法的方法，屬性，如下所示:　　<form action="/forecast" method="POST">　　City: <input name="city" type="text">

14、　　State: <input name="state" type="text">　　　　<input type="SUBMIT">　　</form&

15、gt;　　如果用戶輸入“赫摩薩海灘”和“加州”的表單字段并點(diǎn)擊提交按鈕，瀏覽器發(fā)送一個(gè)請(qǐng)求消息這樣的服務(wù)器：POST /forecast HTTP/1.1　　Host: www.gefionsoftware.com　　User-Agent: Mozilla/5.0 (Windows; U;

16、Win 9x 4.90; en-US; rv: 1.0.2)　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*　　Accept-language: en-US　　Accept-charset: iso-8859-1,*,utf-8</p&

17、gt;　　city=Hermosa+Beach&state=CA　　由于不同的參數(shù)是如何發(fā)出的GET和POST請(qǐng)求，以及不同的目的，瀏覽器處理的要求以不同的方式。 GET請(qǐng)求，參數(shù)和所有，可以很容易地被保存為書(shū)簽，硬編碼為紐帶，和響應(yīng)緩存的瀏覽器。另外，瀏覽器都知道，沒(méi)有損害的是，如果它需要發(fā)出一個(gè)GET請(qǐng)求再次自動(dòng)，例如，如果用戶點(diǎn)擊刷新按鈕。 POST請(qǐng)

18、求，另一方面，不能書(shū)簽一樣容易;瀏覽器將節(jié)省的URI和郵件正文的要求。由于POST請(qǐng)求的目的是執(zhí)行一些不可逆轉(zhuǎn)的行動(dòng)可能在服務(wù)器上，瀏覽器還必須要求用戶如果奧凱發(fā)送再次請(qǐng)求除了GET和POST方法，即HTTP指定下列方法：OPTIONSThe期權(quán)方法是用來(lái)找出選項(xiàng)（例如，方法）一臺(tái)服務(wù)器或一個(gè)資源提供。頭的方法是用來(lái)得到回應(yīng)與所有標(biāo)題產(chǎn)生的GET請(qǐng)求，但身體。它可以確保一個(gè)鏈接是有效的，或看到一個(gè)資源的最后修改。P

19、UTThe PUT方法是用來(lái)儲(chǔ)存郵件正文內(nèi)容的服務(wù)器作為一種資源所確定的URI。DELETEThe Delete方法用于刪除所確定的資源的URI 。 TRACE方法是用于測(cè)試的溝通客戶端和服務(wù)器。服務(wù)器發(fā)回的信息的要求，正是因?yàn)樗玫剿驗(yàn)樯眢w的反　　2.2.1優(yōu)于其他服務(wù)器端技術(shù)　　簡(jiǎn)單來(lái)說(shuō)，一個(gè)servlet是一塊代碼，增加新功能的服務(wù)器

20、（通常是Web服務(wù)器），就像CGI和專有服務(wù)器擴(kuò)展，如NSAPI和的ISAPI 。但是，相對(duì)于其他技術(shù)， servlets有許多優(yōu)點(diǎn)：獨(dú)立平臺(tái)和供應(yīng)商的所有主要的Web服務(wù)器和應(yīng)用服務(wù)器的支持servlets ，因此一個(gè)servlet為基礎(chǔ)的解決方案不配合你一個(gè)具體的供應(yīng)商。另外， servlets是寫在Java編程語(yǔ)言，因此他們可以用來(lái)在任何操作系統(tǒng)上運(yùn)行的Java運(yùn)行環(huán)境。集成Servlets Java中的開(kāi)發(fā)，因此可

21、以充分利用所有其他的Java技術(shù)，如JDBC的數(shù)據(jù)庫(kù)訪問(wèn)， JNDI的對(duì)目錄的訪問(wèn)， RMI的遠(yuǎn)程資源訪問(wèn)等從版本2.2, 該servlet的規(guī)范是在Java 2企業(yè)版（ J2EE ），使servlets的一個(gè)重要組成部分任何大規(guī)模的企業(yè)應(yīng)用，并正式關(guān)系到其他服務(wù)器端的技術(shù)，如企業(yè)JavaBeans 。效率Servlets執(zhí)行的進(jìn)程中運(yùn)行，直到servlet的應(yīng)用程序被關(guān)閉。每個(gè)servlet的請(qǐng)求是作為一個(gè)單獨(dú)的執(zhí)行線程在

22、此永久進(jìn)程。這是更為有效的的CGI模式，在一個(gè)新的進(jìn)程創(chuàng)建的每　　附錄B 英文文獻(xiàn)　　HTTP and Servlet Basics　　Let's start off this chapter by defining the term web application.

23、 We've all seen regular client-side applications, but what exactly is a web application? Loosely, it can be defined as an application running on a server a user accesses through a thin, general-purpose client. Today,

24、 the most common client is a web browser on a PC or workstation, but other kinds of clients are rapidly joining the party, such as wireless PDAs, cell phones, and other specialized devices.　　The loft

25、y goal here is to access all the information and services you need from any type of device that happens to be in front of you. This means that the same simple client program must be able to talk to many different server

26、applications, and the applications must be able to work with many different types of clients. To satisfy this need, the protocol of how a client and a server talk to each other must be defined in detail. That's exact

27、ly what the HyperText Transport Protocol (HTTP) is for.　　The communication model defined by HTTP forms the foundation for all web application design. A basic understanding of HTTP is key to developin

28、g applications that fit within the constraints of the protocol, no matter which server-side technology you use. In this chapter, we look at the most important details of HTTP you need to be aware of as a web application

29、developer.　　One other item: this book is about using JSP as the server-side technology. JSP is based on the Java servlet technology. Both technologies share a lot of terminology and concepts, so know

30、ing a bit about servlets will help you even when you develop pure JSP applications. To really understand and use the full power of JSP, you need to know a fair bit about servlets. Hence, we look at servlet fundamentals i

31、n the last section of this chapter.　　2.1 The HTTP Request/Response Model　　HTTP and all extended protocols based on HTTP are based on a very simple communications model. Here'

32、s how it works: a client, typically a web browser, sends a request for a resource to a server, and the server sends back a response corresponding to the resource (or a response with an error message if it can't proce

33、ss the request for some reason). A resource can be a number of things, such as a simple HTML file returned verbatim to the browser or a program that generates the response dynamically.　　This simple m

34、odel implies three important facts you need to be aware of:　　HTTP is a stateless protocol. This means that the server doesn't keep any information about the client after it sends its response, an

35、d therefore it can't recognize that multiple requests from the same client may be related.　　Web applications can't easily provide the kind of immediate feedback typically found in standalone

36、GUI applications such as word processors or traditional client/server applications. Every interaction between the client and the server requires a request/response exchange. Performing a request/response exchange when a

37、user selects an item in a list box or fills out a form element is usually too taxing on the bandwidth available to most Internet users.　　There's nothing in the protocol that tells the server how

38、a request is made; consequently, the server can't distinguish between various methods of triggering the request on the client. For example, HTTP doesn't allow a web server to differentiate between an explicit req

39、uest caused by clicking a link or submitting a form and an implicit request caused by resizing the browser window or using the browser's Back button. In addition, HTTP doesn't contain any means for the server to

40、invoke client spec　　Over the years, people have developed various tricks to overcome the first problem; HTTP's stateless nature. The other two problems—no immediate feedback and no details about

41、how the request is made—are harder to deal with, but some amount of interactivity can be achieved by generating a response that includes client-side code (code executed by the browser), such as JavaScript or a Java apple

42、t. 　　2.1.1 Requests in Detail　　Let's take a closer look at requests. A user sends a request to the server by clicking a link on a web page, submitting a form, or typing in a

43、web page address in the browser's address field. To send a request, the browser needs to know which server to talk to and which resource to ask for. This information is specified by an HTTP Uniform Resource Locator (

44、URL):　　http://www.gefionsoftware.com/index.html　　The first part of the URL shown specifies that the request is made using the HTTP protocol. This is followed by the name of the s

45、erver, in this case www.gefionsoftware.com. The web server waits for requests to come in on a specific TCP/IP port. Port number 80 is the standard port for HTTP requests. If the web server uses another port, the URL must

46、 specify the port number in addition to the server name. For example:　　http://www.gefionsoftware.com:8080/index.html　　This request is sent to a server that uses port 8080 instead

47、 of 80. The last part of the URL, /index.html, identifies the resource that the client is requesting.　　A URL is actually a specialization of a Uniform Resource Identifier (URI, defined in the RFC-239

48、6 specification). A URL identifies a resource partly by its location, for instance the server that contains the resource. Another type of URI is a Uniform Resource Name (URN), which is a globally unique identifier that i

49、s valid no matter where the resource is located. HTTP deals only with the URL variety. The terms URI and URL are often used interchangeable, and unfortunately, they have slightly diffe　　The browser u

50、ses the URL information to create the request message it sends to the specified server using the specified protocol. An HTTP request message consists of three things: a request line, request headers, and possibly a reque

51、st body.　　The request line starts with the request method name, followed by a resource identifier and the protocol version used by the browser:　　GET /index.html HTTP/1.1

52、;　　The most commonly used request method is named GET. As the name implies, a GET request is used to retrieve a resource from the server. It's the default request method, so if you type a URL in the browse

53、r's address field, or click on a link, the request is sent as a GET request to the server.　　The request headers provide additional information the server may use to process the request. The messa

54、ge body is included only in some types of requests, like the POST request discussed later.　　Here's an example of a valid HTTP request message:　　GET /index.html HTTP/1.1</p

55、>　　Host: www.gefionsoftware.com　　User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv: 1.0.2)　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*<

56、/p>　　Accept-Language : en　　Accept-Charset : iso-8859-1,*,utf-8　　The request line specifies the GET method and asks for the resource named /index.html to be returned

57、 using the HTTP/1.1 protocol version. The various headers provide additional information.　　The Host header tells the server the hostname used in the URL. A server may have multiple names, so this inf

58、ormation is used to distinguish between multiple virtual web servers sharing the same web server process.　　The User-Agent header contains information about the type of browser making the request. The

59、 server can use this to send different types of responses to different types of browsers. For instance, if the server knows whether Internet Explorer or Netscape Navigator is used, it can send a response that takes advan

60、tage of each browser's unique features. It can also tell if a client other than an HTML browser is used, such as a Wireless Markup Language (WML) browser on a cell phone or a PDA device, a　　The A

61、ccept headers provide information about the languages and file formats the browser accepts. These headers can be used to adjust the response to the capabilities of the browser and the user's preferences, such as use

62、a supported image format and the preferred language. These are just a few of the headers that can be included in a request message. 　　The resource identifier (URI) doesn't necessarily correspond

63、to a static file on the server. It can identify an executable program, a record in a database, or pretty much anything the web server knows about. That's why the generic term resource is used. In fact, there's no

64、 way to tell if the /index.html URI corresponds to a file or something else; it's just a name that means something to the server. The web server is configured to map these unique names to the real resources.

65、;　　2.1.2 Responses in Detail　　When the web server receives the request, it looks at the URI and decides, based on configuration information, how to handle it. It may handle it internally b

66、y simply reading an HTML file from the filesystem, or it can forward the request to some component that is responsible for the resource corresponding to the URI. This can be a program that uses database information, for

67、instance, to dynamically generate an appropriate response. To the browser it makes no difference how the request is handle　　The response message looks similar to the request message. It consists of t

68、hree things: a status line, response headers, and an optional response body. Here's an example:　　HTTP/1.1 200 OK　　Last-Modified: Mon, 20 Dec 2002 23:26:42 GMT<

69、p>　　Date: Tue, 11 Jan 2003 20:52:40 GMT　　Status: 200　　Content-Type: text/html　　Servlet-Engine: Tomcat Web Server/5.0　　Content-Length:

70、 59　　<html>　　<body>　　<h1>Hello World!</h1>　　</body></b&g

71、t;　　</html>　　The status line starts with the name of the protocol, followed by a status code and a short description of the status code. Here the status

72、code is 200, meaning the request was executed successfully. The response message has headers just like the request message. In this example, the Last-Modified header gives the date and time for when the resource was last

73、 modified. The browser can use this information as a timestamp in a local cache; the next time the user asks for this resource, he can ask t　　<html><b

74、>　　<body>　　<h1>Hello World!</h1>　　</body>　　</html>　　Of

75、course, the body can contain a more complex HTML page or any other type of content. For example, the request may return an HTML page with <img> elements. When the browser reads the first response and finds the <

76、img> elements, it sends a new request for the resource identified by each element, often in parallel. The server returns one response for each image request, with a Content-Type header telling what type of image it is

77、 (for instance image/gif) and the body containing the bytes that make　　2.1.3 Request Parameters　　Besides the URI and headers, a request message can contain additional information

78、 in the form of parameters. If the URI identifies a server-side program for displaying weather information, for example, request parameters can provide information about the city the user wants to see a forecast for. In

79、an e-commerce application, the URI may identify a program that processes orders, with the user's customer number and the list of items to be purchased transferred as parameters.　　Parameters can b

80、e sent in one of two ways: tacked on to the URI in the form of a query string or sent as part of the request message body. This is an example of a URL with a query string:　　http://www.weather.com/for

81、ecast?city=Hermosa+Beach&state=CA　　The query string starts with a question mark (?) and consists of name/value pairs separated by ampersands (&). These names and values must be URL-encoded, m

82、eaning that special characters, such as whitespace, question marks, ampersands, and all other nonalphanumeric characters are encoded so that they don't get confused with characters used to separate name/value pairs a

83、nd other parts of the URI. In this example, the space between Hermosa and Beach is encoded as a plus sign. Other special charact　　2.1.4 Request Methods　　As described earlier, GET

84、 is the most commonly used request method, intended to retrieve a resource without causing anything else to happen on the server. The POST method is almost as common as GET; it requests some kind of processing on the ser

85、ver, for instance, updating a database or processing a purchase order.　　The way parameters are transferred is one of the most obvious differences between the GET and POST request methods. A GET reque

86、st always uses a query string to send parameter values, while a POST request always sends them as part of the body (additionally, it can send some parameters as a query string, just to make life interesting). If you inse

87、rt a link in an HTML page using an <a> element, clicking on the link results in a GET request being sent to the server. Since the GET request uses a quer　　<a href="/forecast?city=Hermos

88、a+Beach&state=CA">　　Hermosa Beach weather forecast　　</a>　　When you use a form to send user input to the server, you can

89、specify whether to use the GET or POST method with the method attribute, as shown here:　　<form action="/forecast" method="POST">　　City: <input name=&

90、quot;city" type="text">　　State: <input name="state" type="text">　　　　<input type=&q

91、uot;SUBMIT">　　</form>　　If the user enters "Hermosa Beach" and "CA" in the form fields and clicks on the Submit button, the br

92、owser sends a request message like this to the server:　　POST /forecast HTTP/1.1　　Host: www.gefionsoftware.com　　User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.

93、90; en-US; rv: 1.0.2)　　Accept: image/gif, image/jpeg, image/pjpeg, image/png, */*　　Accept-language: en-US　　Accept-charset: iso-8859-1,*,utf-8<

94、p>　　city=Hermosa+Beach&state=CA　　Due to the differences in how parameters are sent by GET and POST requests, as well as the differences in their intended purpose, browsers handle the requests

95、in different ways. A GET request, parameters and all, can easily be saved as a bookmark, hardcoded as a link, and the response cached by the browser. Also, the browser knows that no damage is done if it needs to send a G

96、ET request again automatically, for instance if the user clicks the Reload button.　　A POST request, on the other hand, can't be bookmarked as easily; the browser would have to save both the URI a

97、nd the request message body. Since a POST request is intended to perform some possibly irreversible action on the server, the browser must also ask the user if it's okay to send the request again

98、　　Besides the GET and POST methods, HTTP specifies the following methods:　　OPTIONSThe OPTIONS method is used to find out what options (e.g., methods) a server or a resource offers.<p&

99、gt;　　HEADThe HEAD method is used to get a response with all headers generated by a GET request but without the body. It can make sure a link is valid or to see when a resource was last modified.　　PU

100、TThe PUT method is used to store the message body content on the server as a resource identified by the URI.　　DELETEThe DELETE method is used to delete the resource identified by the URI.

101、　　TRACEThe TRACE method is used for testing the communication between the client and the server. The server sends back the request message, exactly as it received it, as the body of the response.&

102、lt;p>　　These methods aren't normally used in a web application.　　2.2 Servlets　　The JSP specification is based on the Java servlet specification. In fact, JSP pages are oft

103、en combined with servlets in the same application. In this section, we take a brief look at what a servlet is, and then discuss the concepts shared by servlets and JSP pages. In Chapter 3, we'll take a closer look at

104、 how JSP pages are actually turned into servlets automatically.　　If you're already familiar with servlets, this is old news. You can safely skip the rest of this chapter.　　2.

105、2.1 Advantages over Other Server-Side Technologies　　In simple terms, a servlet is a piece of code that adds new functionality to a server (typically a web server), just like CGI and proprietary serve

眾賞文庫(kù)> 全部分類> 畢業(yè)設(shè)計(jì)

溫馨提示

1. 本站所有資源如無(wú)特殊說(shuō)明，都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請(qǐng)下載最新的WinRAR軟件解壓。
2. 本站的文檔不包含任何第三方提供的附件圖紙等，如果需要附件，請(qǐng)聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
3. 本站RAR壓縮包中若帶圖紙，網(wǎng)頁(yè)內(nèi)容里面會(huì)有圖紙預(yù)覽，若沒(méi)有圖紙預(yù)覽就沒(méi)有圖紙。
4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
5. 眾賞文庫(kù)僅提供信息存儲(chǔ)空間，僅對(duì)用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理，對(duì)用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯，并不能對(duì)任何下載內(nèi)容負(fù)責(zé)。
6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容，請(qǐng)與我們聯(lián)系，我們立即糾正。
7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時(shí)也不承擔(dān)用戶因使用這些下載資源對(duì)自己和他人造成任何形式的傷害或損失。

計(jì)算機(jī)專業(yè)外文翻譯（中英文）---http和servlet的基礎(chǔ)知識(shí)

文檔簡(jiǎn)介

溫馨提示

最新文檔

評(píng)論

計(jì)算機(jī)專業(yè)外文翻譯（中英文）---http和servlet的基礎(chǔ)知識(shí)

文檔簡(jiǎn)介

溫馨提示

最新文檔

評(píng)論

免費(fèi)下載