版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領
文檔簡介
1、枸川呻扎文學 本科生畢業(yè)設計(論文)外文資料譯文 設計(論文)題目:基于JSP的人才招聘網(wǎng)站的設計與實現(xiàn) 外文資料翻譯(譯文不少于2000漢字) 1 所譯外文資料: 作者:Nagle Wiegley 書名(或論文題目):An Overview of Servlet and JSP Technology 出版社(或刊物名稱):Westermann Verlagsgruppe Publishers 出版時間(或刊號):2007-8-6 所譯頁碼:第5頁-第10頁 2譯成中文: 1.1 Servlet 的功能 Servlets是運行在Wet或應用服務器上的Java程序,它是一個中間層,負責連接 來自
2、Web瀏覽器或其他HTTP客戶程序的請求和HTTP服務器上的數(shù)據(jù)庫或應用程序。 Servlet的工作是執(zhí)行西門的任務。 讀取客戶發(fā)送的顯式數(shù)據(jù)。 最終用戶一般在頁面的HTM表單中輸入這些數(shù)據(jù)。然而,數(shù)據(jù)還有可能來自applet 或定制的HTTP客戶程序。 (1)讀取由瀏覽器發(fā)送的隱式請求數(shù)據(jù)。 圖1.1中顯示了一條從客戶端到 Web服務器的單箭頭,但實際上從客戶端傳送到 Web服務器的數(shù)據(jù)有兩種,它們分別為用戶在表單中輸入的顯式數(shù)據(jù),以及后臺的HTTP 信息。兩種數(shù)據(jù)都很重要。HTTP信息包括cookie、瀏覽器所能識別的媒體類型和壓縮 模式等。 (2)生成結果。 這個過程可能需要訪問數(shù)據(jù)庫、
3、 執(zhí)行RMI或EJB調用、調用Web服務,或者直接計 算得出對應的響應。實際的數(shù)據(jù)可能存儲在關系型數(shù)據(jù)庫中。該數(shù)據(jù)庫可能不理解 HTTP或者不能返回HTML形式的結果,所有 Web瀏覽器不能直接與數(shù)據(jù)庫進行會話。 即使它能夠做到這一點,為了安全上的考慮,我們也不希望讓它這么做。對應大多數(shù)其 他應用程序,也存在類似的問題。因此,我們需要Web中間層從HTTP流中提取輸入數(shù) 據(jù),與應用程序會話,并將結果嵌入到文檔中。 (3)向客戶發(fā)送顯式數(shù)據(jù)(即文檔)。 這個文檔可以用各種格式發(fā)送,包括文本(HTM或 XM)二進制(GIF圖),甚至 可以式建立在其他底層格式之上的壓縮格式,如gzip。但是,到目前
4、為止,HTML式最 常用的格式,故而servelt和JSP的重要任務之一就式將結果包裝到HTML中 (4)發(fā)送隱式的HTTP響應數(shù)據(jù)。 圖1.1中顯示了一條從 Web中間層到客戶端的單箭頭。但是,實際發(fā)送的數(shù)據(jù)有兩 種:文檔本身,以及后臺的HTTP信息。同樣,兩種數(shù)據(jù)對開發(fā)來說都式至關重要的。 HTTP響應數(shù)據(jù)的發(fā)送過程涉及告知瀏覽器或其他客戶程序所返回文檔的類型(如 HTML,設置cookie和緩存參數(shù),以及其他類似的任務。 1.2動態(tài)構建網(wǎng)頁的原因 預先建立的文檔可以滿足客戶的許多請求,服務器無需調用servlet就可以處理這 些請求。然而,許多情況下靜態(tài)的結果不能滿足要求, 我們需要針對
5、每個請求生成一個 頁面。實時構建頁面的理由有很多種: 1、網(wǎng)頁基于客戶發(fā)送的數(shù)據(jù)。 例如,搜索引擎生成的頁面,以及在線商店的訂單確認頁面,都要針對特定的用戶 請求而產(chǎn)生。在沒有讀取到用戶提交的數(shù)據(jù)之前,我們不知道應該顯示什么。要記住, 用戶提交兩種類型的數(shù)據(jù):顯示(即 HTML表單的數(shù)據(jù))和隱式(即HTTP請求的報頭)。 兩種輸入都可用來構建輸出頁面?;?cookie值針對具體用戶構建頁面的情況尤其普 遍。 2、頁面由頻繁改變的數(shù)據(jù)導出。 如果頁面需要根據(jù)每個具體的請求做出相應的改變,當然需要在請求發(fā)生時構建響 應。但是,如果頁面周期性地改變,我們可以用兩種方式來處理它:周期性地在服務器 上
6、構建新的頁面(和客戶請求無關),或者僅僅在用戶請求該頁面時再構建。具體應該 采用哪種方式要根據(jù)具體情況而定, 但后一種方式常常更為方便,因為它只需簡單地等 待用戶的請求。例如,天氣預報或新聞網(wǎng)站可能會動態(tài)地構建頁面,也有可能會返回之 前構建的頁面(如果它還是最新的話)。 3、頁面中使用了來自公司數(shù)據(jù)庫或其他數(shù)據(jù)庫斷數(shù)據(jù)源的信息。 如果數(shù)據(jù)存儲在數(shù)據(jù)庫中,那么,即使客戶端使用動態(tài)Web內(nèi)容,比如applet, 我們依舊需要執(zhí)行服務器端處理。想象以下,如果一個搜索引擎網(wǎng)站完全使用applet, 那么用戶將會看到:“正在下載50TB的applet,請等待!”顯然,這樣很愚蠢;這種 情況下,我們需要與
7、數(shù)據(jù)庫進行會話。從客戶端到Web層再到數(shù)據(jù)庫(三層結構),要 比從applet直接到數(shù)據(jù)庫(二層結構)更靈活,也更安全,而性能上的損失很少甚至 沒有。畢竟數(shù)據(jù)庫調用通常是對速度影響最大的步驟,因而,經(jīng)過中間層可以執(zhí)行高速 緩存和連接共享 理論上講,servelt并非只用于處理HTTP請求的Web!務器或應用服務器,它同 樣可以用于其他類型的服務器。例如,servlet能夠嵌入到FTP或郵件服務器中,擴展 他們的功能。而且,用于會話啟動協(xié)議服務器的 servlet API最近已經(jīng)被標準化(參見 /en/jsr/detail?id=116)。但在實踐中,servelt 的
8、這種用法尚不流行, 在此,我們只論述HTTP Servlet。 1.3 Servlet 相對于“傳統(tǒng)” CGI的優(yōu)點 和傳統(tǒng)CGI及許多類CGI技術相比,Java servelt 效率更高、更易用、更強大、 更容易移植、更安全、也更廉價。 1、效率 應用傳統(tǒng)的CGI,針對每個HTTP青求都用啟動一個新的進程。如果 CGI程序自身 相對比較簡短,那么啟動進程的開銷會占用大部分執(zhí)行時間。而使用servelt ,Java 虛擬機會一直運行,并用輕量級的 Java線程處理每個請求,而非重量級的操作系統(tǒng)進 程。類似地,應用傳統(tǒng)的 CGI技術,如果存在對同一 CGI程序的N個請求,那么CGI 程序的代碼會
9、載入內(nèi)存N次。同樣的情況,如果使用servlet則啟動N個線程,單僅僅 載入servlet類的單一副本。這種方式減少了服務器的內(nèi)存需求,通過實例化更少的對 象從而節(jié)省了時間。最后,當CGI程序結束對請求的處理之后,程序結束。這種方式難 以緩存計算結果,保持數(shù)據(jù)庫連接打開,或是執(zhí)行依靠持續(xù)性數(shù)據(jù)的其他優(yōu)化。然而, servelt會一直停留在內(nèi)存中(即使請求處理完畢),因而可以直接存儲客戶請求之間 的任意復雜數(shù)據(jù)。 2、便利 Servelt提供大量的基礎構造,可以自動分析和解碼HTML的表單數(shù)據(jù),讀取和設 置HTTPfi頭,處理cookie,跟蹤會話,以及其他次類高級功能。而在CGI中,大部分 工
10、作都需要我們資金完成。另外,如果您已經(jīng)了解了Java編程語言,為什么還有學校 Perl呢?您已經(jīng)承認應用 Java技術編寫的代碼要比 Visual Basic,VBScript或C+ + 編寫的代碼更可靠,且更易重用,為什么還有倒退回去選擇那些語言來開發(fā)服務器端的 程序呢? 3、強大 Servlet支持常規(guī)CGI難以實現(xiàn)或根本不能實現(xiàn)的幾項功能。Servlet能夠直接于 Web務器對話,而常規(guī)的CGI程序做不到這一點,至少在不使用服務器專有API的情 況下是這樣。例如,與Web服務器的通信使得講相對URL轉換成具體的路徑名變得更為 容易。多個servelt還可以共享數(shù)據(jù),從而易于實現(xiàn)數(shù)據(jù)庫連接
11、共享和類似的資源共享 優(yōu)化。Servelt還能維護請求之間的信息,使得諸如會話跟蹤和計算結果緩存等技術變 得更為簡單。 4、可移植性 Servelt使用Java編程語言,并且遵循標準的API。所有主要的Web服務器。實際 上都直接或通過插件支持 servlet。因此。為Macromedia JRun編寫的servlet,可以 不經(jīng)過任何修改地在 Apache Tomcat,Microsoft In ternet In formation Server, IBM WebSphere。iPlanet Enterprise Server 。 Oracle9i AS 或者 StrNine WebSta
12、r 上運 行。他們是java2平臺企業(yè)版的一部分,所以對servlet的支持越來越普遍。 5、廉價 對于開發(fā)用的網(wǎng)站、低容量或中等容量網(wǎng)站的部署,有大量免費或極為廉價的Web 服務器可供選擇。因此,通過使用servelt和jsp,我們可以從免費或廉價的服務器開 始,在項目獲得初步成功后,在移植到更高性能或高級管理工具的昂貴的服務器上。這 與其他CGI方案形成鮮明的對比,這些CGI方案在初期都需要為購買專利軟件包投入大 量的資金。 價格和可移植性在某種程度上是相互關聯(lián)的。例如, Marty記錄了所有通過電子郵 件向他發(fā)送問題的讀者的所在國。印度接近列表的頂端,可能僅次于美國。Marty曾在 馬尼
13、拉講授過jsp和servlet培訓課程,那兒對servelt和jsp技術抱很大的興趣。 那么,為什么印度和菲律賓都對這項技術著呢感興趣呢?我們推測答案可能分兩部 分。首先,這兩個國家都擁有大量訓練有素的軟件開發(fā)人員。其次,這兩個國家的貨幣 對美元的匯率都極為不利。因此,從美國公司那里購買專用 Web服務器會消耗掉項目的 大部分前期資金。 但是,使用servlet和JSP,他們能夠從免費的服務器開始:Apache Tomcat。項 目取得成功之后,他們可以轉移到性能更高、管理更容易,但需要付費的服務器。他們 的servelt和jsp不需要重寫編寫。如果他們的項目變得更龐大,他們或許希望轉移到 分
14、布式環(huán)境。沒有問題:他們可以轉而使用Macromedia JRun Professio nal ,該服務 器支持分布式應用。同樣,他們的servelt和jsp沒有任何部分需要重寫。如果項目變 得極為龐大,錯綜復雜,他們或許希望使用En terprise JavaBea ns 來圭寸裝他們的商業(yè) 邏輯。因此,他們可以切換到 BEAWebLogic或Oracle9i AS同樣,不需要對servlet 和jsp做出更改。最后,如果他們的項目變得更龐大,他們或許將他從Linux轉移到運 行IBM WebSphere的IBM大型機上。他們還是不需要做出任何更改。 6、安全 傳統(tǒng)CGI程序中主要的漏洞來源
15、之一就是,CGI程序常常由通過的操作系統(tǒng)外殼來 執(zhí)行。因此,CGI程序必須仔細地過濾掉那些可能被外殼特殊處理的字符,如反引導和 分號。實現(xiàn)這項預防措施的難度可能超出我們的想象,在廣泛應用的CGI庫中,不斷發(fā) 現(xiàn)由這類問題引發(fā)的弱點。 問題的第二個來源是,一些CGI程序用不自動檢查數(shù)組和字符串邊界的語言編寫而 成。例如,在C和C+ +中,可以分配一個100個元素的數(shù)組,然后向第999個“元素 “寫入數(shù)據(jù)一一實際上是程序內(nèi)存的隨機部分,這完全合法。因而,如果程序員忘記執(zhí) 行這項檢查,就會將系統(tǒng)暴露在蓄意或偶然的緩沖區(qū)溢出攻擊之下。 Servelt不存在這些問題。即使servelt執(zhí)行系統(tǒng)調用激活本
16、地操作系統(tǒng)上的程序, 它也不會用到外殼來完成這項任務。當然,數(shù)組邊界的檢查以及其他內(nèi)存包含特性是 java編程語言的核心部分。 7、主流 雖然存在許多很好的技術,但是,如果提供商助支持他們,或開發(fā)人員不知道如何 使用這些技術,那么它們的優(yōu)點又如何體現(xiàn)呢? servelt和jsp技術得到服務器提供商 的廣泛支持,包括 Apache, Oracle , IBM, Sybase, BEA Maromedia, Causho, Sun/iPlanet , NewAtlanta , ATG Fujitsu , Lutris , Silverstream , World Wide WebConsortin
17、rm , 以及其他服務器。存在幾種低廉的插件,通過應用這些插件,Microsoft IIS 和Zeus 也同樣支持servlet 和jsp技術,它們運行在 Windows Unix/Linus,MacOS,VMS,和IBM 大型機操作系統(tǒng)之上。它們用在航空業(yè)、電子商務、在線銀行、web搜索引擎、門戶、 大型金融網(wǎng)站、以及成百上千您日常光顧的其他網(wǎng)站。 當然,僅僅是流行并不能證明技術的優(yōu)越性。很多泛美的例子。但我們的立場是: 服務器端Java本非一項新的、為經(jīng)證實的技術。 An Overview of Servlet and JSP Technology 1.1 A Servlets Job S
18、ervlets are Java programs that run on Web or application servers, acting as a middle layer betweenrequests coming from Web browsers or other HTTP clients and databases or applicatio ns on the HTTP server. Their job is to perform the followi nq tasks. 1. Read the explicit data sent by the client. The
19、 end user normally enters this data in an HTMLorm on a Webpage. However, the data could also come from an applet or a custom HTTP client program. 2. Read the implicit HTTP request data sent by the browser. Figure 1-1 shows a single arrow going from the client to the Webserver (the layer where servle
20、ts and JSP execute), but there are really two varieties of data: the explicit data that the end user enters in a form and the behind-the-scenesHTTP information.Both varieties are critical. The HTTF in formatio n in cludes cookies, in formati on about media types and compressi on schemes the browser
21、un dersta nds, and so on. 3. Gen erate the results. This process mayrequire talking to a database, executing an RMIor EJB call, invoking a Web service,or computi ng the resp onse directly. Your real data may be in a relatio nal database. Fine. But your database probably does nt speak HTTP or return
22、results in HTML,so the Webbrowser cant talk directly to the database. Even if it could, for security reasons, you probably would not want it to. The sameargument applies to most other applications.Youneed the Web middle layer to extract the results in side a docume nt. 4. Send the explicit data (i.e
23、., the document) to the client. This docume nt can be sent in a variety of formats, in clud ing text (HTML or XML), binary (GIF images), or even a compressed format like gzip that is layered on top of some other un derly ing format. But, HTML is by far the most com mon format, so an importa nt servl
24、et/JSP task is to wrap the results in side of HTML. 5. Send the implicit HTTP response data. Figure 1-1 shows a single arrow going from the Webmiddle layer (the servlet or JSP page) to the clie nt. But, there are really two varieties of data sent: the docume nt itself and the behi nd-the-sce nes HTT
25、P in formati on. Agai n, both varieties are critical to effective developme nt. Sending HTTP resp onse data invo Ives telli ng the browser or other clie nt what type of docume nt is being retur ned (e.g., HTML), sett ing cookies and cach ing parameters, and other such tasks. 1.2 Why Build Web Pages
26、Dy namically? manyclient requests can be satisfied by prebuiltdocuments, and the server would handle these requests without invoking servlets. In many cases, however, a static result is not sufficie nt, and a page n eeds to be gen erated for each request. There are a number of reasons why Webpages n
27、eed to be built on-the-fly: 1. The Web page is based on data sent by the client. For in sta nee, the results page from search engines and order-co nfirmatio n pages at online stores are specific to particular user requests. You dont know what to display un til you read the data that the user submits
28、. Just remember that the user submits two kinds of data: explicit (i.e., HTML form data) and implicit (i.e., HTTPrequest headers). Either ki nd of in put can be used to build the output page. In particular, it is quite commorto build a user-specific page based on a cookie value. 2. The Web page is d
29、erived from data that changes frequently. If the page changes for every request, then you certainly need to build the response at request time. If it changes only periodically, however, you could do it two ways: you could periodically build a new Web page on the server (in depe nden tly of clie nt r
30、equests), or you could wait and only build the page when the user requests it. The right approach depends on the situation, but sometimes it is more convenient to do the latter: wait for the user request. For example, a weather report or n ews headli nes site might build the pages dyn amically, perh
31、aps retur ning a previously built page if that page is still up to date. 3 . The Web page uses informationfrom corporate databases or other server-side sources. If the information is in a database, you need server-side processing even if the clie nt is using dyn amic Web content such as an applet. I
32、mag ine using an applet by itself for a search engine site: Downloading 50 terabyte applet, please wait! Obviously, that is silly; you need to talk to the database. Going from the client to the Web tier to the database (a three-tier approach) in stead of from an applet directly to a database (a two-
33、tier approach) provides in creased flexibility and security with little or no performanee penalty. After all, the database call is usually the rate-limiting step, so goingthrough the Web server does not slow things down. In fact, a three-tier approach is often faster because the middle tier can perf
34、orm cachi ng and connection pooli ng. In principle, servlets are not restricted to Webor applicationservers that han dle HTTP requests but can be used for other types of servers as well. For example, servlets could be embedded in FTP or mail servers to extend their functionality.And, a servlet API f
35、or SIP (Session InitiationProtocol) servers was recentlystandardized (see/en/jsr/detail?id=116).In practice, however, this use of servlets has not caught on, and well only be discuss ing HTTP servlets. 1.3 The Advantages of Servlets Over Traditional CGI Java servlets are more efficient,
36、easier to use, more powerful, more portable, safer, and cheaper tha n traditi onalCGI and man yalter nativeCGI-like tech nologies. 1. Efficient With traditional CGI, a new process is started for each HTTP request. If the CGI program itself is relatively short, the overhead of starting the process ca
37、n dominate the execution time. With servlets, the Java virtual machine stays running and handles each request with a lightweight Java thread, not a heavyweight operating system process. Similarly, in traditional CGI, if there are N requests to the same CGI program, the code for the CGI program is lo
38、aded into memoryN times. With servlets, however, there would be N threads, but only a single copy of the servlet class would be loaded. This approach reduces server memoryrequirements and saves time by instantiatingfewer objects. Finally,when a CGI program fini shes han dli ng a request, the program
39、 term in ates.This approach makes it difficult to cache computati ons, keep database connections ope n, and perform other optimizati ons that rely on persiste nt data. Servlets, however, remain in memory even after they complete aresponse, so it is straightforward to store arbitrarily complex data b
40、etwee n clie nt requests. 2. Convenient Servlets have an exte nsive in frastructure for automatically pars ing and decod ing HTML form data, read ing and sett ing HTTP headers, han dli ng cookies, track ing sessi ons, and many other such high-level utilities. In CGI, you have to do much of this your
41、self. Besides, if you already know the Java programming Ian guage, why lear n Perl too? Youre already convin ced that Java tech no logy makes for more reliable and reusable code tha ndoes Visual Basic, VBScript, or C+. Why go back to those Ian guages for server-side programmi ng? 3. Powerful Servlet
42、s support several capabilities that are difficult or impossible to accomplish with regular CGI. Servlets can talk directly to the Web server, whereas regular CGI programs cannot, at least not without using a server-specific API. Communi cat ing with the Web server makes it easier to tran slaterelati
43、ve URLs in to con crete path n ames, for in sta nee.Multiple servlets can also share data, maki ng it easy to impleme nt database connection pooling and similar resource-sharingoptimizations.Servlets can also maintain in formatio nfrom request to request,simplifyi ngtech niq ues likesessi on track i
44、ng and cach ing of previous computatio ns. 4. Portable Servlets are written in the Java programming Ianguage and follow a standard API. Servlets are supported directly or by a plug in on virtually every major Web server. Con seque ntly, servlets writte n for, say, Macromedia JRun can run virtually u
45、n cha nged on Apache Tomcat, Microsoft Internet In formati on Server (with a separate plugin), IBM WebSphere, iPlanet Enterprise Server, Oracle9i AS, or Star Nine WebStar. They are part of the Java 2 Platform, En terprise Editi on (J2EE; see http:/java.s un. com/j2ee/), so in dustry support for serv
46、lets is beco ming eve n more pervasive. 5. Inexpensive A nu mber of free or very in expe nsive Web servers are good for developme nt use or deployment of low- or medium-volume Web sites. Thus, with servlets and JSP you can start with a free or inexpensive server and migrate to more expensive servers
47、 withhigh-performa neecapabilities or adva need admi nistrati on utilities only after your project meets in itial success. This is in con trast to many of the other CGI alter natives, which require a sig nifica nt in itial inv estme nt for the purchase of a proprietary package. Price and portability
48、 are somewhat conn ected. For example, Marty tries to keep track of the coun tries of readers that send him questi ons by email. In dia was near the top of the list, probably #2 behind the U.S. Marty also taught one of his JSP and servlet training courses (see http:/ in Man ila, and there was great
49、in terest in servlet and JSP tech no logy there. Now, why are India and the Philippinesboth so interested? We surmise that the answer is twofold. First, both countrieshave large pools of well-educated software developers. Second, both countries have (or had, at that time) highly unfavorable currency
50、 exchange rates against the U.S. dollar. So, buying a special-purpose Web server from a U.S. compa ny con sumed a large part of early project fun ds. But, with servlets and JSP, they could start with a free server: Apache Tomcat (eitherstandalone,embedded in the regular Apache Web server, or embedde
51、d in Microsoft IIS). Once the project starts to become successful, they could moveto a server like Caucho Resin that had higher performanee and easier administration but that is not free. But none of their servlets or JSP pages have to be rewritten. If their project becomes even larger, they might w
52、ant to move to a distributed (clustered) en vir onment. No problem: they could move to Macromedia JRun Professi on al, which supports distributed applicati ons (Web farms). Again, none of their servlets or JSP pages have to be rewritten.If the project becomes quite large and complex, they might want
53、 to use En terprise JavaBea ns (EJB) to en capsulate their bus in ess logic. So, they might switch to BEA WebLogic or Oracle9i AS. Aga in, none of their servlets or JSP pages have to be rewritte n. Fin ally, if their project becomeseve n bigger, they might move it off of their Linux box and onto an
54、IBM main frame running IBM WebSphere. But once aga in, none of their servlets or JSP pages have to be rewritte n. 6. Secure One of the main sources of vulnerabilities in traditional CGI stems from the fact that the programs are ofte n executed by gen eral-purpose operat ing system shells. So, the CG
55、I programmer must be careful to filter out characters such as backquotes and semico Ions that are treated specially by the shell. Impleme nti ng this precauti on is harder tha n one might think, and weak nesses stemming from this problem are constantly being uncovered in widely used CGI libraries. A
56、 second source of problems is the fact that someCGI programs are processed by Ianguages that do not automatically check array or string bounds. For example, in C and C+ it is perfectly legal to allocate a 100-element array and then write into the 999th eleme nt, which is really some ran dom part of
57、program memory. So, programmers who forget to perform this check open up their system to deliberate or accide ntal buffer overflow attacks. Servlets suffer from neither of these problems. Even if a servlet executes a system call (e.g., with Runtime.exec or JNI) to invoke a program on the localoperat
58、ing system, it does not use a shell to do so. And, of course, array bounds check ing and other memory protecti on features are a cen tral part of the Java program ming Ian guage. 7. Mainstream There are a lot of good tech no logies out there. But if ven dors dont support them and developers dont kno
59、w how to use them, what good are they? Servlet and JSP tech no logy is supported by servers from Apache, Oracle, IBM, Sybase, BEA, Macromedia, Caucho, Sun/iPlanet,New Atlanta,ATG, Fujitsu, Lutris, Silverstream, the World Wide Web Con sortium (W3C), and ma ny others. Several low-cost plugi ns add sup
60、port to Microsoft IIS and Zeus as well. They run on Windows, Unix/Linux, MacOS,VMS,and IBM mainframe operating systems. They are the single most popular applicationof the Java programming Ianguage. They are arguably the most popular choice for developing medium to large Web applications. They are us
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
- 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
- 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 二零二五版?zhèn)€人二手車融資擔保合同3篇
- 2024渣車運輸與環(huán)保達標及工程驗收合同范本3篇
- 2024版游戲開發(fā)與內(nèi)容采購合同
- 個性化正規(guī)借款協(xié)議模板2024版版B版
- 2024消防安全隱患排查及整改服務合同3篇
- 2024版外貿(mào)領域業(yè)務信息保密合作合同版B版
- 消防工程節(jié)能施工方案
- 2025至2030年中國垂直循環(huán)停車設備數(shù)據(jù)監(jiān)測研究報告
- 2025至2030年中國廚用黃酒數(shù)據(jù)監(jiān)測研究報告
- 2025年中國電梯梳齒板市場調查研究報告
- 【傳媒大學】2024年新營銷
- 2025屆廣東省佛山市高三上學期普通高中教學質量檢測(一模)英語試卷(無答案)
- 自身免疫性腦炎課件
- 人力資源管理各崗位工作職責
- 信陽農(nóng)林學院《新媒體傳播學》2023-2024學年第一學期期末試卷
- 2024建筑公司年終工作總結(32篇)
- 2024年項目投資計劃書(三篇)
- 配電安規(guī)課件
- 瀝青路面施工安全培訓
- 機電設備安裝施工及驗收規(guī)范
- 倉庫安全培訓考試題及答案
評論
0/150
提交評論