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.