可以給Servlet一個(gè)美好的定義：是使用Java Servlet應用程序接口及相關(guān)類(lèi)和方法的Java程序；
Servlet是由web服務(wù)器（輔助虛擬機）加載和執行的；Applet是虛擬機來(lái)干的；
Applet可以讓web瀏覽器顯示更復雜的用戶(hù)界面；
Servlet可以讓web服務(wù)器產(chǎn)生更復雜的..............;
Applet可以在任何支持Java的web瀏覽器上執行；
Servlet可以在任何支持Java的web服務(wù)器上執行；
”Servlet是一個(gè)類(lèi)“，靠，好一句話(huà)驚醒夢(mèng)中人也！不就是Applet一樣的家伙嘛！
但是Applet雖然產(chǎn)生于服務(wù)器端，卻是跑到客戶(hù)端載工作；
B/S：Browser/Server
需要說(shuō)明的是Servlet就是一種和CGI同樣功能的技術(shù)，就象J2EE和.NET的關(guān)系；
所有的Servlet都必須直接或者間接地實(shí)現javax.servlet.Servlet接口，才能在Servlet Engine上運行；
（多么象是在說(shuō)Applet呀?。?/p>
"HTTP是Servlet最常用的協(xié)議”它豈不是在說(shuō)Servlet還可以處理其他的應用協(xié)議；
service()方法的作用就是：
Receives standard HTTP requests from the public service method and dispatches
them to the doXXX methods defined in this class
所以你必須重寫(xiě)有可能用到的doXXX()方法；
但是它是根據什么來(lái)決定doXXX()的呢？？
回答如下：
service()將會(huì )得到一個(gè)ServletRequest的對象，該對象描述了客戶(hù)的html表單上的請求數據，
基于http協(xié)議，我們可以用ServletRequest的getXXX()方法得到這個(gè)表單上的數據，因為
有http協(xié)議作為標準嘛??！然后這個(gè)Servlet就獲得了用戶(hù)的信息，不就可以處理了；
也許你會(huì )問(wèn)：我可沒(méi)有調用service()來(lái)從html表單上把數據謄到servlet中；
放心，這個(gè)方法是有service container自己調用的，用戶(hù)既然通過(guò)這個(gè)容器服務(wù)器的端口請求
一個(gè)服務(wù)并且在這個(gè)請求中夾帶著(zhù)自己的請求信息，容器服務(wù)器能不響應嗎？？響應的時(shí)候
能不接受請求信息然后通過(guò)service傳給Servlet嗎？有http作為協(xié)議，容器能不理解這個(gè)請求
信息表達了一個(gè)什么事情嗎？？？
既然容器是用來(lái)調用service()的，那么可以知道以下servlet的功能都是
容器來(lái)完成的：
1：接受用戶(hù)的請求表單參數信息；通過(guò)傳給Servlet的ServletRequest對象。
2：為用戶(hù)產(chǎn)生一個(gè)表單返回；通過(guò)傳給Servlet的ServletResponse對象。
可見(jiàn)：Servlet確實(shí)只是處理數據；從用戶(hù)端接受數據以及給用戶(hù)發(fā)送數據都是容器的事情；
而Servlet只是從容器那拿數據來(lái)處理后又給容器結果，它可不關(guān)心對外交往的事情；
無(wú)論何時(shí)請求Servlet,引擎都會(huì )派生一個(gè)新的線(xiàn)程并執行servlet的service()方法；
service()方法判斷調用doXXX();實(shí)際上，doXXX()上我們用戶(hù)在html表單里指明了的；
當然如果我們沒(méi)有在html表單里指定應該doXXX()，或者我們直接在瀏覽器中請求servlet，
根本沒(méi)有指定該調用的方法，這時(shí)默認調用的是doGet()方法；
總之呢，一個(gè)Servlet類(lèi)負責把一個(gè)對html構造的串寫(xiě)到響應對象中，然后由容器負責勾勒出這個(gè)
響應對象所描述的html文件來(lái)；一般在Servlet類(lèi)中我們用一個(gè)PrintWriter來(lái)寫(xiě)很多html的標記通過(guò)
響應對象傳送給容器(并不是完全寫(xiě)完了后才可以傳送給容器的，響應對象只是傳輸線(xiàn)，而不是
傳輸車(chē)，即有一行發(fā)一行，不在傳輸線(xiàn)上逗留)，但是很麻煩，為了方便，你完全可以自己寫(xiě)一個(gè)html
類(lèi)；因為我們總是只需要將一個(gè)字符串描述的html標記組合給響應對象，所以我們可以用這個(gè)html
類(lèi)來(lái)返回整個(gè)html標記字符串，然后在Servlet類(lèi)中我們只需要一次簡(jiǎn)單的out.println(html.getPages())
就可以了；
Servlet肯定是要強調效率的，但是我們總是會(huì )new 出很多String或者StringBuffer對象來(lái)；
所以我們盡量不要用+或者直接用String對象，我們可以out.println一行串來(lái)描述整個(gè)html,
同時(shí)用StringBuffer.append()方法來(lái)連接字符串而不是+;
Servlet中的異常處理
異常有時(shí)候是個(gè)好的事情，因為我們可能自愿拋出異常以抵抗某種操作；
關(guān)于html標記的幾個(gè)小常識：<br>是一個(gè)換行符號！如果用<h1></h1>標記標起來(lái)的將回以
強調的字體并且單獨一行顯示；
異常錯誤代替return 語(yǔ)句的過(guò)程：
以前你如果想調用一個(gè)方法檢查某組數據是否有錯時(shí)會(huì )這樣做，讓這個(gè)方法
返回不同的值以代表數據正確與否；這樣你的主代碼中還需要用if來(lái)判斷
返回值以做出下一步動(dòng)作‘
而現在我們的方法是讓方法自己拋出異常而不是返回值，這樣主代碼中
只管處理這個(gè)異常就行了，這樣的代碼更健壯；
service方法拋出的異常自己不管，都拋給了引擎，如果發(fā)生異常，引擎會(huì )停止運行；
這就好像我們把底層的所有異常都逐級拋，直到JVM為止；
這里我們都逐級拋，知道引擎為止；
HTTP協(xié)議是無(wú)狀態(tài)的協(xié)議；
會(huì )話(huà)的作用
怎么說(shuō)這個(gè)東西呢？
有時(shí)候你的信息不是在一次請求中傳遞給servlet的，比如買(mǎi)書(shū)，你可能挑了
很多次，每挑一本就點(diǎn)擊了“提交”按鈕請求了一個(gè)servlet服務(wù);
而Http是無(wú)狀態(tài)的，當你挑好了下一本書(shū)，你上次點(diǎn)擊請求的servlet已經(jīng)結束
生命，所以新的請求將只會(huì )知道你當前挑的這本書(shū)而不知道你以前還挑過(guò)別的書(shū)，
會(huì )話(huà)(HttpSession)正是致力于解決這個(gè)問(wèn)題；
通過(guò)很多個(gè)Servlet實(shí)例共享同一個(gè)Session就可以保存這些信息了；
在這樣的應用中，Servlet為了正確處理數據，應該從Session對象里取數據，
而不是從Request取數據；因為從Request取出的數據只是本次瀏覽器提交的
信息，而從Session取出的數據則是這個(gè)Session對象的生命周期中瀏覽器
提交的所有信息；
重起Tomcat之后這個(gè)Session還可以起作用，但是重起瀏覽器后Session就沒(méi)了，
所以Session是客戶(hù)端的瀏覽器保存的而不是web服務(wù)器的，這句話(huà)對嗎？
Session對象不會(huì )自動(dòng)加上一些信息，必須用setAttribute()來(lái)維護Session
以保證它記錄了所有用戶(hù)請求信息；
對于原來(lái)以有的記錄項，新的加入將會(huì )更新；
對于原來(lái)沒(méi)有的記錄項，新的加入將會(huì )產(chǎn)生一個(gè)新的記錄項！
HttpSession.setMaxInactiveInterval(int interval)方法的疑問(wèn)：
這個(gè)時(shí)間從什么時(shí)候算起？？
ServletContext
大家也看到了，接口ServletSession沒(méi)有實(shí)現類(lèi)，說(shuō)明你根本沒(méi)辦法實(shí)例一個(gè)HttpSession;
而只能通過(guò)HttpRequest的getSession()方法來(lái)得到，這說(shuō)明一個(gè)Session只對應于一個(gè)HttpRequest,
也就是說(shuō)，它只提供對同一個(gè)Servlet的同一個(gè)HttpRequest的多次請求的共享，而不能提供不同的
Servlet的HttpRequest之間的共享；
注意：Servlet引擎通過(guò)URI來(lái)標識和配置了多個(gè)Servlet環(huán)境；這個(gè)URI就在web.xml文件里；
這個(gè)映射并不是用路徑名來(lái)做的，有什么好處呢？
一般的映射名稱(chēng)可以十分簡(jiǎn)略，因為它可以略掉實(shí)現類(lèi)的包名，實(shí)際上它完全與
實(shí)現類(lèi)的名字無(wú)關(guān)，短名稱(chēng)使得對Servlet的引用更容易，并且更容易更換servlet
的實(shí)現類(lèi)而不改變應用對servlet的引用；
如果用路徑和完整類(lèi)名，至少應用中的對servlet的引用必須老是換；
目前為止，你的應用指的就是你給用戶(hù)的用來(lái)請求的html文件；
映射名保證了當servlet更換的時(shí)候,html文件不需要更改；
MIME
MIME就是"多用途的因特網(wǎng)郵件擴充業(yè)務(wù)"來(lái)的,最初被開(kāi)發(fā)成允許包含非ASCII信息的E-MAIL信息.
HTTP很依賴(lài)于MIME.每個(gè)傳送到某個(gè)客戶(hù)端瀏覽器的文件都由一個(gè)MIME數據頭開(kāi)始,
http協(xié)議也使用mine,瀏覽器一般是根據服務(wù)器返回的mine type決定文件類(lèi)型.
或許你看到這句話(huà)就明白了
1,response.setContentType("text/html;charset=gb2312");
2,
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<title>無(wú)標題文檔</title>
</head>
在Content-Type響應標頭中指定了HTTP數據的內容類(lèi)型；
如果沒(méi)有指定，則會(huì )默認為"text/html";
可以在一個(gè)http請求中提供一張可接受的內容類(lèi)型表：
Accept:image/gif,image/jpeg,image/pjpeg,*/*
一個(gè)Content type是形式為type/sub-type的字符串：
image/jpeg:
是漸進(jìn)的；
image/gif:
是交錯的；
..............
Response.getWriter()得到一個(gè)PrintSwriter只能給瀏覽器傳送text類(lèi)型的字符數據，
如果是二進(jìn)制數據則需要Response.getOutputStream();
servlet不能打開(kāi)窗口，取而代之的是，它可以創(chuàng )建屏幕上不顯示的圖像，就象雙緩沖技區創(chuàng )建不顯示
的圖像一樣；
servlet發(fā)送圖像給web瀏覽器的步驟和原理是這樣的：
為了得到一個(gè)Image對象，必須有一個(gè)組件，通過(guò)這個(gè)組件獲得它，因為你知道
Image是個(gè)抽象類(lèi)，是受保護的不可以直接得到的保護類(lèi)，如Graphics一樣；
所以可以先new Component()得到一個(gè)Component;
然后用這個(gè)Component.addNotify() 連接在主機平臺上的AWT工具集上；
然后就可以createImage();
然后傳遞這個(gè)Image給編碼類(lèi)，編碼到Response.getOutputStream()得到的
指向web瀏覽器的輸出流上；
必須將ContentType設置為image/sub-type，不然瀏覽器還是不認識；
注意：Response除了getWriter,getResponse得到輸出流寫(xiě)到響應對象之外，還可以setXXX等為將要
發(fā)送給客戶(hù)的響應對象設置內容，比如頭，等東西；
對于Servlet 這種模式你現在應該有所體會(huì )：
無(wú)論用戶(hù)要什么信息，需要什么處理，需要什么數據結構，需要什么對象，
你都不可以把這些東西放到或者傳送到瀏覽器端去；
也就是說(shuō)，出了傳送Content Tpye 規定的數據給瀏覽器顯示之外，瀏覽器不擁有
任何處理邏輯哪怕是為了顯示而做的處理邏輯；瀏覽器端更本就沒(méi)有顯而易見(jiàn)的
Java程序；
Color的兩種表示法：
1，RGB,紅，綠，藍
2, HSB，色調，飽和度，亮度
可以用Color.HSBtoRGB和Color.RGBtoHSB來(lái)實(shí)現兩者的轉換；
CSDN關(guān)于float的回答：
帶小數的常值都會(huì )被認為是 double 型的，就像整型的常值都會(huì ) 被認為是 int 型的一樣。
你可以這樣
float x = 0.01f;
也就是加個(gè) f 后綴就行了。
繼續關(guān)于html和服務(wù)器端的交互
html中，一個(gè)表單form中，每個(gè)表單元素都有一個(gè)唯一的名字和值；
當用戶(hù)按下submit按鈕的時(shí)候，
表單數據就被打包作為請求發(fā)送給
html中的<form>標簽指定的服務(wù)器端的腳本或者說(shuō)
是指定的用來(lái)處理的特定的CGI或者S特定的ervlet等；
好像有這么一個(gè)道理：.html文件里顯示的文件不一定是text/html類(lèi)型的數據，
數據類(lèi)型和文件類(lèi)型完全是兩回事；
Web服務(wù)器通過(guò)URL來(lái)與Servlet聯(lián)系，所以說(shuō)URL雖然是用戶(hù)給的....;
Servlet模型中，為每個(gè)URL僅創(chuàng )建一個(gè)對象
任何客戶(hù)每次訪(fǎng)問(wèn)服務(wù)器上的那個(gè)URL時(shí)，都調用同一個(gè)Servlet對象的service()方法；
這其實(shí)說(shuō)明了什么呢？說(shuō)明對一個(gè)URL多次請求都只對應用相同的一個(gè)Servlet對象來(lái)處理；
Tomcat啟動(dòng)的時(shí)候并沒(méi)有加載所有的servlet,而是做了一個(gè)什么動(dòng)作；
當第一次請求發(fā)生時(shí)，Tomcat調用了init()方法；
Servlet的一些類(lèi)和方法的說(shuō)明
如果你的servlet類(lèi)只是繼承了GenericServlet的話(huà)，就不要寫(xiě)doXXX()一類(lèi)的方法，因為
這個(gè)類(lèi)并不是針對http協(xié)議的，所以它根本就不認識什么get,post請求，與此同時(shí)，它也就
沒(méi)有這些方法，反正都會(huì )調用service()方法，你就實(shí)現這個(gè)方法就行了；
對繼承HttpServlet的類(lèi)來(lái)說(shuō)，要么實(shí)現service()方法，自己決定doXXX()方法，要么不寫(xiě)service()方法
讓它自己分配去；但是如果兩者不一致，那會(huì )怎么樣？比如當我的html請求里是get請求，但是在我的
servlet類(lèi)中卻是調用了doPost()方法，這時(shí)候tomcat就會(huì )發(fā)生異常：
The specified HTTP method is not allowed for the requested resource (HTTP method GET is not supported by this URL).
對于http風(fēng)格的Servlet 來(lái)說(shuō)，內容類(lèi)型在http響應中返回給客戶(hù)，而輸出流和書(shū)寫(xiě)器在HTML體中
返回數據；
你必須明確，getServletContext()是從接口ServletConfig繼承而不是Servlet;
關(guān)于部署
WEB-INF結點(diǎn)不是應用程序的公共文檔樹(shù)的一部分，在這個(gè)目錄中的文件不能直接為客戶(hù)服務(wù)；
如果想要服務(wù)器啟動(dòng)的時(shí)候就加載一個(gè)Servlet,只要在web.xml部署中
寫(xiě)<load-on-startup>就行了，具體待看： <load-on-startup>4</load-on-startup>
對于ServletRequest中的getParameter()和getReader()方法不能混用；
你也不能太死板了！在只繼承GenericServlet的Servlet不寫(xiě)doXXX()方法是因為它沒(méi)有這個(gè)請求方法的
約束；而另一方面又說(shuō)在繼承了HttpServlet的Servlet里應該實(shí)現doXXX()方法，你就以為這必須做；
實(shí)際上也可以不寫(xiě)doXXX()方法，因為引擎調用的是默認的service()方法，如果你直接重寫(xiě)service()方法，
那你的sercice()方法完全可以不調用doXXX()方法而自己做所有的事情不就完了嗎？
注意，要牢牢記住的是：Servlet通過(guò)ServletRequest和ServletResponse所做的是：
得到http報文和構造http報文而不是你以前所理解的
得到html表單和構造html；Servlet針對的是http而不是html;
HttpSession會(huì )話(huà)的進(jìn)一步學(xué)習
可以這樣描述會(huì )話(huà)的功能：會(huì )話(huà)跟蹤機制允許把任意對象通過(guò)會(huì )話(huà)關(guān)聯(lián)起來(lái)。
其實(shí)會(huì )話(huà)就是一個(gè)駐在內存中的ID；
會(huì )話(huà)只是針對無(wú)狀態(tài)的Http而言存在的，所以必須是在HttpServlet里談?wù)摃?huì )話(huà)；
HttpSession是從HttpRequest得到的，所以一個(gè)會(huì )話(huà) 對應一個(gè)HttpRequest而不是一個(gè)HttpServlet；
更確切的說(shuō)，一個(gè)會(huì )話(huà)對應著(zhù)一個(gè)Html表單里的一個(gè)Form標簽的一個(gè)action動(dòng)作，當然這只是我個(gè)人的
猜測；
一個(gè)會(huì )話(huà)中的值都是對象！在web服務(wù)器上，因為我們或許會(huì )想要存儲會(huì )話(huà)記錄的某些對象，
所以使這些對象可串行化是很重要的；
會(huì )話(huà)保存什么樣的對象是手動(dòng)維護的；并不是你想像的會(huì )話(huà)會(huì )自動(dòng)保存來(lái)自客戶(hù)端的請求對象，
事實(shí)上，客戶(hù)的請求信息未必是對象；所以會(huì )話(huà)是非常依賴(lài)人工的；
Session里的對象是按照name(String)---value(Object)來(lái)存儲，檢索的；
Cookie的學(xué)習
Cookie也是從HttpRequest得到的；而且可以一個(gè)HttpRequest可以得到多個(gè)Cookie；
cookie必須是Http頭的一部分；
多線(xiàn)程Servlet
啊，一切都是在變化和不斷的廣泛化！
我們已經(jīng)不是象以前那樣認為線(xiàn)程共享的是變量，對象等內存中的東西；
而是文件，數據庫連接等東西了；
聯(lián)系客服
