cookie存儲多個資料庫

Ⅰ 什麼是cookies數據

Cookies，指某些網站為了辨別用戶身份、進行 session 跟蹤而儲存在用戶本地終端上的數據（通常經過加密）。定義於 RFC2109 和 2965 中的都已廢棄，最新取代的規范是 RFC6265。

Cookie 技術產生源於 HTTP 協議在互聯網上的急速發展。隨著互聯網的深層次發展，帶寬等限制不存在了，人們需要更復雜的互聯網交互活動，就必須同伺服器保持活動狀態。

於是，在瀏覽器發展初期，為了適應用戶的需求，技術上推出了各種保持 Web 瀏覽狀態的手段，其中就包括了 Cookie 技術。

(1)cookie存儲多個資料庫擴展閱讀：

Cookies功能特點：

在同一個頁面中設置 Cookie，實際上是按從後往前的順序進行的。如果要先刪除一個 Cookie，再寫入一個 Cookie，則必須先寫入語句，再寫刪除語句，否則會出現錯誤。

Cookie是面向路徑的。預設路徑 (path) 屬性時，Web 伺服器頁會自動傳遞當前路徑給瀏覽器，指定路徑強制伺服器使用設置的路徑。在一個目錄頁面里設置的 Cookie 在另一個目錄的頁面里是看不到的。

Cookie 必須在 HTML 文件的內容輸出之前設置；不同的瀏覽器對 Cookie 的處理不一致，使用時一定要考慮。

客戶端用戶如果設置禁止 Cookie，則 Cookie 不能建立。 並且在客戶端，一個瀏覽器能創建的 Cookie 數量最多為 300 個，並且每個不能超過 4KB，每個 Web 站點能設置的 Cookie 總數不能超過 20 個。

Ⅱ cookies在.NET里的詳細用法和注意事項

Cookie 的限制

在開始討論 Cookie 的技術細節之前，我想先介紹一下 Cookie 應用的幾條限制。大多數瀏覽器支持最多可達 4096 位元組的 Cookie，如果要將為數不多的幾個值保存到用戶計算機上，這一空間已經足夠大，但您不能用一個 Cookie 來保存數據集或其他大量數據。在實際應用中，您可能並不希望在 Cookie 中保存大量的用戶信息，而只希望保存用戶編號或其他標識符。之後，當用戶再次訪問您的站點時，您就可以使用該用戶 ID 在資料庫中查找用戶的詳細信息。（有關保存用戶信息的說明，請參閱 Cookie 和安全性。）

瀏覽器還限制了您的站點可以在用戶計算機上保存的 Cookie 數。大多數瀏覽器只允許每個站點保存 20 個 Cookie。如果試圖保存更多的 Cookie，則最先保存的 Cookie 就會被刪除。還有些瀏覽器會對來自所有站點的 Cookie 總數作出限制，這個限制通常為 300 個。

您最可能遇到的 Cookie 限制是：用戶可以設置自己的瀏覽器，拒絕接受 Cookie。您很難解決這個問題，除非完全不使用 Cookie 而是通過其他機制來保存用戶相關信息。保存用戶信息的一種常用方法是會話狀態，但會話狀態又依賴於 Cookie。這一點在後面的 Cookie 和會話狀態中闡述。

注意：有關狀態管理和 Web 應用程序中用於保存信息的選項的詳細信息，請參閱 Introction to Web Forms State（英文）和 State Management Recommendations（英文）。
更一般的經驗很可能是，盡管 Cookie 在應用程序中非常有用，應用程序也不應該依賴於能夠保存 Cookie。利用 Cookie 可以做到錦上添花，但不要利用它們來支持關鍵功能。如果您的應用程序必須使用 Cookie，則您可以通過測試來確定瀏覽器是否接受 Cookie。我在本文後面的檢查瀏覽器是否接受 Cookie 一節中簡單介紹了一種測試方法。

編寫 Cookie

您可以利用頁面的 Response（英文）屬性來編寫 Cookie，該屬性提供的對象使用戶可以將信息添加到由頁面向瀏覽器呈現的信息中。Response 對象支持一個名為 Cookies（英文）的集合，您可以向其中添加要寫入瀏覽器的 Cookie。

注意：下面要討論的 Response 對象和 Request 對象分別是包含 HttpResponse（英文）和 HttpRequest（英文）類實例的頁面的屬性。要在文檔中查找 Response 和 Request 的信息，請參閱 HttpResponse 和 HttpRequest 下的內容。

在創建 Cookie 時，您需要指定幾個值。最初，您要指定 Cookie 的名稱和其中保存的值。您可以創建多個 Cookie，每個 Cookie 都必須具有唯一的名稱，以便日後讀取時識別。（Cookie 是按名稱保存的，所以如果您創建了兩個名稱相同的 Cookie，後保存的那一個將覆蓋前一個。）

您可能還希望指定 Cookie 的過期日期和時間。Cookie 一般都寫入到用戶的磁碟，然後可能一直都留在磁碟上。因此，您可以指定 Cookie 過期的日期和時間。當用戶再次訪問您的站點時，瀏覽器會先檢查您站點的 Cookie 集合，如果某個 Cookie 已經過期，瀏覽器不會把這個 Cookie 隨頁面請求一起發送給伺服器，而是刪除這個已經過期的 Cookie。（您的站點可能已經在用戶計算機上寫入了多個 Cookie，每個 Cookie 都有各自的過期日期和時間。） 請注意，由瀏覽器負責管理硬碟上的 Cookie，這將影響您在應用程序中對 Cookie 的使用，我很快會介紹這方面的內容。

一個 Cookie 的有效期應為多長？這取決於 Cookie 的用途，換句話說，取決於您的應用程序需要 Cookie 值保持有效的時間有多長。如果利用 Cookie 統計網站的訪問者，您可以把有效期設置為 1 年，如果某個用戶已有一年時間未訪問您的站點，則可以把該用戶當作新的訪問者； 如果利用 Cookie 來保存用戶的首選項，則可以把其設置為永遠有效（例如 50 年後到期），因為定期重新設置首選項對用戶而言是比較麻煩的。有時，您可能需要編寫在數秒或數分鍾內即過期的 Cookie。在本文後面的檢查瀏覽器是否接受 Cookie 一節中，我列舉了一個示例，該示例中創建的 Cookie 的實際有效期就只有幾秒。

注意：不要忘記用戶隨時可以刪除自己計算機上的 Cookie，所以即使您保存了長期有效的 Cookie，用戶也可以自行決定將其全部刪除，同時清除保存在 Cookie 中的所有設置。

如果沒有設置 Cookie 的有效期，還是可以創建 Cookie，但它不會保存到用戶的硬碟上，而是會成為用戶會話信息的一部分。如果用戶關閉瀏覽器或會話超時，該 Cookie 就會被刪除。這種非永久性的 Cookie 很適合用來保存只需短時間保存的信息，或者保存由於安全原因不應該寫入客戶計算機磁碟的信息。例如，如果用戶使用的是一台公用計算機，而您不希望把 Cookie 寫入這種計算機的磁碟上，這時就可以使用非永久性的 Cookie。

您可以通過多種方法把 Cookie 添加到 Response.Cookies 集合中。以下示例介紹了兩種完成此任務的方法：

Response.Cookies("userName").Value = "mike"
Response.Cookies("userName").Expires = DateTime.Now.AddDays(1)

Dim aCookie As New HttpCookie("lastVisit")
aCookie.Value = DateTime.Now.ToString
aCookie.Expires = DateTime.Now.AddDays(1)
Response.Cookies.Add(aCookie)

該示例向 Cookies 集合中添加了兩個 Cookie，一個稱為「userName」，另一個稱為「lastVisit」。對於第一個 Cookie，我直接設置了 Response.Cookies 集合的值。您可以使用這種方法向集合中添加值，因為 Response.Cookies 是從 NameObjectCollectionBase（英文）類型的特殊集合派生得到的。

對於第二個 Cookie，我創建了 Cookie 對象的一個實例（HttpCookie [英文] 類型），並設置了其屬性，然後通過 Add 方法把它添加到 Response.Cookies 集合。實例化 HttpCookie 對象時，您必須把 Cookie 名稱作為構造函數的一部分進行傳遞。

這兩個示例完成了相同的任務，即向瀏覽器寫入一個 Cookie。您要採用哪種方法主要取決於您的個人喜好。您可能會發現第二種方法在設置 Cookie 屬性方面要稍微容易一些，但同時您也會注意到兩者的差別並不是很大。

在這兩種方法中，有效期值必須為 DateTime 類型。而「lastVisited」值也是日期/時間值。但在這種情況下，我必須把日期/時間值轉換為字元串，因為 Cookie 中的任何值最終都是以字元串的形式保存的。 詳細參考MSDN幫助文檔 http://msdn.microsoft.com/zh-cn/library/ms178194(VS.80).aspx

Ⅲ 什麼是cookie文件它有什麼用存儲在哪

cookie是一種程序，當它放到硬碟後，就成為一個個擴展名為TXT的純文本文件。
cookie的大小並不相同，有的是幾十個位元組，有的則是2K左右。cookie的內容用一般的文本編輯器都可以看到。但是，大多數cookie的內容看上去都是亂糟糟的，讓人不知所雲，但這 看起來亂糟糟的內容，卻蘊藏著天機： 有的cookie中包含了上次訪問的時間、信用卡信息等數據信息；還有的cookie甚至包含了Email地址和訪問過的站點地址。
Cookie一般來說，其位置都是放置在C:\WINDOWS\cookie目錄下面，只要打開這個目錄就可以看到了。不過，也有些cookie並沒有在這個目錄下面。這些cookie就只能通過搜索系統 的注冊表來查找了。
當第一次登錄到某個站點時，遠端伺服器就會傳過來一個cookie，裡麵包含一個隨機產生的字元序列，稱為用戶ID，用來唯一標識用戶，當然這個用戶就是了。與此同時，伺服器 也把這個用戶ID記錄到自己的資料庫中，每當這個被標識過的用戶在站點上進行操作，譬如在各個連接之間跳轉，或是下載了某些東西，在哪裡哪裡逗留了多久等，這些有關的操作信息就會 被記錄到資料庫中。當這個用戶再一次登錄該站點時，只要他上一次訪問時收到的cookie還存在，瀏覽器就會把相應cookie中的信息上傳給遠端的伺服器，伺服器便能依據cookie中的信息查 到資料庫中相應的記錄，然後對將要下傳的數據進行處理之後再傳到遠方用戶的電腦中，瀏覽器再把這些數據顯示給用戶。

Ⅳ 緩存 是session 還是 cookie

以前實現數據的緩存有很多種方法，有客戶端的Cookie，有伺服器端的Session和Application。

其中Cookie是保存在客戶端的一組數據，主要用來保存用戶名等個人信息。

Session則保存對話信息。Application則是保存在整個應用程序范圍內的信息，相當於全局變數。

Session

Session用來保存每一個用戶的專有信息

Session的生存期是用戶持續請求時間加上一段時間（一般是20分鍾左右）

Session信息是保存在Web伺服器內存中的，保存數據量可大可小
由於用戶停止使用應用程序之後它仍在內存中存留一段時間，因此這種方法效率較低

代碼：

Session[「UserID」]=」test」;
String UserName=Session[「UserID」].ToString();

Cookie

Cookie用來保存客戶瀏覽器請求伺服器頁面的請求信息

我們可以存放非敏感的用戶信息，保存時間可以根據需要設置

如果沒有設置Cookie失效日期，它的生命周期保存到關閉瀏覽器為止

Cookie對象的Expires屬性設置為MinValue表示永不過期

Cookie存儲的數據量受限制，大多數的瀏覽器為4K因此不要存放大數據

由於並非所有的瀏覽器都支持Cookie，數據將以明文的形式保存在客戶端

代碼：

Resopnse.Cookies[「UserID」]=」test」;
String UserName= Resopnse.Cookies [「UserID」].ToString();

Cache

Cache用於在Http請求期間保存頁面或者數據

Cache的使用可以大大的提高整個應用程序的效率

它允許將頻繁訪問的伺服器資源存儲在內存中，當用戶發出相同的請求後,伺服器不是再次處理而是將Cache中保存的數據直接返回給用戶

可以看出Cache節省的是時間—伺服器處理時間

Cache實例是每一個應用程序專有的，其生命周期==該應用程序周期

應用程序重啟將重新創建其實例

注意：如果要使用緩存的清理、到期管理、依賴項等功能必須使用Insert 或者Add方法方法添加信息

代碼：

Cache[」ID」]=」cc」;或者Cache.Insert(「ID」,」test」);
String ID =Cache[「ID」].ToString();

通常使用最頻繁的是Session，那麼Session和Cache又有什麼區別呢？

Session緩存和Cache緩存的區別。

（1）最大的區別是Cache提供緩存依賴來更新數據，而Session只能依靠定義的緩存時間來判斷緩存數據是否有效。

（2）即使應用程序終止，只要Cache.Add方法中定義的緩存時間未過期，下次開啟應用程序時，緩存的數據依然存在。而Session緩存只是存在於一次會話中，會話結束後，數據也就失效了。

（3）Session容易丟失，導致數據的不確定性，而Cache不會出現這種情況。

（4）由於Session是每次會話就被載入，所以不適宜存放大量信息，否則會導致伺服器的性能降低。而Cache則主要用來保存大容量信息，如資料庫中的多個表。

（5）Session目前只能保存在內存中，對其性能有影響。

Session：為當前用戶會話提供信息。還提供對可用於存儲信息的會話范圍的緩存的訪問，以及控制如何管理會話的方法。它存儲在伺服器的內存中，因此與在資料庫中存儲和檢索信息相比，它的執行速度更快。與不特定於單個用戶會話的應用程

序狀態不同，會話狀態應用於單個的用戶和會話。因此，應用程序狀態非常適合存儲那些數量少、隨用戶的變化而變化的常用數據。而且由於其不發生伺服器-客戶
端數據傳輸，Session還適合存儲關於用戶的安全數據，如購物車信息。

Session的關鍵特性有：存儲於伺服器內存中，與會話相關，在會話的整個生存期中存在即不會被主動丟棄，不被序列化，不發生伺服器-客戶端數據傳輸。
Cache：它存儲於

伺服器的內存中，允許您自定義如何緩存項以及將它們緩存多長時間。例如，當缺乏系統內存時，緩存會自動移除很少使用的或優先順序較低的項以釋放內存。該技術

也稱為清理，這是緩存確保過期數據不使用寶貴的伺服器資源的方式之一。它不與會話相關，所以它是多會話共享的，因此使用它可以提高網站性能，但是可能泄露
用戶的安全信息，還由於在伺服器缺乏內存時可能會自動移除Cache因此需要在每次獲取數據時檢測該Cache項是否還存在。

Cache的關鍵特性有：存儲於伺服器內存中，與會話無關，根據伺服器內存資源的狀況隨時可能被丟棄，不被序列化，不發生伺服器-客戶端數據傳輸。

Cookie：Cookie 提供了一種在 Web 應用程序中存儲用戶特定信息的方法。例如，當用戶訪問您的站點時，您可以使用 Cookie
存儲用戶首選項或其他信息。當該用戶再次訪問您的網站時，應用程序便可以檢索以前存儲的信息。在開發人員以編程方式設置Cookie時，需要將自己希望保
存的數據序列化為字元串（並且要注意，很多瀏覽器對Cookie有4096位元組的限制）然後進行設置。

Cookie的關鍵特性有：存儲於客戶端硬碟上，與用戶相關，在一定時間內持久化存儲，可以跨瀏覽器共享數據，需要被序列化，發生伺服器-客戶端數據傳輸。

下面這個問題很有啟發性:

最近小組的同事很喜歡用Session做頁面跳轉，具體就是在查詢頁面把查詢結果放到DataTable中，用Session存儲這個dataTable,讀取到數據之後再子頁面做Session清除，這樣對性能有沒有什麼影響？

1、session：session的確是存放在伺服器的內存中（但不是4k上限，具體大小限制應該是伺服器內存），而且同一個sessionid的多個
http請求會排隊，也就是session對於同一個瀏覽器來說是同步的，用不好會極大影響性能。另外，session依賴於客戶端cookie，因為
sessionid是存放在客戶端瀏覽器進程cookie中的，因此不支持cookie的瀏覽器，session也會丟失(session
url重寫可部分解決這個問題，可參考：http://www.sungness.com/archives/48)。因此不建議用。

2、cookie，也不建議存放datatable這樣的「大數據」。因為cookie不僅有4k上限，並且不是「純存放在客戶端」這么簡單，要知道

cookie的值在每次web頁面請求往返的過程中都是要附帶在http頭中的，如果太大會佔用伺服器和客戶端之間的網路帶寬（雖然只是4k，但在線人多
了可就是4k * n了）。對於b/s結構的應用來說，網路帶寬是性能最主要的瓶頸之一！另外，對於datatbale轉換成json字元串再存入
cookie，伺服器CPU也會消耗。最可怕的是，一但你的cookie忘記刪除了，那麼在其有效期和作用域內，用戶訪問你的所有頁面時都將攜帶這個4K
大小的http頭，那就悲劇了。10000在線人數，4千兆網卡也不夠你花的。

3、資料庫連接，每次保存查詢語句然後再查詢的方式不錯，不過看你的查詢復雜度了，如果很費時的查詢，這樣調用也是不可取的。內存和cpu的矛盾你要根據

實際情況作出選擇。對於具有連接池的應用來說，一次連接數據的成本並不高，經過測試差不多=10次調用取當前系統時間函數。但查詢語句的復雜度就沒譜了。

另外，如果並發人數很多的情況下，頻繁佔用資料庫連接，會導致連接池沒有可用連接了，那就又悲劇了。此時就不是一次連接的成本，系統整體性能將毀滅性的下
降，反應遲鈍。

4、cache：一個不錯的選擇，不過它可同樣是佔用伺服器內存哦，只是比session多了一些靈活性。不過我也不建議你用於存放傳遞參數的地方。要知

道session就算內存滿了也不會丟失你的參數值（會拋異常），可cache可不是，它會直接刪掉你的參數值，甚至內存極度不足時都不會讓你進去（也不
會報錯）。換句話說，可能上一行代碼剛存進去，下一行代碼去讀就丟了。很可怕吧~

5、form表單：最為提倡的方式，http協議中原本頁面間傳值的方法就是這樣的，只是有時不太方便，能用之則用之。
6、自定義存儲機制：如果你對性能要求很苛刻，或者非要精益求精的話。那麼還是自己寫一個存儲機制吧。例如我自己就是寫了自己的XSession對象，它

的用法與session使用類似，但是存儲機制都是我自己封裝的，既有cache的優點、又有session的優點，還有資料庫的優點、性能看你寫的演算法
了、而且具有更大的使用靈活性。缺點就是需要你自己coding.