❶ httplook怎麼使用，找不到輸入url的地方，好像也不能自動監聽瀏覽器啊
一個術語屆
在我的經驗，會話字可能是僅次於濫用交易的程度，更有趣的是，在某些意義上是相同的會話的事務上下文。
會話，中文經常翻譯成一個會話，其本義是指有始有終的一系列動作/消息，比如拿起電話撥打一個電話掛斷時要調用的在中間的一系列的流程，可以稱為會話。有時候，我們可以看到的話「在一個瀏覽器會話中，...」，其中的談話是其本義使用的術語，是衡量一個瀏覽器窗口打開到關閉這個期間，E。最令人困惑的是「用戶（客戶端）在會話過程中，」的話，它可能指用戶的一系列動作（正常情況下是與一系列具體行動的目的，如購買商品登錄這樣的網上購物結帳注銷過程中，有時簡稱為交易），但有時也可能僅僅是指一個連接，有可能是指的意思，E，差異只能靠上下文來推斷，E° 。
但是，當會話詞是與網路協議，它也往往意味著「面向連接」和/或「持有」，這兩個含義，「面向連接」指的是通信雙方在通信之前，先來建立溝通的渠道，如電話，直到對方接到一個電話通信才能開始，與此相對的是一個字母，把信送給你，當你不能確認地址是否正確的對方，可能無法建立溝通渠道，但發件人，通信已經開始了。 「保留」是指黨能夠溝通了一系列的消息關聯的消息之間可以互相依賴，例如，一個服務員可以識別老客戶前來再次記得上一次的客戶還欠一塊錢存儲。 「一個TCP會話」或「POP3會話」，E￠這種類型的例子。
到web伺服器蓬勃發展的時代，會話上下文中的語義Web開發有一個新的擴展，它的含義是指用來保持溶液狀態的客戶端和伺服器之間的一類，E￡ 。有時會話也用來指到該溶液中的存儲結構，如「儲存在一個會話中，其中xxx」，§。由於給各種語言的Web開發在一定程度上提供了這種解決方案的支持，所以在一個特定的語言的上下文中，會話也被用來指語言解決方案，如定期提供在java javax.servlet.http.HttpSession稱為會話，E。
鑒於這種混亂已不可改變的，這在會話中使用的術語將根據上下文有不同的含義，請注意區分。
在本文中，使用中國的「瀏覽器會話」表達的意思，E，使用「session機制」，要表達的意思，英鎊，使用「會話」表達的意思，E「，使用特定的「的HttpSession的」要表達的意思，E
二，HTTP協議和國家仍然
HTTP協議本身是無狀態的HTTP協議，它與原來的目的是一致的，客戶端只需要一個簡單的請求到伺服器下載某些文件，無論是客戶端或伺服器記錄彼此的行為，在過去是沒有必要的，每次請求之間是獨立的，像一個客戶和一個自動售貨機或正常（非成員），如超市之間的關系。
但是，聰明的（或貪婪？），人們很快發現，如果我們能夠提供一些需求的網頁上生成的動態信息將變得更加有用，像有線電視加上點播功能相同。這種需求一方面迫使逐步添加HTML表單，腳本，DOM和其他客戶端的行為，其他伺服器側出現了CGI規范的動態響應客戶端的請求，作為傳輸載體的HTTP協議也添加一個文件上傳，這些功能的cookie。 Cookie是解決無狀態的HTTP協議中的缺陷的努力的作用。至於後來出現的會話機制又是一個客戶端和伺服器之間保持狀態的解決方案。
讓我們來看看幾個例子來說明會話cookie和機制之間的差異和相似之處。我曾經常去的一家咖啡店，免費贈品喝五杯咖啡，一杯咖啡的優惠，然而，消費5杯咖啡的機會不大，那麼你需要一些方式來記錄消費一定數量的客戶。試想一下，其實沒什麼低於以下幾種選擇：
1，店員是非常強大的，能夠記住每個顧客的消費，只要顧客一走進咖啡店，店員會知道如何對待。支持這種做法的協議本身規定。
2，給客戶一張卡，記錄消費金額，是一個普遍的有效性。每一個消費者，如果顧客出示這張卡，你將之前或之後與消費者的消費聯系在一起。這種方法是在客戶端保持狀態。
3，給顧客一張會員卡，除了卡號信息沒有記錄超出每個消費者，如果客戶生產出的卡，然後店員在店裡找到相應的卡號記錄記錄添加一些消費者信息。這種做法是在伺服器端保持狀態。
由於HTTP協議是無狀態的，但出於種種考慮不想成為一個國家，因此，後兩種方案已成為一個現實的選擇。具體而言，cookie機制用於保持狀態的客戶端程序，並且會話的機制是用來保持的狀態的伺服器端解決方案。我們也看到，利用伺服器端程序在客戶端保持狀態也需要保存一個標識，所以會話cookie機制可能需要的幫助機制，以實現節能的目的確定，但實際上它還有其他選項。
三，理解cookie機制
的cookie機制的基本原理是一樣的，在上面的例子很簡單，但有幾個問題要解決：「會員卡」如何分發;會員卡「的內容，以及客戶如何使用」會員卡「。
正統的cookie分發是通過擴展HTTP協議，伺服器通過HTTP響應頭一排，添加特殊說明，按照說明進行操作提示瀏覽器將生成相應的cookie。然而，純粹的客戶端腳本如JavaScript或VBScript也可以生成cookie中。
使用cookie是由瀏覽器按照一定的原則在後台自動發送到伺服器。瀏覽器檢查所有存儲的cookie，如果聲明一個cookie范圍大於或等於所請求的資源，把附在請求資源的HTTP請求發送到伺服器的頭的cookie。意思是麥當勞的會員卡只能在麥當勞的店裡出示，如果一個商店也發行了自己的會員卡，然後進店除了麥當勞的會員卡到現在的時間，而且還產生一個成員的存儲卡。
的cookie內容包括：名字，值，過期，路徑和域。
在那裡你可以指定一個特定的領域，如域。 google.com，相當於總店招牌，比如寶潔公司（Procter＆Gamble），你也可以指定一個特定的領域，如機器或froogle.google.com，您可以用飄柔做比。
如下的URL路徑的路徑後，該域名，比如/或者/ foo的等，可以做一定比例飄柔專櫃。
路徑和域共同構成的cookie的范圍。
如果不設置過期時間，然後為瀏覽器會話cookie的壽命，只要關閉瀏覽器窗口，cookie的消失。這一時期的生活的瀏覽器會話cookie被稱為會話cookie。會話cookie一般不存儲在硬碟上，但存儲在內存中，當然，這種行為是不是規范。如果你設置的過期時間，瀏覽器cookie保存到硬碟驅動器，打開瀏覽器後，再次關閉這些cookie仍然有效，直到過期時間超過設定。
存儲在硬碟上的Cookie在不同的瀏覽器，可以在進程間共享，比如兩個IE窗口。並存儲在內存中的cookie，不同的瀏覽器有不同的方法。對於IE瀏覽器，在打開的窗口中，按Ctrl-N（或者從文件菜單）打開的窗口可以與原窗口共享，而使用其他方式來打開IE進程不會共享內存窗口已經打開餅干;對於Mozilla Firefox0.8中，所有的流程和標簽可以共享相同的cookie。一般用javascript的window.open打開的窗口與原窗口共享內存cookie。只認cookie的瀏覽器會話cookie不承認這樣的人造成了很大的困擾，使用常規的網路應用程序開發人員的會話處理機制。
這里是GOOLGE集一個cookie的響應頭的例子
HTTP/1.1 302找到
位置：
的Set-Cookie：PREF = ID = 0565f77e132de138：凈重= 1 ：TM = 1098082649：LM = 1098082649：S = KaeaCFPo49RiA_d8到期=星期日，1月17日 - 2038年19時14分07秒GMT;路徑= /;域=。 google.com
的Content-Type：text / html類型
這是使用HTTPLook這個HTTP Sniffer軟體捕獲記錄的一部分，HTTP通信
瀏覽器再次訪問GOOLGE自動送出當資源的cookie
使用Firefox可以很容易地觀察現有的cookie值，
請使用HTTPLook Firefox可以很容易理解的cookie工程。
IE也可以設置在詢價之前接受cookie
這是一個對話框，要求接受Cookie。
四，理解機制
會話的會話機制是一種機制，為伺服器，伺服器使用一個哈希表狀結構（也可能是使用一個哈希表）來保存信息。
當程序需要為客戶端請求創建一個會話時，伺服器首先檢查客戶端的請求已被列入會話標識符 - 所謂的會話ID，如果已包含一個session id，然後在客戶端有先前已創建伺服器會話的會話ID將主持本屆會議，檢索使用（如果沒有檢索到，它可以創建一個），如果客戶端請求不包含會話ID，然後為這個客戶端創建一個會話，並生成一個會話這個會話ID，會話ID值應該既不是重復的，不容易找到規律復制字元串，這個session id將返回響應這個客戶端保存。
這種方式可以使用會話cookie保存，以便根據規則把這個標識伺服器的一個互動的過程中瀏覽器可以自動播放。一般來說，cookie的名稱是類似SEEESIONID的。對於Web應用程序生成的cookie如WebLogic，JSESSIONID = ！ -145788764，它的名字是JSESSIONID。
由於cookie可以被人為的禁止，必須有其他的機制被禁止的cookie會話ID仍然能夠回傳給伺服器。經常使用的一種技術叫做URL重寫，會話ID被附加到URL路徑直接背後，還有另外兩種方法，一種是在JSESSIONID = 的形式，為更多的信息，表現的URL路徑！ -145788764
另一種是作為查詢字元串附加到URL後面的表現！ -145788764
這兩種方式為用戶沒有任何區別，只有伺服器解析不同的方式處理時，第一種方法是會話ID信息也有利於區分正常程序參數。
整個交互過程中，為了始終保持狀態，就必須要求每個客戶端後路徑可能包含會話ID。
另一種技術稱為隱藏的表單欄位。是伺服器會自動表單，添加一個隱藏欄位，這樣，當表單被提交到這個session id傳遞回伺服器。例如，下面的表格
被傳遞到客戶端之前被改寫
現在已很少使用這種技術，我談到一個非常古老的iPlanet6（SUNONE應用伺服器的前身）上使用這種技術。
其實，這種技術可以應用，只需使用URL重寫的行動，而不是。
談論的會話機制，我經常聽到這樣的誤會「，只要在瀏覽器關閉，會話就消失了。」事實上，想像例子會員卡除非客戶作出商店賣卡，否則店裡會不會輕易刪除客戶數據。同樣是真實的會話，除非程序通知伺服器刪除會話，否則伺服器將仍然存在，程序通常都是在用戶注銷時發出命令刪除會話。然而，瀏覽器從來不會主動關閉之前通知伺服器將被關閉，伺服器將不會有機會知道瀏覽器已經關閉，之所以有這樣的誤解最多的一屆機制使用會話cookie來存儲會話ID，會話ID消失後關閉瀏覽器，它不能連接到伺服器，再找到原來的session。如果伺服器設置的cookie存儲在您的硬碟上，或者使用某種手段改寫瀏覽器發送一個HTTP請求頭，原來的session id發送到伺服器，然後重新打開瀏覽器仍然能夠找到原來的會話。
正是因為瀏覽器被關閉，並不導致會話被刪除，迫使伺服器SEESION設立了故障時間，當距離客戶端上使用，盤中一度時間超過屆滿時間，伺服器，客戶端已停止其活動，該會話將被刪除以節省存儲空間。
五，理解javax.servlet.http.HttpSession
HttpSession會話的機制是Java平台的實施規范，因為它是唯一的，具體到每一個Web應用程序伺服器提供商的介面，除了規范的支持，仍然會有一些規范未指定的細微差別。在這里，我們與BEA公司的Weblogic Server8.1作為例子來演示。
第一，WebLogic Server提供的一組參數來控制它的HttpSession實現，包括使用cookie的開關選項，使用URL重寫的開關選項，會話持久性設置，會話過期時間設置，並為各種cookie的設置，比如設置cookie的名稱，路徑，域，cookie的生存時間。
當伺服器進程停止或重新啟動，正常情況下，將被保存在內存中，內存的會議將被清除，如果你將它設置為會話持久性功能，將伺服器會話保存到您的硬碟驅動器，當伺服器進程重新啟動或信息將能夠被再次使用時，WebLogic Server支持持久的方法，包括文件，資料庫，客戶端cookie保存和繁殖。
持續復制是沒有嚴格保持，因為會話實際上是存儲在內存中，但同樣的信息被復制到每個集群內的伺服器進程，這樣即使伺服器進程停止工作能在這個過程中仍然可以實現從其他會話。
cookie設置會影響生成的cookie，如果瀏覽器是一個會話cookie的生存時間。默認是使用會話cookie。有興趣的人士可以用它來測試在第四季度，我們提到的那個誤解。
Cookie路徑的Web應用程序是一個非常重要的選項，此選項的默認處理，使得它有著明顯的區別與其他伺服器Weblogic伺服器。稍後我們將討論的話題。
會話設置參考[5]
六，HttpSession中常見問題
（本條所指的混合會話，E§ E）
1，創建會話時
一個常見的誤解是，在客戶端的會話訪問，當它被創建，但事實是，直到伺服器端程序調用HttpServletRequest的。 getSession（）這樣的語句只被創建，注意不顯示，如果使用JSP 閉門會議中，JSP文件被編譯成Servlet會自動添加這樣的語句的HttpSession會話= HttpServletRequest.getSession（真），這是JSP隱式會話對象的原點。
因為會話會消耗內存資源，因此，如果你不打算使用會話，所有的JSP應該把它關閉。
綜合前面的討論，都將被刪除2，會話，會話在下列情況下被刪除。程序調用HttpSession.invalidate（）令;或b。從最後客戶收到發送的session id時間間隔超過會話超時設置，或c。伺服器進程被停止（非持久性會議）
3，如何做到在瀏覽器關閉時刪除會話
嚴格地說，這是不可能的。你可以做一點努力接近客戶的所有頁面使用javascript代碼window.oncolose的監視瀏覽器的關閉動作，然後向伺服器發送一個請求刪除會話。但是，瀏覽器崩潰或強制殺進程仍然無能為力這些非常規手段。
4，有
，HttpSessionListener補償是如何創建這樣的監聽監視會話的創建和銷毀事件，發生這樣的事件，你可以做一些相應的工作。請注意，創建和銷毀的會話或動作觸發的監聽器，而不是相反。類似的HttpSession中伴有以及HttpSessionBindingListener介面，的HttpSessionActivationListener HttpSessionAttributeListener的聽者。
5，存儲在會話對象必須是可序列化
不是必需的。需要對象可以序列化會話，只是為了能夠在集群中被復制，或者可以堅持，在必要的情況下，會話伺服器可以暫時換出內存。在WebLogic Server控制台上放置一個非序列化對象的會話將收到一個警告。我用過的iPlanet版本如果會話已經沒有序列化的對象在會話中有將是一個例外破壞，很奇怪。
6，如何正確處理與客戶端的可能性禁止餅干
所有的URL使用URL重寫，包括超鏈接，form的action，和重定向URL，具體做法參見[6
7，打開兩個瀏覽器窗口訪問應用程序將使用同一時段或不同的會話
見第三部分討論的cookie，會話ID只認不認人，因此不同瀏覽器，不同的窗口開放和不同的cookie將被存儲在受影響這個問題的答案。
8，如何防止用戶打開兩個瀏覽器窗口操作導致會話混亂
防止多次提交的問題是類似的形式，你可以設置客戶端的令牌來解決。也就是說，伺服器每次生成一個不同的ID返回給客戶端，同時保存在會話中，客戶端提交表單時，必須返回到伺服器也是這個id，程序首先比較返回的id的值存儲在會話是相同的，如果不一致，在此操作中所示前已經提交。可以發現在「J2EE核心模式」表示層模式的部分。需要注意的是，使用的javascript的window.open打開的窗口，一般不設置這個id，或者使用一個單獨的ID，無法操作，以防止在主窗口，建議不要做window.open打開的窗口操作，這樣就可以不設置。
9，為什麼做這個動作的目的主要是為集群環境中提示Weblogic伺服器會話發生在在Weblogic伺服器改變會話的價值後，重新調用一次session.setValue
值的變化，你需要復制到其他伺服器進程的價值，新的會話。
10，為什麼會話了
排除會話正常的故障因素，伺服器本身的可能性應該是微乎其微，雖然筆者iPlanet6SP1的加若干補丁Solaris版本是相當遇到;通過瀏覽器插件的可能性，我也遇到過3721插件造成的問題;理論上防火牆或者代理伺服器在cookie處理也可能會造成問題。
發生，主要是因為這個問題是程序的錯誤，最常見的是在應用程序中訪問另一個應用程序。在下一節中，我們將討論這個問題。
七，跨應用程序的會話共享
這是通常的情況下，一個大型開發項目劃分成若干小項目，為了能夠干擾對方，要求每個小項目作為一個單獨的Web應用程序開發中，但在最後突然發現了幾個小項目需要之間共享一些信息，或者想使用session來實現SSO（單點登錄），存儲在會話登錄用戶信息，最自然的要求是應用程序之間互相訪問對方的會話。
但是，按照Servlet規范，會話的范圍應僅限於當前的應用程序，不同的應用程序之間是不能夠訪問每個會話。從實際的效果是每個應用伺服器在遵守本規范，但其執行細節可能會有所不同，因此解決跨應用程序的會話共享方法也是不同的。
先看看Tomcat的Web應用程序是如何實現會話之間的隔離，從Tomcat視圖設置cookie路徑，其不同的應用程序設置的cookie路徑是不同的，所以不同的應用程序所用的session id是不同的，即使在同一個瀏覽器窗口訪問不同的應用程序，發送到伺服器的會話ID可以是不同的。
根據這一特點，我們可以在會話推測Tomcat的內存結構如下。
我用過的iPlanet也採用同樣的方式，估計SUNONE和iPlanet沒有太大的區別。對於這樣的伺服器，解決方案是非常簡單的想法，它的實際執行情況並不難。要麼讓所有的應用程序共享一個session id，或者讓應用程序能夠獲得其他應用程序會話ID。
的iPlanet是一個非常簡單的方式來實現共享一個session id，那就是每個應用程序的cookie路徑都設為/（實際上應該是/ NASApp的，在其行為中的應用為根）。
</路徑/ NASApp >
注操作共享會議應該遵循一些編程約定，如在會話屬性名稱前面的應用程序的前綴，使的setAttribute（「名稱」，「新」）成為的setAttribute（的「app1.name」，「新」）中，為了防止命名空間沖突，領導互相覆蓋。
在Tomcat中是不太方便的選擇。在Tomcat版本3中，我們還可以有一些手段來共享會話。對於版本4以上的Tomcat，現在我還沒有找到一個簡單的解決方案。只能藉助於第三方的力量，比如使用文件，資料庫，JMS或者客戶端cookie，URL參數或者隱藏欄位等手段。
讓我們來看看如何處理與WebLogic Server是會話。
從截圖可以看到WebLogic Server應用程序設置的cookie路徑為/，這是不是意味著在默認情況下，WebLogic伺服器可以共享會話它？然而，一個小實驗證明，即使不同的應用程序使用同一個會話，每個應用程序仍然只能訪問自己設置這些屬性。這表明，本次會議的WebLogic Server的內存結構可能看起來
對於這樣的結構，機制本身的會話共享解決問題的會議應該是不可能的。另外電源通過一個第三個政黨，比如使用文件，資料庫，JMS或者客戶端cookie，URL參數或者隱藏欄位和其他手段，以及更方便的方式，就是以把一個應用程序的會話ServletContext的，所以從ServletContext的引用到應用程序之前，另一個應用程序可以通過以下方式獲得。示例代碼如下
應用á
context.setAttribute（「阿帕」，會話）;
應用程序B，
contextA =上下文。的getContext（「/ APPA」）;
HttpSession中sessionA =（HttpSession中）contextA.getAttribute（APPA）;
值得注意的是，這種用法是不可移植的，因為根據ServletContext的的JavaDoc，應用伺服器可以在出於安全原因context.getContext（「/ APPA」）;返回一個空值，通過上述方法在WebLogic Server 8.1。
那麼，為什麼要所有的WebLogic Server應用程序設置的cookie路徑/？正是在SSO，誰分享了本次會議的應用程序可以共享認證信息。一個簡單的實驗可以證明這一點，第一個日誌，應用程序描述符weblogic.xml，cookie路徑是/ APPA訪問的另一個應用程序的要求重新登錄，甚至如果反過來，先訪問cookie路徑為/應用程序，然後訪問的路徑，雖然不再提示登錄，但注冊用戶的信息將會丟失。請注意，這個實驗驗證表單時，應使用基本身份驗證方法其他的方式來處理第二個請求認證，因為瀏覽器和Web伺服器沒有達到通過會話。具體見文獻[7] 14.8 secion授權，你可以所附的示常式序來做這些測試。
八，總結
session機制本身並不復雜，但其實施和配置靈活性的具體情況復雜。它還需要，我們可以不只是一個第一次的經驗或者某一個瀏覽器，伺服器的經驗作為普遍的經驗，但總是需要具體情況具體分析。
❷ 怎麼判斷用戶非法退出，比如用戶關閉了瀏覽器，我怎麼能夠知道用戶退出了
有個監聽類，可以監控session失效，比如超過設置的時間沒有操作，關閉瀏覽器後
因為http協議是無狀態的，客戶端關瀏覽器 伺服器端是不知道的。
javax.servlet.http.HttpSessionBindingListener;
寫一個類繼承這個介面，這個介面提供2個抽象方法，它會再session創建和失效的時候自動運行
valueBound()
valueUnbound()
在這個類裡面可以操作session 和application
❸ 記住密碼的原理是什麼
應該是保存在Cookie里，session是放在伺服器的內存里的。在用戶關閉了網頁窗口後，session就清空了。而Cookie是保存在用戶的IE臨時文件夾中的，再次登錄時，讀取其中的值傳給伺服器。
session是放在伺服器的內存，Cookie是保存在用戶端。以下是從網上搜到的相關內容，希望對你有用：
一、cookie機制和session機制的區別
*************************************************************************************
具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。
同時我們也看到，由於才伺服器端保持狀態的方案在客戶端也需要保存一個標識，所以session
機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上還有其他選擇
*************************************************************************************
二、會話cookie和持久cookie的區別
*************************************************************************************
如果不設置過期時間，則表示這個cookie生命周期為瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期為瀏覽會話期的cookie被稱為會話cookie。會話cookie一般不保存在硬碟上而是保存在內存里。
如果設置了過期時間，瀏覽器就會把cookie保存到硬碟上，關閉後再次打開瀏覽器，這些cookie依然有效直到超過設定的過期時間。
存儲在硬碟上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存的cookie，不同的瀏覽器有不同的處理方式。
*************************************************************************************
三、如何利用實現自動登錄
*************************************************************************************
當用戶在某個網站注冊後，就會收到一個惟一用戶ID的cookie。客戶後來重新連接時，這個
用戶ID會自動返回，伺服器對它進行檢查，確定它是否為注冊用戶且選擇了自動登錄，從而使用戶務需給出明確的用戶名和密碼，就可以訪問伺服器上的資源。
*************************************************************************************
四、如何根據用戶的愛好定製站點
*************************************************************************************
網站可以使用cookie記錄用戶的意願。對於簡單的設置，網站可以直接將頁面的設置存儲在cookie中完成定製。然而對於更復雜的定製，網站只需僅將一個惟一的標識符發送給用戶，由伺服器端的資料庫存儲每個標識符對應的頁面設置。
*************************************************************************************
五、cookie的發送
*************************************************************************************
1.創建Cookie對象
2.設置最大時效
3.將Cookie放入到HTTP響應報頭
如果你創建了一個cookie，並將他發送到瀏覽器，默認情況下它是一個會話級別的cookie:存儲在瀏覽器的內存中，用戶退出瀏覽器之後被刪除。如果你希望瀏覽器將該cookie存儲在磁碟上，則
需要使用maxAge，並給出一個以秒為單位的時間。將最大時效設為0則是命令瀏覽器刪除該cookie。
發送cookie需要使用HttpServletResponse的addCookie方法，將cookie插入到一個Set-Cookie HTTP請求報頭中。由於這個方法並不修改任何之前指定的Set-Cookie報頭，而是創建新的報頭，因此我們將這個方法稱為是addCookie，而非setCookie。同樣要記住響應報頭必須在任何文檔內容發送到客戶端之前設置。
六、cookie的讀取
*************************************************************************************
1.調用request.getCookie
要獲取有瀏覽器發送來的cookie，需要調用HttpServletRequest的getCookies方法，這個調用返回Cookie對象的數組，對應由HTTP請求中Cookie報頭輸入的值。
2.對數組進行循環，調用每個cookie的getName方法，直到找到感興趣的cookie為止
cookie與你的主機(域)相關，而非你的servlet或JSP頁面。因而，盡管你的servlet可能只發送了單個cookie，你也可能會得到許多不相關的cookie。
例如：
String cookieName = 「userID」;
Cookie cookies[] = request.getCookies();
if (cookies!=null){
for(int i=0;i<cookies.length;i++){
Cookie cookie = cookies[i];
if (cookieName.equals(cookie.getName())){
doSomethingWith(cookie.getValue());
}
}
}
*************************************************************************************
七、如何使用cookie檢測初訪者
*************************************************************************************
A.調用HttpServletRequest.getCookies()獲取Cookie數組
B.在循環中檢索指定名字的cookie是否存在以及對應的值是否正確
C.如果是則退出循環並設置區別標識
D.根據區別標識判斷用戶是否為初訪者從而進行不同的操作
*************************************************************************************
八、使用cookie檢測初訪者的常見錯誤
*************************************************************************************
不能僅僅因為cookie數組中不存在在特定的數據項就認為用戶是個初訪者。如果cookie數組為null，客戶可能是一個初訪者，也可能是由於用戶將cookie刪除或禁用造成的結果。
但是，如果數組非null,也不過是顯示客戶曾經到過你的網站或域，並不能說明他們曾經訪問過你的servlet。其它servlet、JSP頁面以及非Java Web應用都可以設置cookie，依據路徑的設置，其中的任何cookie都有可能返回給用戶的瀏覽器。
正確的做法是判斷cookie數組是否為空且是否存在指定的Cookie對象且值正確。
*************************************************************************************
九、使用cookie屬性的注意問題
*************************************************************************************
屬性是從伺服器發送到瀏覽器的報頭的一部分；但它們不屬於由瀏覽器返回給伺服器的報頭。
因此除了名稱和值之外，cookie屬性只適用於從伺服器輸出到客戶端的cookie；伺服器端來自於瀏覽器的cookie並沒有設置這些屬性。
因而不要期望通過request.getCookies得到的cookie中可以使用這個屬性。這意味著，你不能僅僅通過設置cookie的最大時效，發出它，在隨後的輸入數組中查找適當的cookie,讀取它的值，修改它並將它存回Cookie，從而實現不斷改變的cookie值。
*************************************************************************************
十、如何使用cookie記錄各個用戶的訪問計數
*************************************************************************************
1.獲取cookie數組中專門用於統計用戶訪問次數的cookie的值
2.將值轉換成int型
3.將值加1並用原來的名稱重新創建一個Cookie對象
4.重新設置最大時效
5.將新的cookie輸出
*************************************************************************************
十一、session在不同環境下的不同含義
*************************************************************************************
session，中文經常翻譯為會話，其本來的含義是指有始有終的一系列動作/消息，比如打電話是從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之為一個session。
然而當session一詞與網路協議相關聯時，它又往往隱含了「面向連接」和/或「保持狀態」這樣兩個含義。
session在Web開發環境下的語義又有了新的擴展，它的含義是指一類用來在客戶端與伺服器端之間保持狀態的解決方案。有時候Session也用來指這種解決方案的存儲結構。
*************************************************************************************
十二、session的機制
*************************************************************************************
session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構(也可能就是使用散列表)來保存信息。
但程序需要為某個客戶端的請求創建一個session的時候，伺服器首先檢查這個客戶端的請求里是否包含了一個session標識－稱為session id,如果已經包含一個session id則說明以前已經為此客戶創建過session，伺服器就按照session id把這個session檢索出來使用(如果檢索不到，可能會新建一個，這種情況可能出現在服務端已經刪除了該用戶對應的session對象，但用戶人為地在請求的URL後面附加上一個JSESSION的參數)。
如果客戶請求不包含session id，則為此客戶創建一個session並且生成一個與此session相關聯的session id，這個session id將在本次響應中返回給客戶端保存。
*************************************************************************************
十三、保存session id的幾種方式
*************************************************************************************
A．保存session id的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發送給伺服器。
B．由於cookie可以被人為的禁止，必須有其它的機制以便在cookie被禁止時仍然能夠把session id傳遞回伺服器，經常採用的一種技術叫做URL重寫，就是把session id附加在URL路徑的後面，附加的方式也有兩種，一種是作為URL路徑的附加信息，另一種是作為查詢字元串附加在URL後面。網路在整個交互過程中始終保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個session id。
C．另一種技術叫做表單隱藏欄位。就是伺服器會自動修改表單，添加一個隱藏欄位，以便在表單提交時能夠把session id傳遞回伺服器。
*************************************************************************************
十四、session什麼時候被創建
*************************************************************************************
一個常見的錯誤是以為session在有客戶端訪問時就被創建，然而事實是直到某server端程序(如Servlet)調用HttpServletRequest.getSession(true)這樣的語句時才會被創建。
*************************************************************************************
十五、session何時被刪除
*************************************************************************************
session在下列情況下被刪除：
A．程序調用HttpSession.invalidate()
B．距離上一次收到客戶端發送的session id時間間隔超過了session的最大有效時間
C．伺服器進程被停止
再次注意關閉瀏覽器只會使存儲在客戶端瀏覽器內存中的session cookie失效，不會使伺服器端的session對象失效。
*************************************************************************************
十六、URL重寫有什麼缺點
*************************************************************************************
對所有的URL使用URL重寫，包括超鏈接，form的action，和重定向的URL。每個引用你的站點的URL，以及那些返回給用戶的URL(即使通過間接手段，比如伺服器重定向中的Location欄位)都要添加額外的信息。
這意味著在你的站點上不能有任何靜態的HTML頁面(至少靜態頁面中不能有任何鏈接到站點動態頁面的鏈接)。因此，每個頁面都必須使用servlet或JSP動態生成。即使所有的頁面都動態生成，如果用戶離開了會話並通過書簽或鏈接再次回來，會話的信息都會丟失，因為存儲下來的鏈接含有錯誤的標識信息－該URL後面的SESSION ID已經過期了。
*************************************************************************************
十七、使用隱藏的表單域有什麼缺點
*************************************************************************************
僅當每個頁面都是有表單提交而動態生成時，才能使用這種方法。單擊常規的<A HREF..>超文本鏈接並不產生表單提交，因此隱藏的表單域不能支持通常的會話跟蹤，只能用於一系列特定的操作中，比如在線商店的結賬過程
*************************************************************************************
十八、會話跟蹤的基本步驟
*************************************************************************************
1．訪問與當前請求相關的會話對象
2．查找與會話相關的信息
3．存儲會話信息
4．廢棄會話數據
*************************************************************************************
十九、getSession()/getSession(true)、getSession(false)的區別
*************************************************************************************
getSession()/getSession(true)：當session存在時返回該session，否則新建一個session並返回該對象
getSession(false)：當session存在時返回該session，否則不會新建session，返回null
*************************************************************************************
二十、如何將信息於會話關聯起來
*************************************************************************************
setAttribute會替換任何之前設定的值；如果想要在不提供任何代替的情況下移除某個值，則應使用removeAttribute。這個方法會觸發所有實現了HttpSessionBindingListener介面的值的valueUnbound
方法。
*************************************************************************************
二十一、會話屬性的類型有什麼限制嗎
*************************************************************************************
通常會話屬性的類型只要是Object就可以了。除了null或基本類型，如int,double,boolean。
如果要使用基本類型的值作為屬性，必須將其轉換為相應的封裝類對象
*************************************************************************************
二十二、如何廢棄會話數據
*************************************************************************************
A．只移除自己編寫的servlet創建的數據：
調用removeAttribute(「key」)將指定鍵關聯的值廢棄
B．刪除整個會話(在當前Web應用中)：
調用invalidate，將整個會話廢棄掉。這樣做會丟失該用戶的所有會話數據，而非僅僅由我們
servlet或JSP頁面創建的會話數據
C．將用戶從系統中注銷並刪除所有屬於他(或她)的會話
調用logOut，將客戶從Web伺服器中注銷，同時廢棄所有與該用戶相關聯的會話(每個Web應用至多一個)。這個操作有可能影響到伺服器上多個不同的Web應用
*************************************************************************************
二十三、使用isNew來判斷用戶是否為新舊用戶的錯誤做法
*************************************************************************************
public boolean isNew()方法如果會話尚未和客戶程序(瀏覽器)發生任何聯系，則這個方法返回true，這一般是因為會話是新建的，不是由輸入的客戶請求所引起的。
但如果isNew返回false，只不過是說明他之前曾經訪問該Web應用，並不代表他們曾訪問過我們的servlet或JSP頁面。
因為session是與用戶相關的，在用戶之前訪問的每一個頁面都有可能創建了會話。因此isNew為false只能說用戶之前訪問過該Web應用，session可以是當前頁面創建，也可能是由用戶之前訪問過的頁面創建的。
正確的做法是判斷某個session中是否存在某個特定的key且其value是否正確
*************************************************************************************
二十四、Cookie的過期和Session的超時有什麼區別
*************************************************************************************
會話的超時由伺服器來維護，它不同於Cookie的失效日期。首先，會話一般基於駐留內存的cookie
不是持續性的cookie，因而也就沒有截至日期。即使截取到JSESSIONID cookie，並為它設定一個失效日期發送出去。瀏覽器會話和伺服器會話也會截然不同。
*************************************************************************************
二十五、session cookie和session對象的生命周期是一樣的嗎
*************************************************************************************
當用戶關閉了瀏覽器雖然session cookie已經消失，但session對象仍然保存在伺服器端
*************************************************************************************
二十六、是否只要關閉瀏覽器，session就消失了
*************************************************************************************
程序一般都是在用戶做log off的時候發個指令去刪除session，然而瀏覽器從來不會主動在關閉之前通知伺服器它將要被關閉，因此伺服器根本不會有機會知道瀏覽器已經關閉。伺服器會一直保留這個會話對象直到它處於非活動狀態超過設定的間隔為止。
之所以會有這種錯誤的認識，是因為大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個session id就消失了，再次連接到伺服器時也就無法找到原來的session。
如果伺服器設置的cookie被保存到硬碟上，或者使用某種手段改寫瀏覽器發出的HTTP請求報頭，把原來的session id發送到伺服器，則再次打開瀏覽器仍然能夠找到原來的session。
恰恰是由於關閉瀏覽器不會導致session被刪除，迫使伺服器為session設置了一個失效時間，當距離客戶上一次使用session的時間超過了這個失效時間時，伺服器就可以認為客戶端已經停止了活動，才會把session刪除以節省存儲空間。
由此我們可以得出如下結論：
關閉瀏覽器，只會是瀏覽器端內存里的session cookie消失，但不會使保存在伺服器端的session對象消失，同樣也不會使已經保存到硬碟上的持久化cookie消失。
*************************************************************************************
二十七、打開兩個瀏覽器窗口訪問應用程序會使用同一個session還是不同的session
*************************************************************************************
通常session cookie是不能跨窗口使用的，當你新開了一個瀏覽器窗口進入相同頁面時，系統會賦予你一個新的session id，這樣我們信息共享的目的就達不到了。
此時我們可以先把session id保存在persistent cookie中(通過設置session的最大有效時間)，然後在新窗口中讀出來，就可以得到上一個窗口的session id了，這樣通過session cookie和persistent cookie的結合我們就可以實現了跨窗口的會話跟蹤。
*************************************************************************************
二十八、如何使用會話顯示每個客戶的訪問次數
*************************************************************************************
由於客戶的訪問次數是一個整型的變數，但session的屬性類型中不能使用int，double，boolean等基本類型的變數，所以我們要用到這些基本類型的封裝類型對象作為session對象中屬性的值
但像Integer是一種不可修改(Immutable)的數據結構：構建後就不能更改。這意味著每個請求都必須創建新的Integer對象，之後使用setAttribute來代替之前存在的老的屬性的值。例如：
HttpSession session = request.getSession();
SomeImmutalbeClass value = (SomeImmutableClass)session.getAttribute(「SomeIdentifier」);
if (value= =null){
value = new SomeImmutableClass(…); // 新創建一個不可更改對象
}else{
value = new SomeImmutableClass(calculatedFrom(value)); // 對value重新計算後創建新的對象
}
session.setAttribute(「someIdentifier」,value); // 使用新創建的對象覆蓋原來的老的對象
*************************************************************************************
二十九、如何使用會話累計用戶的數據
*************************************************************************************
使用可變的數據結構，比如數組、List、Map或含有可寫欄位的應用程序專有的數據結構。通過這種方式，除非首次分配對象，否則不需要調用setAttribute。例如
HttpSession session = request.getSession();
SomeMutableClass value = (SomeMutableClass)session.getAttribute(「someIdentifier」);
if(value = = null){
value = new SomeMutableClass(…);
session.setAttribute(「someIdentifier」,value);
}else{
value.updateInternalAttribute(…); // 如果已經存在該對象則更新其屬性而不需重新設置屬性
}
*************************************************************************************
三十、不可更改對象和可更改對象在會話數據更新時的不同處理
*************************************************************************************
不可更改對象因為一旦創建之後就不能更改，所以每次要修改會話中屬性的值的時候，都需要
調用setAttribute(「someIdentifier」,newValue)來代替原有的屬性的值，否則屬性的值不會被更新
可更改對象因為其自身一般提供了修改自身屬性的方法，所以每次要修改會話中屬性的值的時
候，只要調用該可更改對象的相關修改自身屬性的方法就可以了。這意味著我們就不需要調
用setAttribute方法了
*************************************************************************************
❹ 登陸有的網頁會導致瀏覽器自動關閉是怎麼回事
請參考：
使用Windows操作系統的人有時會遇到這樣的錯誤信息：「0X????????指令引用的0x00000000內存，該內存不能written」，然後應用程序被關閉。如果去請教一些「高手」，得到的回答往往是「Windows就是這樣不穩定」之類的義憤和不屑。其實，這個錯誤並不一定是Windows不穩定造成的。本文就來簡單分析這種錯誤的常見原因。
一、應用程序沒有檢查內存分配失敗
程序需要一塊內存用以保存數據時，就需要調用操作系統提供的「功能函數」來申請，如果內存分配成功，函數就會將所新開辟的內存區地址返回給應用程序，應用程序就可以通過這個地址使用這塊內存。這就是「動態內存分配」，內存地址也就是編程中的「指針」。
內存不是永遠都招之即來、用之不盡的，有時候內存分配也會失敗。當分配失敗時系統函數會返回一個0值，這時返回值「0」已不表示新啟用的指針，而是系統向應用程序發出的一個通知，告知出現了錯誤。作為應用程序，在每一次申請內存後都應該檢查返回值是否為0，如果是，則意味著出現了故障，應該採取一些措施挽救，這就增強了程序的「健壯性」。
若應用程序沒有檢查這個錯誤，它就會按照「思維慣性」認為這個值是給它分配的可用指針，繼續在之後的運行中使用這塊內存。真正的0地址內存區保存的是計算機系統中最重要的「中斷描述符表」，絕對不允許應用程序使用。在沒有保護機制的操作系統下（如DOS），寫數據到這個地址會導致立即死機，而在健壯的操作系統中，如Windows等，這個操作會馬上被系統的保護機制捕獲，其結果就是由操作系統強行關閉出錯的應用程序，以防止其錯誤擴大。這時候，就會出現上述的「寫內存」錯誤，並指出被引用的內存地址為「0x00000000」。
內存分配失敗故障的原因很多，內存不夠、系統函數的版本不匹配等都可能有影響。因此，這種分配失敗多見於操作系統使用很長時間後，安裝了多種應用程序（包括無意中「安裝」的病毒程序），更改了大量的系統參數和系統文件之後。
二、應用程序由於自身BUG引用了不正常的內存指針
在使用動態分配的應用程序中，有時會有這樣的情況出現：程序試圖讀寫一塊「應該可用」的內存，但不知為什麼，這個預料中可用的指針已經失效了。有可能是 「忘記了」向操作系統要求分配，也可能是程序自己在某個時候已經注銷了這塊內存而「沒有留意」等等。注銷了的內存被系統回收，其訪問權已經不屬於該應用程序，因此讀寫操作也同樣會觸發系統的保護機制，企圖「違法」的程序唯一的下場就是被操作終止運行，回收全部資源。計算機世界的法律還是要比人類有效和嚴厲得多啊！
像這樣的情況都屬於程序自身的BUG，你往往可在特定的操作順序下重現錯誤。無效指針不一定總是0，因此錯誤提示中的內存地址也不一定為「0x00000000」，而是其他隨機數字。
如果系統經常有所提到的錯誤提示，下面的建議可能會有幫助：
1.查看系統中是否有木馬或病毒。這類程序為了控制系統往往不負責任地修改系統，從而導致操作系統異常。平常應加強信息安全意識，對來源不明的可執行程序絕不好奇。
2.更新操作系統，讓操作系統的安裝程序重新拷貝正確版本的系統文件、修正系統參數。有時候操作系統本身也會有BUG，要注意安裝官方發行的升級程序。
3.試用新版本的應用程序。
問題
運行某些程序的時候，有時會出現內存錯誤的提示，然後該程序就關閉。
「0x????????」指令引用的「0x????????」內存。該內存不能為「read」。
「0x????????」指令引用的「0x????????」內存，該內存不能為「written」。
一般出現這個現象有方面的，一是硬體，即內存方面有問題，二是軟體，這就有多方面的問題了。
故障分析
硬體方面：
一般來說，內存出現問題的可能性並不大，主要方面是：內存條壞了、內存質量有問題，還有就是2個不同牌子不同容量的內存混插，也比較容易出現不兼容的情況，同時還要注意散熱問題，特別是超頻後。你可以使用MemTest 這個軟體來檢測一下內存，它可以徹底的檢測出內存的穩定度。
假如是雙內存，而且是不同品牌的內存條混插或者買了二手內存時，出現這個問題，這時，就要檢查是不是內存出問題了或者和其它硬體不兼容。
軟體方面：
先簡單說說原理：內存有個存放數據的地方叫緩沖區，當程序把數據放在其一位置時，因為沒有足夠空間，就會發生溢出現象。舉個例子：一個桶子只能將一斤的水，當放入兩斤的水進入時，就會溢出來。而系統則是在屏幕上表現出來。這個問題，經常出現在windows2000和XP系統上，Windows 2000/XP對硬體的要求是很苛刻的,一旦遇到資源死鎖、溢出或者類似Windows 98里的非法操作，系統為保持穩定，就會出現上述情況。另外也可能是硬體設備之間的兼容性不好造成的。
幾個例子
例一：打開IE瀏覽器或者沒過幾分鍾就會出現"0x70dcf39f"指令引用的"0x00000000"內存。該內存不能為「read」。要終止程序，請單擊「確定」的信息框，單擊「確定」後，又出現「發生內部錯誤，您正在使用的其中一個窗口即將關閉」的信息框，關閉該提示信息後，IE瀏覽器也被關閉。
解決方法：修復或升級IE瀏覽器，同時打上補丁。看過其中一個修復方法是，Win2000自升級，也就是Win2000升級到Win2000，其實這種方法也就是把系統還原到系統初始的狀態下。比如你的IE升級到了6.0，自升級後，會被IE5.0代替。
例二：在windows xp下雙擊光碟裡面的「AutoRun.exe」文件，顯示「0x77f745cc」指令引用的「0x00000078」內存。該內存不能為「written」，要終止程序，請單擊「確定」，而在Windows 98里運行卻正常。
解決方法：這可能是系統的兼容性問題，winXP的系統，右鍵「AutoRun.exe」文件，屬性，兼容性，把「用兼容模式運行這個程序」項選擇上，並選擇「Windows 98/Me」。win2000如果打了SP的補丁後，只要開始，運行，輸入：regsvr32 c:\winnt\apppatch\slayerui.dll。右鍵，屬性，也會出現兼容性的選項。
例三：RealOne Gold關閉時出現錯誤，以前一直使用正常，最近卻在每次關閉時出現「0xffffffff」指令引用的「0xffffffff」內存。該內存不能為「read」 的提示。
解決方法：當使用的輸入法為微軟拼音輸入法2003，並且隱藏語言欄時（不隱藏時沒問題）關閉RealOne就會出現這個問題，因此在關閉RealOne之前可以顯示語言欄或者將任意其他輸入法作為當前輸入法來解決這個問題。
例四：我的豪傑超級解霸自從上網後就不能播放了，每次都提示「Ox060692f6」（每次變化）指令引用的「Oxff000011」內存不能為「read」，終止程序請按確定。
解決方法：試試重裝豪傑超級解霸,如果重裝後還會，到官方網站下載相應版本的補丁試試。還不行，只好換就用別的播放器試試了。
例五：雙擊一個游戲的快捷方式，「Ox77f5cdO」指令引用「Oxffffffff」內存，該內存不能為「read」 ，並且提示Client.dat程序錯誤。
解決方法：重裝顯卡的最新驅動程序，然後下載並且安裝DirectX9.0。
例六：一個朋友發信息過來，我的電腦便出現了錯誤信息:「0*772b548f」指令引用的「0*00303033」內存，該內存不能為「written」,然後QQ自動下線，而再打開QQ，發現了他發過來的十幾條的信息。
解決方法：這是對方利用QQ的BUG，發送特殊的代碼，做QQ出錯，只要打上補丁或升級到最新版本，就沒事了。
例七：我的筆記本電腦用的XP系統，有時關閉網頁時會彈出tbrowser.exe遇到問題需要關閉，然後有彈出0x03e7c738指令引用的0x03e7c738內存，該內存不能為read,請問是怎麼回事？
解決方法：先查殺一下病毒，另外如果你安裝了瀏覽增強之類的軟體，請卸掉。
例八：從桌面或開始菜單中打開任何一個程序, 出現錯誤提示："0x........"指令引用的"0x00000000"內存,該內存不能為"read"。省略號代表可變值。而從運行中打開程序沒問題。
解決方法：運行regedit進入注冊表, 在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellExecuteHooks 下，應該只有一個正常的鍵值"{AEB6717E-7E19-11d0-97EE-00C04FD91972}, 將其他的刪除(默認鍵值當然不要刪除)。
例九：我三個月前配了台機子。系統比較不穩定，三個月內已經重裝過多次系統，四五天前剛裝過系統，可是經常隨機地出現Explorer-應用程序錯誤，「0x4a01259d「指令引用的「0x00000000"內存。該內存不能為 「read"。要終止程序，請單擊「確定「。要調試程序，請單擊「取消」。如果點確定，windows桌面就不見了。這種問題在之前的系統也出現過，不知道是不是硬體的問題？
解決方法：內存的兼容性問題！遇到這類問題，用戶可以自行打開機器把內存的位置調動一下，看問題是否可以解決，如果問題依舊，可與你的朋友調換內存使用。
通過上面的幾個例子，可以看到，出現故障的原因有好多種，下面列出已經提到和有可能發生的原因，方便查閱。
問題產生原因原因－－解決方法
內存條壞了－－更換內存條
雙內存不兼容－－使用同品牌的內存或只用一條內存
內存質量問題－－更換內存條
散熱問題－－加強機箱內部的散熱
內存和主板沒插好或和其它硬體不兼容等－－重插內存或換個插糟
硬碟有問題－－更換硬碟
驅動問題－－重裝驅動。如果是新系統，要先安裝主板驅動
軟體損壞－－重裝軟體
軟體有BUG－－打補丁或用最新的版本。
軟體和系統不兼容－－給軟體打上補丁或者試試系統的兼容模式
軟體和軟體之間有沖突－－如果最近安裝了什麼新軟體，卸載了試試
軟體要使用到其它相關的軟體有問題－－重裝相關軟體。比如播放某一格式的文件時出錯，可能是這個文件的解碼器有問題
病毒問題－－殺毒
殺毒軟體與系統或軟體沖突－－由於殺毒軟體是進入底層監控系統的，可能與一些軟體沖突，卸載了試試
系統本身有問題－－有時候操作系統本身也會有BUG，要注意安裝官方發行的升級程序，像SP的補丁，最好要打上。如果還不行重裝系統或更換其它版本的系統了。
此問題已經引起我們的重視並有解決方案，請去我們的官方網站了解及下載相關程序。
運行某些程序的時候，有時會出現內存錯誤的提示，然後該程序就關閉。
「0x????????」指令引用的「0x????????」內存。該內存不能為「read」。
「0x????????」指令引用的「0x????????」內存，該內存不能為「written」。
以上的情況相信大家都應該見到過，甚至說一些網友因為不爽於這個經常出現的錯誤提示而屢次重裝系統。相信普通用戶應該不會理解那些復雜的十六進制代碼。
我也遇到過這樣的情況，不過WINDOWS的確是用久了就很不穩定了，沒辦法。
❺ 華為瀏覽器的停止服務是什麼意思
是因為你停用了華為瀏覽器，導致華為瀏覽器無法使用的意思。
資料擴展：如何恢復華為瀏覽器使用
我們在手機上左右的滑動屏幕，找到華為手機的「設置」的圖標。
請點擊輸入圖片描述
這時就會打開華為瀏覽器的設置頁面了，在頁面中找到「應用和通知」的菜單項。
接著在打開的應用和通知的頁面中，我們點擊「應用管理」的菜單項。
然後在應有管理頁面中，點擊上面的「所有應用」的下拉按鈕。
在彈出的下拉菜單中我們選擇「已停用」的菜單項。
這時就會打開已停用的頁面了，在停用列表中找到「華為瀏覽器」的菜單項。
點擊後就會打開華為瀏覽器的應用信息頁面，在頁面中點擊「啟用」按鈕就可以了。這樣我們就會重新啟用被停用的華為瀏覽器了。
❻ Session會在瀏覽器關閉後消失嗎
通常情況下，當我們關閉瀏覽器再重新打開後，我們就需要再次進行登陸（如果沒有進行下次自動登錄之類的設置）。在Jav中（Session是通用的，這里以Java為例）有一種叫做Session機制（會話機制）來記錄用戶的登錄信息。瀏覽器關閉之後，Session會被清除嗎？
Session是一種伺服器端的對象，保存在伺服器中。 每個Session 有一個唯一的Session id。 Session的超時也是由伺服器來控制。我們一般都會把Session和Cookie放在一起來說，它們具體的區別和聯系這里我就不多說了，可以去查閱相關資料。Cookie分為內存中Cookie（也可以說是進程中Cookie）和硬碟中Cookie。大部分的Session機制都使用進程中Cookie來保存Session id的，關閉瀏覽器後這個進程也就自動消失了，進程中的Cookie自然就消失了，那麼Session id也跟著消失了，再次連接到伺服器時也就無法找到原來的Session了。
其實伺服器是不會知道瀏覽器關閉了沒有（當然，你可以在關閉的時候去通知伺服器，但一般都不會這樣做），所以關閉瀏覽器時伺服器是不會刪除Session的，也正是這個原因伺服器才會設置一個Session失效時間的，不然伺服器早晚會被撐爆的。等距離上一次使用該Session的時間達到設置的失效時間時，伺服器就會認為客戶端已停止活動，便會將相應的Session刪除。
當然，我們可以在登陸時點擊下次自動登錄，比如說CSDN的「記住我一周」，或者我們的購物車信息可以在切換不同瀏覽器時依然可用。這就要用到我們上文提到的另一種Cookie了——硬碟中Cookie，這時Session id將長期保存在硬碟上的Cookie中，直到失效為止。
❼ 用戶關閉網頁時怎麼通知伺服器"我注銷了"
給你的網頁加個unload事件處理器，這樣無論是關閉網頁還是跳轉到其它頁面，只要這個HTML文檔被卸載，就會觸發這個unload事件。在這個事件處理器中你就寫一段JS代碼，發個Ajax請求給伺服器，告訴伺服器，這個用戶已經離開此網頁，也就是注銷了
❽ asp.net中如何判斷關閉瀏覽器
後台是沒有辦法直接捕獲到的，不過可以通過在頁面中加入以下腳本讓瀏覽器關閉時觸發一次提交
<script>
window.onunload=function(){
if(event.clientX>document.body.clientWidth && event.clientY < 0 || event.altKey) //如果是關閉瀏覽器而不是刷新頁面
__doPostBack('closing',''); //觸發一次提交
}
</script>
然後即可在後台此動作進行捕獲
protected void Page_Load(object sender, EventArgs e)
{
if (Request["__EVENTTARGET"] == "closing")
{
...最後的處理...
Response.End(); //因為是最後的處理，不需要頁面輸出，所以執行到這里就可以了
}
...原有的正常代碼...
}
有些情況下，頁面不會自動生成__doPostBack函數即其相關控制項（如：頁面上只有Button控制項時）,可以在頁面上手工添加以下代碼：
<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
<script type="text/javascript">
//<![CDATA[
var theForm = document.forms['form1'];
if (!theForm) {
theForm = document.form1;
}
function __doPostBack(eventTarget, eventArgument) {
if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
theForm.__EVENTTARGET.value = eventTarget;
theForm.__EVENTARGUMENT.value = eventArgument;
theForm.submit();
}
}
//]]>
</script>
以上方法對於用戶通過任務管理器中止IE進程之類的「狠招」沒有任務辦法...
另外還有個缺點：
1.只有在用戶關閉瀏覽器時才會觸發，如果是頁面跳轉就捕獲不到了
2.當然也可以把那個腳本改成
<script>
window.onunload=function(){ __doPostBack('closing','');}
</script>
這樣，不管如果都會觸發提交，但是問題更大，因為即使是用戶進行正常的頁面提交，比如點擊頁面上的某個按鈕也會觸發這個事件！
3.解決辦法是使用UpdatePanel，這樣普通的提交是不會刷新頁面的，也就不會觸發window.onunload事件了。但是還有一個問題，就是當第一次頁面發生跳轉時（不管是後台控制還是前面用戶操作的）都會使頁面變成一個空白頁面。因為那個腳本強制讓頁面刷新了一下，導致跳轉失效，而後台捕獲到了closing參數，處理完後終止了輸出，導致頁面變成了空白頁。
4.也有辦法解決後台控制的跳轉問題，前是前台用戶修改地址欄這樣的跳轉就沒有辦法了，不想細寫了，反正我沒找到一個完美的解決辦法。
PS:以上方法還有一個惡心的用途，把後台的那句"Response.End();"去掉後，就可以讓用戶永遠離開你的頁面(包括修改地址欄和點擊收藏夾等），除非關閉瀏覽器
另外再提供一個解決的思路，可以較好的實現頁面關閉或頁面跳轉後的處理，但是實現起來相對麻煩些。就是用ajax做「心跳」：當用戶打開你的頁面時，保存一個對應的時間戳以及頁面關閉後要做的處理中用到的相關信息。在頁面中加入一個時間觸發器，每過一段時間（比如8秒）就用ajax提交一次，刷新用戶對應的時間戳。（也可以在global的sessionstart中進行時間戳的創建，並用sessionid作為標識進行刷新，這樣可以不局限於一個頁面，做到僅當用戶關閉所有打開你的站點的窗口之後才觸發，靈活性非常高）另外用一個線程，每過一段時間去檢查這個保存的時間戳（比如20秒），如果發現每個時間戳和系統當前時間相差大於等於閥值（比如20秒)即認定用戶關閉了瀏覽器或跳轉到別的頁面了，然後就可以進行你要的處理了。
寫得很亂，不知道你能看明白不？