视图状态是 ASP.NET 页框架默认情况下用于保存往返过程之间的页和控件值的方法。当呈现页的 HTML 形式时，需要在回发过程中保留的页的当前状态和值将被序列化为 Base64 编码的字符串，并输出到视图状态的隐藏字段中。

视图状态是 ASP.NET 页中的储存库，可以存储需要在回发过程中保留的值。例如，您可以将信息存储在视图状态中，下次将页面发送到服务器时，将会在页加载事件过程中访问这些信息。
您可以使用页的 ViewState 属性（此属性公开一个字典对象）来访问视图状态信息。由于视图状态数据以字符串的形式存储，因此只能存储可以序列化的对象。

视图状态数据以 Base64 编码字符串的格式存储在一个或多个隐藏字段中。您可以使用页的 ViewState 属性（此属性公开一个字典对象）来访问视图状态信息。由于视图状态数据以字符串的形式存储，因此只能存储可以序列化的对象。

由于视图状态是作为隐藏字段发送的，因此直到发生 PreRenderComplete 事件之前，都可以对视图状态进行更改。一旦将页呈现到浏览器，便无法保存对视图状态的更改。

如果查看页输出源，则可以看到隐藏视图状态字段中的信息，这可能产生安全性问题。若要缓解该问题，可以通过将 @ Page 指令中的 viewStateEncryptionMode 属性设置为“Always”来加密视图状态。

注意
若要使用 ViewState 属性，ASP.NET 网页必须包含具有 runat="server" 属性的窗体元素。

可以存储在视图状态中的数据类型
您可以将下列类型的对象存储到视图状态中：
字符串
整数
布尔值
Array 对象
ArrayList 对象
哈希表
自定义类型转换器（请参见 TypeConverter 类）
您也可以存储其他类型的数据，但是必须使用 Serializable 属性编译该类，这样视图状态便可以将这些数据序列化为 XML。

使用视图状态的注意事项
视图状态提供了特定 ASP.NET 页的状态信息。如果需要在多个页上使用信息，或者如果需要在访问网站时保留信息，则应当使用另一个方法（如应用程序状态、会话状态或个性化设置）来维护状态。

视图状态信息将序列化为 XML，然后使用 Base64 编码进行编码，这将生成大量的数据。将页回发到服务器时，视图状态的内容将作为页回发信息的一部分发送。如果视图状态包含大量信息，则会影响页的性能。

另一个重要的考虑因素是，如果隐藏字段中的数据量过大，某些代理和防火墙将禁止访问包含这些数据的页。由于最大数量会随所采用的防火墙和代理的不同而不同，因此大量隐藏字段可能会导致偶发性问题。为了帮助避免这一问题，如果 ViewState 属性中存储的数据量超过了页的 MaxPageStateFieldLength 属性中指定的值，该页会将视图状态拆分为多个隐藏字段，以将每个单独字段的大小减少到防火墙拒绝的大小以下。

某些移动设备根本不允许使用隐藏字段。因此，视图状态对于这些设备无效。

从视图状态中读取值
在页代码中，设置 ViewState 属性中变量的值。
下面的代码示例说明如何从视图状态中获取名为 arrayListInViewState 的 ArrayList 对象，然后将 GridView 控件作为数据源绑定到该对象。
arrayList = new ArrayList();
arrayList = (ArrayList)ViewState["arrayListInViewState"];

this.GridView1.DataSource = arrayList;
this.GridView1.DataBind();

视图状态中的值被类型化为 String。如本例所示。在 C# 中，当您读取视图状态值时，应该始终强制转换为适当的类型。
如果尝试从不存在的视图状态中获取值，则不会引发任何异常。若要确保所需的值处于视图状态，请首先使用测试（例如以下测试）检查该对象是否存在：
if (ViewState["color"] == null)
    // No such value in view state, take appropriate action.

将值保存到视图状态
下面的示例演示如何实现从其控件的 ViewState 属性存储和检索值的 Text 属性。
private const int defaultFontSize = 3;

// Add property values to view state with set;
// retrieve them from view state with get.
public String Text
{
    get
    {
        object o = ViewState["text"];
        return (o == null)? String.Empty : (string)o;
    }

    set
    {
        ViewState["Text"] = value;
    }
}

加密视图状态
在 @ Page 指令中，将 ViewStateEncryptionMode 属性设置为“Always”，如下面的示例所示：
<% @Page ViewStateEncryptionMode="Always" ...  %>

如果您在编写控件，可以将控件的状态信息存储在 ViewState 字典中，该字典是一个 StateBag 对象。开发人员将通过 ControlState 属性检索控件状态。您为 ViewState 属性指定键和值，Page 对象将对请求之间的状态信息进行序列化。要在您的控件中执行自定义状态处理，可重写 LoadViewState 和 SaveViewState 方法。在页开发人员禁用视图状态时，存储在此字典中的所有状态信息都会丢失。为弥补这一缺陷，在 ASP.NET 2.0 版中，您可以将关键状态信息存储在一个称为控件状态的单独对象中。在页开发人员禁用视图状态时，控件状态对象不会受到影响。要将状态信息存储在控件状态对象中，控件需要重写 LoadControlState 和 SaveControlState 方法，并且需要在每次初始化该控件时将其注册为在控件状态中存储状态信息。可以通过重写 OnInit 方法并调用 RegisterRequiresControlState 方法将控件注册为使用控件状态。
控件状态是一个包含 Web 服务器控件正常工作所需要的关键视图状态数据的对象，并且它包含在一个单独的对象（与包含普通视图状态信息的对象不同）中。在 Page 级别禁用视图状态时，控件状态数据不会受到影响，但是需要额外的实现步骤才能使用。

下面的代码示例演示一个从 PageStatePersister 类派生的类如何初始化 ControlState 属性。此示例将 ControlState 属性指派给 Pair 对象的 Second 字段，并使用 ObjectStateFormatter 类对该属性进行序列化。调用 Load 方法时，使用 ObjectStateFormatter 类对视图状态和控件状态信息进行反序列化，并使用所得 Pair 对象的 Second 字段初始化 ControlState 属性。
//
// Load ViewState and ControlState.
//
public override void Load()
{
    Stream stateStream = GetSecureStream();

    // Read the state string, using the StateFormatter.
    StreamReader reader = new StreamReader(stateStream);

    IStateFormatter formatter = this.StateFormatter;
    string fileContents = reader.ReadToEnd();

    // Deserilize returns the Pair object that is serialized in
    // the Save method.
    Pair statePair = (Pair)formatter.Deserialize(fileContents);

    ViewState = statePair.First;
    ControlState = statePair.Second;
    reader.Close();
    stateStream.Close();
}

ASP.NET 允许您将信息存储在 HiddenField 控件中，此控件将呈现为一个标准的 HTML 隐藏域。
隐藏域在浏览器中不以可见的形式呈现，但您可以就像对待标准控件一样设置其属性。
当向服务器提交页时，隐藏域的内容将在 HTTP 窗体集合中随同其他控件的值一起发送。
隐藏域可用作一个储存库，您可以将希望直接存储在页中的任何特定于页的信息放置到其中。

安全注意
恶意用户可以很容易地查看和修改隐藏域的内容。请不要在隐藏域中存储任何敏感信息或保障应用程序正确运行的信息。

HiddenField 控件在其Value属性中只存储一个变量，并且必须通过显式方式添加到页上。
为了在页处理期间能够使用隐藏域的值，必须使用 HTTP POST 命令提交相应的页。如果在您使用隐藏域的同时，为了响应某个链接或 HTTP GET 命令而对页进行了相应处理，那么隐藏域将不可用。

HiddenField 控件用于存储一个值，在向服务器的各次发送过程中，需保持该值。它呈现为 <input type= "hidden"/> 元素。
通常情况下，Web 窗体页的状态由视图状态、会话状态和 cookie 来维持。但是，如果这些方法被禁用或不可用，则可以使用 HiddenField 控件来存储状态值。

若要指定 HiddenField 控件的值，请使用 Value 属性。

在向服务器的各次发送过程中，当 HiddenField 控件的值更改时，将引发ValueChanged事件

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>无标题页</title>

    <script type="text/javascript">
    function PageLoad()
  {
 
    // Set the value of the HiddenField control with the
    // value from the TextBox.
    form1.ValueHiddenField.value = form1.ValueTextBox.value;
   
  }

    </script>

</head>
<body>
    <form >
        <div>
            <asp:TextBox ID="ValueTextBox" runat="server" />
            <br />
            <input type="submit" name="SubmitButton" value="Submit" onclick="PageLoad()" />
            <br />
            <asp:Label ID="Message" runat="server" />
            <asp:HiddenField ID="ValueHiddenField" runat="server" OnValueChanged="ValueHiddenField_ValueChanged" />
        </div>
    </form>
</body>
</html>

总结

可以在页上的隐藏域中存储特定于页的信息，作为维护页的状态的一种方式。
如果使用隐藏域，最好在客户端上只存储少量经常更改的数据。

注意:
如果使用隐藏域，则必须使用 HTTP POST 方法向服务器提交页，而不是使用通过页 URL 请求该页的方法（HTTP GET 方法）向服务器提交页。
 

使用隐藏域的优点
1.不需要任何服务器资源:隐藏域在页上存储和读取。
2.广泛的支持:几乎所有浏览器和客户端设备都支持具有隐藏域的窗体。
3.实现简单:隐藏域是标准的HTML控件，不需要复杂的编程逻辑。

使用隐藏域的缺点
1.潜在的安全风险  
隐藏域可以被篡改。如果直接查看页输出源，可以看到隐藏域中的信息，这导致潜在的安全性问题。
您可以手动加密和解密隐藏域的内容，但这需要额外的编码和开销。如果关注安全，请考虑使用基于服务器的状态机制，从而不将敏感信息发送到客户端。
2.简单的存储结构  
隐藏域不支持复杂数据类型。
隐藏域只提供一个字符串值域存放信息。
若要存储多个值，必须实现分隔的字符串以及用来分析那些字符串的代码。您可以手动分别将复杂数据类型序列化为隐藏域以及将隐藏域反序列化为复杂数据类型。但是，这需要额外的代码来实现。
如果您需要将复杂数据类型存储在客户端上，请考虑使用视图状态。视图状态内置了序列化，并且将数据存储在隐藏域中。
3.性能注意事项  
由于隐藏域存储在页本身，因此如果存储较大的值，用户显示页和发送页时的速度可能会减慢。
4.存储限制  
如果隐藏域中的数据量过大，某些代理和防火墙将阻止对包含这些数据的页的访问。因为最大数量会随所采用的防火墙和代理的不同而不同，较大的隐藏域可能会出现偶发性问题。
如果您需要存储大量的数据项，请考虑执行下列操作之一：
(1)将每个项放置在单独的隐藏域中。
(2)使用视图状态并打开视图状态分块，这样会自动将数据分割到多个隐藏域。
(3)不将数据存储在客户端上，将数据保留在服务器上。向客户端发送的数据越多，您的应用程序的表面响应时间越慢，因为浏览器需要下载或发送更多的数据。
 

Cookie 提供了一种在 Web 应用程序中存储用户特定信息的方法。
例如，当用户访问您的站点时，您可以使用 Cookie 存储用户首选项或其他信息。当该用户再次访问您的网站时，应用程序便可以检索以前存储的信息。

什么是 Cookie？
Cookie 是一小段文本信息，伴随着用户请求和页面在 Web 服务器和浏览器之间传递。
Cookie 包含每次用户访问站点时 Web 应用程序都可以读取的信息。

例如，如果在用户请求站点中的页面时应用程序发送给该用户的不仅仅是一个页面，还有一个包含日期和时间的 Cookie，用户的浏览器在获得页面的同时还获得了该 Cookie，并将它存储在用户硬盘上的某个文件夹中。

以后，如果该用户再次请求您站点中的页面，当该用户输入 URL 时，浏览器便会在本地硬盘上查找与该 URL 关联的 Cookie。如果该 Cookie 存在，浏览器便将该 Cookie 与页请求一起发送到您的站点。然后，应用程序便可以确定该用户上次访问站点的日期和时间。您可以使用这些信息向用户显示一条消息，也可以检查到期日期。

Cookie 与网站关联，而不是与特定的页面关联。因此，无论用户请求站点中的哪一个页面，浏览器和服务器都将交换 Cookie 信息。用户访问不同站点时，各个站点都可能会向用户的浏览器发送一个 Cookie；浏览器会分别存储所有 Cookie。

Cookie 帮助网站存储有关访问者的信息。一般来说，Cookie 是一种保持 Web 应用程序连续性（即执行状态管理）的方法。除短暂的实际交换信息的时间外，浏览器和 Web 服务器间都是断开连接的。对于用户向 Web 服务器发出的每个请求，Web 服务器都会单独处理。但是在很多情况下，Web 服务器在用户请求页时识别出用户会十分有用。例如，购物站点上的 Web 服务器跟踪每位购物者，这样站点就可以管理购物车和其他的用户特定信息。因此，Cookie 可以作为一种名片，提供相关的标识信息帮助应用程序确定如何继续执行。

使用 Cookie 能够达到多种目的，所有这些目的都是为了帮助网站记住用户。例如，一个实施民意测验的站点可以简单地将 Cookie 作为一个 Boolean 值，用它来指示用户的浏览器是否已参与了投票，这样用户便无法进行第二次投票。要求用户登录的站点则可以通过 Cookie 来记录用户已经登录，这样用户就不必每次都输入凭据。

Cookie 的限制
大多数浏览器支持最大为 4096 字节的 Cookie。由于这限制了 Cookie 的大小，最好用 Cookie 来存储少量数据，或者存储用户 ID 之类的标识符。用户 ID 随后便可用于标识用户，以及从数据库或其他数据源中读取用户信息。（有关存储用户信息安全建议的信息，请参见下面的“Cookie 和安全性”一节。）

浏览器还限制站点可以在用户计算机上存储的 Cookie 的数量。大多数浏览器只允许每个站点存储 20 个 Cookie；如果试图存储更多 Cookie，则最旧的 Cookie 便会被丢弃。有些浏览器还会对它们将接受的来自所有站点的 Cookie 总数作出绝对限制，通常为 300 个。

您可能遇到的 Cookie 限制是用户可以将其浏览器设置为拒绝接受 Cookie。如果定义一个 P3P 隐私策略，并将其放置在网站的根目录中，则更多的浏览器将接受您站点的 Cookie。但是，您可能会不得不完全放弃 Cookie，而通过其他机制来存储用户特定的信息。

编写 Cookie
浏览器负责管理用户系统上的 Cookie。
Cookie 通过 HttpResponse 对象发送到浏览器，该对象公开称为 Cookies 的集合。可以将 HttpResponse 对象作为 Page 类的 Response 属性来访问。要发送给浏览器的所有 Cookie 都必须添加到此集合中。创建 Cookie 时，需要指定 Name 和 Value。每个 Cookie 必须有一个唯一的名称，以便以后从浏览器读取 Cookie 时可以识别它。由于 Cookie 按名称存储，因此用相同的名称命名两个 Cookie 会导致其中一个 Cookie 被覆盖。

还可以设置 Cookie 的到期日期和时间。用户访问编写 Cookie 的站点时，浏览器将删除过期的 Cookie。只要应用程序认为 Cookie 值有效，就应将 Cookie 的有效期设置为这一段时间。对于永不过期的 Cookie，可将到期日期设置为从现在起 50 年。

注意:
用户可随时清除其计算机上的 Cookie。即便存储的 Cookie 距到期日期还有很长时间，但用户还是可以决定删除所有 Cookie，清除 Cookie 中存储的所有设置。
 

如果没有设置 Cookie 的有效期，仍会创建 Cookie，但不会将其存储在用户的硬盘上。而会将 Cookie 作为用户会话信息的一部分进行维护。当用户关闭浏览器时，Cookie 便会被丢弃。这种非永久性 Cookie 很适合用来保存只需短时间存储的信息，或者保存由于安全原因不应该写入客户端计算机上的磁盘的信息。例如，如果用户在使用一台公用计算机，而您不希望将 Cookie 写入该计算机的磁盘中，这时就可以使用非永久性 Cookie。

可以通过多种方法将 Cookie 添加到 Cookies 集合中。下面的示例演示两种编写 Cookie 的方法：
Response.Cookies["userName"].Value = "patrick";
Response.Cookies["userName"].Expires = DateTime.Now.AddDays(1);

HttpCookie aCookie = new HttpCookie("lastVisit");
aCookie.Value = DateTime.Now.ToString();
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);

此示例向 Cookies 集合添加两个 Cookie，一个名为 userName，另一个名为 lastVisit。
对于第一个 Cookie，Cookies 集合的值是直接设置的。可以通过这种方式向集合添加值，因为 Cookies 是从 NameObjectCollectionBase 类型的专用集合派生的。

对于第二个 Cookie，代码创建了一个 HttpCookie 类型的对象实例，设置其属性，然后通过 Add 方法将其添加到 Cookies 集合。在实例化 HttpCookie 对象时，必须将该 Cookie 的名称作为构造函数的一部分进行传递。

这两个示例都完成了同一任务，即向浏览器写入一个 Cookie。在这两种方法中，有效期值必须为 DateTime 类型。但是，lastVisited 值也是日期时间值。因为所有 Cookie 值都存储为字符串，因此，必须将日期时间值转换为 String。

多值 Cookie
可以在 Cookie 中存储一个值，如用户名和上次访问时间。
也可以在一个 Cookie 中存储多个名称/值对。名称/值对称为子键。（子键布局类似于 URL 中的查询字符串。）例如，不要创建两个名为 userName 和 lastVisit 的单独 Cookie，而可以创建一个名为 userInfo 的 Cookie，其中包含两个子键 userName 和 lastVisit。

您可能会出于多种原因来使用子键。首先，将相关或类似的信息放在一个 Cookie 中很方便。此外，由于所有信息都在一个 Cookie 中，所以诸如有效期之类的 Cookie 属性就适用于所有信息。（反之，如果要为不同类型的信息指定不同的到期日期，就应该把信息存储在单独的 Cookie 中。）

带有子键的 Cookie 还可帮助您限制 Cookie 文件的大小。正如前面“Cookie 的限制”一节中所提到的，Cookie 通常限制为 4096 字节，并且每个站点最多可存储 20 个 Cookie。使用带子键的单个 Cookie，使用的 Cookie 数就不会超过分配给站点的 20 个的限制。此外，一个 Cookie 会占用大约 50 个字符的系统开销（用于保存有效期信息等），再加上其中存储的值的长度，其总和接近 4096 字节的限制。如果存储五个子键而不是五个单独的 Cookie，便可节省单独 Cookie 的系统开销，节省大约 200 字节。

若要创建带子键的 Cookie，您可以使用编写单个 Cookie 的各种语法。
下面的示例演示用于编写同一 Cookie 的两种方法，其中的每个 Cookie 都带有两个子键：
Response.Cookies["userInfo"]["userName"] = "patrick";
Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();
Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);

HttpCookie aCookie = new HttpCookie("userInfo");
aCookie.Values["userName"] = "patrick";
aCookie.Values["lastVisit"] = DateTime.Now.ToString();
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);

控制 Cookie 的范围
默认情况下，一个站点的全部 Cookie 都一起存储在客户端上，而且所有 Cookie 都会随着对该站点发送的任何请求一起发送到服务器。也就是说，一个站点中的每个页面都能获得该站点的所有 Cookie。
但是，可以通过两种方式设置 Cookie 的范围：
1.将 Cookie 的范围限制到服务器上的某个文件夹，这允许您将 Cookie 限制到站点上的某个应用程序。
2.将范围设置为某个域，这允许您指定域中的哪些子域可以访问 Cookie。

将 Cookie 限制到某个文件夹或应用程序
若要将 Cookie 限制到服务器上的某个文件夹，请按下面的示例设置 Cookie 的 Path 属性：
HttpCookie appCookie = new HttpCookie("AppCookie");
appCookie.Value = "written " + DateTime.Now.ToString();
appCookie.Expires = DateTime.Now.AddDays(1);
appCookie.Path = "/Application1";
Response.Cookies.Add(appCookie);

路径可以是站点根目录下的物理路径，也可以是虚拟根目录。所产生的效果是 Cookie 只能用于 Application1 文件夹或虚拟根目录中的页面。例如，如果您的站点名称为 http://www.contoso.com/，则在前面示例中创建的 Cookie 将只能用于路径为 http://www.contoso.com/Application1/ 的页面以及该文件夹下的所有页面。但是，Cookie 将不能用于其他应用程序中的页面，如 http://www.contoso.com/Application2/ 或 http://www.contoso.com/ 中的页面。

注意:
在某些浏览器中，路径区分大小写。您无法控制用户如何在其浏览器中键入 URL，但如果应用程序依赖于与特定路径相关的 Cookie，请确保您创建的所有超链接中的 URL 与 Path 属性值的大小写相匹配。

默认情况下，一个站点的全部 Cookie 都一起存储在客户端上，而且所有 Cookie 都会随着对该站点发送的任何请求一起发送到服务器。也就是说，一个站点中的每个页面都能获得该站点的所有 Cookie。但是，可以通过两种方式设置 Cookie 的范围：

将 Cookie 的范围限制到服务器上的某个文件夹，这允许您将 Cookie 限制到站点上的某个应用程序。

将范围设置为某个域，这允许您指定域中的哪些子域可以访问 Cookie。

将 Cookie 限制到某个文件夹或应用程序
若要将 Cookie 限制到服务器上的某个文件夹，请按下面的示例设置 Cookie 的 Path 属性：
HttpCookie appCookie = new HttpCookie("AppCookie");
appCookie.Value = "written " + DateTime.Now.ToString();
appCookie.Expires = DateTime.Now.AddDays(1);
appCookie.Path = "/Application1";
Response.Cookies.Add(appCookie);
 
注意
还可以通过将 Cookie 直接添加到 Cookies 集合的方式来编写 Cookie，如先前的示例所示。
 

路径可以是站点根目录下的物理路径，也可以是虚拟根目录。所产生的效果是 Cookie 只能用于 Application1 文件夹或虚拟根目录中的页面。例如，如果您的站点名称为 http://www.contoso.com/，则在前面示例中创建的 Cookie 将只能用于路径为 http://www.contoso.com/Application1/ 的页面以及该文件夹下的所有页面。但是，Cookie 将不能用于其他应用程序中的页面，如 http://www.contoso.com/Application2/ 或 http://www.contoso.com/ 中的页面。

注意
在某些浏览器中，路径区分大小写。您无法控制用户如何在其浏览器中键入 URL，但如果应用程序依赖于与特定路径相关的 Cookie，请确保您创建的所有超链接中的 URL 与 Path 属性值的大小写相匹配。
 

限制 Cookie 的域范围
默认情况下，Cookie 与特定域关联。
例如，如果您的站点是 http://www.contoso.com/，那么当用户向该站点请求任何页时，您编写的 Cookie 就会被发送到服务器。（这可能不包括带有特定路径值的 Cookie。）如果站点具有子域（例如，contoso.com、sales.contoso.com 和 support.contoso.com），则可以将 Cookie 与特定的子域关联。
若要执行此操作，请设置 Cookie 的 Domain 属性，如此示例所示：
Response.Cookies["domain"].Value = DateTime.Now.ToString();
Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);
Response.Cookies["domain"].Domain = "support.contoso.com";

当以此方式设置域时，Cookie 将仅可用于指定的子域中的页面。还可以使用 Domain 属性创建可在多个子域间共享的 Cookie，如下面的示例所示：
Response.Cookies["domain"].Value = DateTime.Now.ToString();
Response.Cookies["domain"].Expires = DateTime.Now.AddDays(1);
Response.Cookies["domain"].Domain = "contoso.com";

随后 Cookie 将可用于主域，也可用于 sales.contoso.com 和 support.contoso.com 域。

读取 Cookie
浏览器向服务器发出请求时，会随请求一起发送该服务器的 Cookie。
在 ASP.NET 应用程序中，可以使用 HttpRequest 对象读取 Cookie，该对象可用作 Page 类的 Request 属性使用。HttpRequest 对象的结构与 HttpResponse 对象的结构基本相同，因此，可以从 HttpRequest 对象中读取 Cookie，并且读取方式与将 Cookie 写入 HttpResponse 对象的方式基本相同。
下面的代码示例演示两种方法，通过这两种方法可获取名为 username 的 Cookie 的值，并将其值显示在 Label 控件中：
if(Request.Cookies["userName"] != null)
    Label1.Text = Server.HtmlEncode(Request.Cookies["userName"].Value);

if(Request.Cookies["userName"] != null)
{
    HttpCookie aCookie = Request.Cookies["userName"];
    Label1.Text = Server.HtmlEncode(aCookie.Value);
}

在尝试获取 Cookie 的值之前，应确保该 Cookie 存在；如果该 Cookie 不存在，将会收到 NullReferenceException 异常。还请注意在页面中显示 Cookie 的内容前，先调用 HtmlEncode 方法对 Cookie 的内容进行编码。这样可以确保恶意用户没有向 Cookie 中添加可执行脚本。

注意
由于不同的浏览器存储 Cookie 的方式不同，因此，同一计算机上的不同浏览器没有必要能够读取彼此的 Cookie。例如，如果使用 Internet Explorer 测试一个页面，然后再使用其他浏览器进行测试，那么后者将不会找到 Internet Explorer 保存的 Cookie。

读取 Cookie 中子键值的方法与设置该值的方法类似。下面的代码示例演示获取子键值的一种方法：
if(Request.Cookies["userInfo"] != null)
{
    Label1.Text =
        Server.HtmlEncode(Request.Cookies["userInfo"]["userName"]);

    Label2.Text =
        Server.HtmlEncode(Request.Cookies["userInfo"]["lastVisit"]);
}

在上面的示例中，代码读取子键 lastVisit 的值，该值先前被设置为字符串表示形式的 DateTime 值。Cookie 将值存储为字符串，因此，如果要将 lastVisit 值作为日期使用，必须将其转换为适当的类型，如此示例所示：

DateTime dt;
dt = DateTime.Parse(Request.Cookies["userInfo"]["lastVisit"]);
 
Cookie 中的子键被类型化为 NameValueCollection 类型的集合。因此，获取单个子键的另一种方法是获取子键集合，然后再按名称提取子键值，如下面的示例所示：
if(Request.Cookies["userInfo"] != null)
{
    System.Collections.Specialized.NameValueCollection
        UserInfoCookieCollection;
      
    UserInfoCookieCollection = Request.Cookies["userInfo"].Values;
    Label1.Text =
        Server.HtmlEncode(UserInfoCookieCollection["userName"]);
    Label2.Text =
        Server.HtmlEncode(UserInfoCookieCollection["lastVisit"]);
}

更改 Cookie 的到期日期
浏览器负责管理 Cookie，而 Cookie 的到期时间和日期可帮助浏览器管理 Cookie 的存储。因此，虽然可以读取 Cookie 的名称和值，但无法读取 Cookie 的到期日期和时间。当浏览器向服务器发送 Cookie 信息时，并不包括有效期信息。（Cookie 的 Expires 属性始终返回值为 0 的日期时间值。）如果您担心 Cookie 的到期日期，必须重新设置该 Cookie。

注意
可以在向浏览器发送 Cookie 之前读取已在 HttpResponse 对象中设置的 Cookie 的 Expires 属性。但是，您无法从返回的 HttpRequest 对象中获取有效期。

读取 Cookie 集合
有时，您可能需要读取可供页面使用的所有 Cookie。若要读取可供页面使用的所有 Cookie 的名称和值，可以使用如下代码依次通过 Cookies 集合。
System.Text.StringBuilder output = new System.Text.StringBuilder();
HttpCookie aCookie;
for(int i=0; i<Request.Cookies.Count; i++)
{
    aCookie = Request.Cookies[i];
    output.Append("Cookie name = " + Server.HtmlEncode(aCookie.Name)
        + "<br />");
    output.Append("Cookie value = " + Server.HtmlEncode(aCookie.Value)
        + "<br /><br />");
}
Label1.Text = output.ToString();

注意
在运行此代码时，可能会看到一个名为 ASP.NET_SessionId 的 Cookie。ASP.NET 使用该 Cookie 来存储您的会话的唯一标识符。会话 Cookie 不会保存在您的硬盘上。

上面的示例有一个限制：如果 Cookie 有子键，则会以一个名称/值字符串来显示子键。可以读取 Cookie 的 HasKeys 属性，以确定 Cookie 是否有子键。如果有，则可以读取子键集合以获取各个子键名称和值。可以通过索引值直接从 Values 集合中读取子键值。相应的子键名称可在 Values 集合的 AllKeys 成员中获得，该成员将返回一个字符串数组。还可以使用 Values 集合的 Keys 成员。但是，首次访问 AllKeys 属性时，该属性会被缓存。相比之下，每次访问 Keys 属性时，该属性都生成一个数组。因此在同一页请求的上下文内，在随后访问时，AllKeys 属性要快得多。

下面的示例演示对前一示例的修改。该示例使用 HasKeys 属性来测试是否存在子键，如果检测到子键，便从 Values 集合获取子键：
for(int i=0; i<Request.Cookies.Count; i++)
{
    aCookie = Request.Cookies[i];
    output.Append("Name = " + aCookie.Name + "<br />");
    if(aCookie.HasKeys)
    {
        for(int j=0; j<aCookie.Values.Count; j++)
        {
            subkeyName = Server.HtmlEncode(aCookie.Values.AllKeys[j]);
            subkeyValue = Server.HtmlEncode(aCookie.Values[j]);
            output.Append("Subkey name = " + subkeyName + "<br />");
            output.Append("Subkey value = " + subkeyValue +
                "<br /><br />");
        }
    }
    else
    {
        output.Append("Value = " + Server.HtmlEncode(aCookie.Value) +
            "<br /><br />");
    }
}
Label1.Text = output.ToString();

或者，可将子键作为 NameValueCollection 对象提取，如下面的示例所示：
System.Text.StringBuilder output = new System.Text.StringBuilder();
HttpCookie aCookie;
string subkeyName;
string subkeyValue;

for (int i = 0; i < Request.Cookies.Count; i++)
{
    aCookie = Request.Cookies[i];
    output.Append("Name = " + aCookie.Name + "<br />");
    if (aCookie.HasKeys)
    {
        System.Collections.Specialized.NameValueCollection CookieValues =
            aCookie.Values;
        string[] CookieValueNames = CookieValues.AllKeys;
        for (int j = 0; j < CookieValues.Count; j++)
        {
            subkeyName = Server.HtmlEncode(CookieValueNames[j]);
            subkeyValue = Server.HtmlEncode(CookieValues[j]);
            output.Append("Subkey name = " + subkeyName + "<br />");
            output.Append("Subkey value = " + subkeyValue +
                "<br /><br />");
        }
    }
    else
    {
        output.Append("Value = " + Server.HtmlEncode(aCookie.Value) +
            "<br /><br />");
    }
}
Label1.Text = output.ToString();

修改和删除 Cookie
不能直接修改 Cookie。更改 Cookie 的过程涉及创建一个具有新值的新 Cookie，然后将其发送到浏览器来覆盖客户端上的旧版本 Cookie。
下面的代码示例演示如何更改存储用户对站点的访问次数的 Cookie 的值：
int counter;
if (Request.Cookies["counter"] == null)
    counter = 0;
else
{
    counter = int.Parse(Request.Cookies["counter"].Value);
}
counter++;

Response.Cookies["counter"].Value = counter.ToString();
Response.Cookies["counter"].Expires = DateTime.Now.AddDays(1);

删除 Cookie
删除 Cookie（即从用户的硬盘中物理移除 Cookie）是修改 Cookie 的一种形式。由于 Cookie 在用户的计算机中，因此无法将其直接移除。但是，可以让浏览器来为您删除 Cookie。该技术是创建一个与要删除的 Cookie 同名的新 Cookie，并将该 Cookie 的到期日期设置为早于当前日期的某个日期。当浏览器检查 Cookie 的到期日期时，浏览器便会丢弃这个现已过期的 Cookie。
下面的代码示例演示删除应用程序中所有可用 Cookie 的一种方法：
HttpCookie aCookie;
string cookieName;
int limit = Request.Cookies.Count;
for (int i=0; i<limit; i++)
{
    cookieName = Request.Cookies[i].Name;
    aCookie = new HttpCookie(cookieName);
    aCookie.Expires = DateTime.Now.AddDays(-1);
    Response.Cookies.Add(aCookie);
}

修改或删除子键
修改单个子键的方法与创建它的方法相同，如下面的示例所示：
Response.Cookies["userInfo"]["lastVisit"] = DateTime.Now.ToString();
Response.Cookies["userInfo"].Expires = DateTime.Now.AddDays(1);

若要删除单个子键，可以操作 Cookie 的 Values 集合，该集合用于保存子键。首先通过从 Cookies 对象中获取 Cookie 来重新创建 Cookie。然后您就可以调用 Values 集合的 Remove 方法，将要删除的子键的名称传递给 Remove 方法。接着，将 Cookie 添加到 Cookies 集合，这样 Cookie 便会以修改后的格式发送回浏览器。下面的代码示例演示如何删除子键。在此示例中，要移除的子键的名称在变量中指定。
string subkeyName;
subkeyName = "userName";
HttpCookie aCookie = Request.Cookies["userInfo"];
aCookie.Values.Remove(subkeyName);
aCookie.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(aCookie);

Cookie 和安全性
Cookie 的安全性问题与从客户端获取数据的安全性问题类似。在应用程序中，Cookie 是另一种形式的用户输入，因此很容易被他们非法获取和利用。由于 Cookie 保存在用户自己的计算机上，因此，用户至少能看到您存储在 Cookie 中的数据。用户还可以在浏览器向您发送 Cookie 之前更改该 Cookie。

千万不要在 Cookie 中存储敏感信息，如用户名、密码、信用卡号等等。不要在 Cookie 中放置任何不应由用户掌握的内容，也不要放可能被其他窃取 Cookie 的人控制的内容。

同样，不要轻信从 Cookie 中得到的信息。不要假定数据与您写出时相同；处理 Cookie 值时采用的安全措施应该与处理网页中用户键入的数据时采用的安全措施相同。本主题前面的示例演示在页面中显示值前，先对 Cookie 内容进行 HTML 编码的方法，这与在显示从用户处得到的任何信息之前的做法相同。

Cookie 以明文形式在浏览器和服务器间发送，任何可以截获 Web 通信的人都可以读取 Cookie。可以设置 Cookie 属性，使 Cookie 只能在使用安全套接字层 (SSL) 的连接上传输。SSL 并不能防止保存在用户计算机上的 Cookie 被读取或操作，但可防止 Cookie 在传输过程中被读取，因为 Cookie 已被加密。

确定浏览器是否接受 Cookie
用户可将其浏览器设置为拒绝接受 Cookie。在不能写入 Cookie 时不会引发任何错误。同样，浏览器也不向服务器发送有关其当前 Cookie 设置的任何信息。

注意
Cookies 属性不指示 Cookie 是否启用。它仅指示当前浏览器是否原本支持 Cookie。

确定 Cookie 是否被接受的一种方法是尝试编写一个 Cookie，然后再尝试读取该 Cookie。如果无法读取您编写的 Cookie，则可以假定浏览器不接受 Cookie。

下面的代码示例演示如何测试浏览器是否接受 Cookie。此示例由两个页面组成。第一个页面写出 Cookie，然后将浏览器重定向到第二个页面。第二个页面尝试读取该 Cookie。然后再将浏览器重定向回第一个页面，并将带有测试结果的查询字符串变量添加到 URL。
第一个页面的代码如下所示：
protected void Page_Load(object sender, EventArgs e)
{
    if (!Page.IsPostBack)
    {
        if (Request.QueryString["AcceptsCookies"] == null)
        {
            Response.Cookies["TestCookie"].Value = "ok";
            Response.Cookies["TestCookie"].Expires =
                DateTime.Now.AddMinutes(1);
            Response.Redirect("TestForCookies.aspx?redirect=" +
                Server.UrlEncode(Request.Url.ToString()));
        }
        else
        {
            Label1.Text = "Accept cookies = " +
                Server.UrlEncode(
                Request.QueryString["AcceptsCookies"]);
        }
    }
}

该页面首先测试以确定是不是回发，如果不是，则查找包含测试结果的查询字符串变量名 AcceptsCookies。如果不存在查询字符串变量，表示测试还未完成，因此代码会写出一个名为 TestCookie 的 Cookie。写出 Cookie 后，该示例调用 Redirect 来切换到 TestForCookies.aspx 测试页。附加到测试页 URL 的信息是一个名为 redirect 的查询字符串变量，该变量包含当前页的 URL；这样就能在执行测试后重定向回此页面。

测试页可完全由代码组成；不需要包含控件。下面的代码示例阐释了该测试页。
protected void Page_Load(object sender, EventArgs e)
{
    string redirect = Request.QueryString["redirect"];
    string acceptsCookies;
    if(Request.Cookies["TestCookie"] ==null)
        acceptsCookies = "no";
    else
    {
        acceptsCookies = "yes";
        // Delete test cookie.
        Response.Cookies["TestCookie"].Expires =
            DateTime.Now.AddDays(-1);
    }
    Response.Redirect(redirect + "?AcceptsCookies=" + acceptsCookies,
    true);
}

读取重定向查询字符串变量后，代码尝试读取 Cookie。出于管理目的，如果该 Cookie 存在，则立即删除。测试完成后，代码通过 redirect 查询字符串变量传递给它的 URL 构造一个新的 URL。新 URL 也包括一个包含测试结果的查询字符串变量。最后一步是使用新 URL 将浏览器重定向到最初页面。

该示例的一个改进是可将 Cookie 测试结果保存到永久存储区（如数据库）中，这样就不必在用户每次查看最初页面时都重复进行测试。（默认情况下，在会话状态中存储测试结果需要 Cookie。）

Cookie 和会话状态
当用户导航到您的站点时，服务器为该用户建立唯一的会话，会话将一直延续到用户访问结束。ASP.NET 会为每个会话维护会话状态信息，应用程序可在会话状态信息中存储用户特定信息。

ASP.NET 必须跟踪每个用户的会话 ID，以便可以将用户映射到服务器上的会话状态信息。默认情况下，ASP.NET 使用非永久性 Cookie 来存储会话状态。但是，如果用户已在浏览器上禁用 Cookie，会话状态信息便无法存储在 Cookie 中。

ASP.NET 提供了无 Cookie 会话作为替代。可以将应用程序配置为不将会话 ID 存储在 Cookie 中，而存储在站点中页面的 URL 中。如果应用程序依赖于会话状态，可以考虑将其配置为使用无 Cookie 会话。但是在较少的情况下，如果用户与他人共享 URL（可能是用户将 URL 发送给同事，而该用户的会话仍然处于活动状态），则最终这两个用户可能共享同一个会话，结果将难以预料。

总结
使用 Cookie 的优点
1.可配置到期规则:  
Cookie 可以在浏览器会话结束时到期，或者可以在客户端计算机上无限期存在，这取决于客户端的到期规则。
2.不需要任何服务器资源  
Cookie 存储在客户端并在发送后由服务器读取。
3.简单性  
Cookie 是一种基于文本的轻量结构，包含简单的键值对。
4.数据持久性  
虽然客户端计算机上 Cookie 的持续时间取决于客户端上的 Cookie 过期处理和用户干预，Cookie 通常是客户端上持续时间最长的数据保留形式。

使用 Cookie 的缺点
1.大小受到限制  
大多数浏览器对 Cookie 的大小有 4096 字节的限制，尽管在当今新的浏览器和客户端设备版本中，支持 8192 字节的 Cookie 大小已愈发常见。
2.用户配置为禁用  
有些用户禁用了浏览器或客户端设备接收 Cookie 的能力，因此限制了这一功能。
3.潜在的安全风险  
Cookie 可能会被篡改。用户可能会操纵其计算机上的 Cookie，这意味着会对安全性造成潜在风险或者导致依赖于 Cookie 的应用程序失败。另外，虽然 Cookie 只能被将它们发送到客户端的域访问，历史上黑客已经发现从用户计算机上的其他域访问 Cookie 的方法。您可以手动加密和解密 Cookie，但这需要额外的编码，并且因为加密和解密需要耗费一定的时间而影响应用程序的性能。

注意
Cookie 通常用于为已知用户自定义内容的个性化情况。在大多数此类情况中，Cookie 是作为“标识”而不是“身份验证”。因此，通常保护用于标识的 Cookie 的方法是在 Cookie 中存储用户名、帐户名或唯一用户 ID（例如 GUID），然后用以访问站点的用户个性化结构中的信息。

查询字苻串是追加在URL后的数据（也是我常用的）

例如：
http://www.cnblogs.com/aierong/admin/EditPosts.aspx?opt=abc
这里？后的opt=1就是查询字符串

当我们在一页面向另一页面传递数据时可以用此方法。

使用如下方法接到数据：
string str=Request.QueryString[“opt“]
这样str就等于“abc“

这里我们传递的是英文字符，要是传递中文字符，我们得进行编码和解吗：
傳送時用Server.UrlEncode方法編碼,接收時用Server.UrlDecode解碼.

例如：
传递：
string url=“http://www.cnblogs.com/aierong/admin/EditPosts.aspx?opt=“+Server.UrlEncode(“我们“);
Response.Redirect(url);
接收：
string str=Server.UrlDecode(Request.QueryString[“opt“]);
这样str就等于“我们“

当然我们还有一省事的方法：

在web.config中修改globalization节为
<globalization
            requestEncoding="gb2312"
            responseEncoding="gb2312"
/>

总结

查询字符串是在页 URL 的结尾附加的信息。

可以使用查询字符串来通过 URL 将数据提交回您的页或另一页上。
查询字符串提供一种维护某些状态信息的简单但有限的方法。
例如，它们是将信息从一页传送到另一页的简便的方法（例如，将产品号传递到将处理该产品号的另一页）。

使用查询字符串的优点
1.不需要任何服务器资源:查询字符串包含在对特定 URL 的 HTTP 请求中。
2.广泛的支持:几乎所有的浏览器和客户端设备均支持使用查询字符串传递值。
3.实现简单:ASP.NET完全支持查询字符串方法，其中包含了使用 HttpRequest 对象的Params属性读取查询字符串的方法。

使用查询字符串的缺点
1.潜在的安全性风险  
用户可以通过浏览器用户界面直接看到查询字符串中的信息。
用户可将此URL设置为书签或发送给别的用户，从而通过此URL传递查询字符串中的信息。
如果您担心查询字符串中的任何敏感数据，请考虑使用窗体（使用 POST而不是查询字符串）中的隐藏域。

2.有限的容量  
有些浏览器和客户端设备对URL的长度有2083个字符的限制。

ASP.NET 允许您使用应用程序状态来保存每个活动的 Web 应用程序的值，应用程序状态是 HttpApplicationState 类的一个实例。
应用程序状态是一种全局存储机制，可从 Web 应用程序中的所有页面访问。因此，应用程序状态可用于存储需要在服务器往返行程之间及页请求之间维护的信息。

应用程序状态存储在一个键/值字典中，在每次请求一个特定的 URL 期间就会创建这样一个字典。可以将特定于应用程序的信息添加到此结构以在页请求期间存储它。

一旦将应用程序特定的信息添加到应用程序状态中，服务器就会管理该对象。

应用程序状态是可用于 ASP.NET 应用程序中的所有类的数据储存库。
应用程序状态存储于服务器的内存中，并且比在数据库中存储和检索数据的速度更快。
与特定于单个用户会话的会话状态不同，应用程序状态应用于所有的用户和会话。
因此，应用程序状态非常适合存储那些数量少、不随用户的变化而变化的常用数据。

应用程序状态存储于 HttpApplicationState 类中，用户首次访问应用程序中的 URL 资源时将创建该类的新实例。
HttpApplicationState 类通过 Application 属性公开。

如何：从应用程序状态中读取值
应用程序状态存储类型化为 Object 的数据。因此，即使将数据存储于应用程序状态中时不必对其进行序列化，也必须在检索数据时将其强制转换为相应的类型。

确定应用程序变量是否存在，然后在访问该变量时将其转换为相应的类型。
下面的代码示例检索应用程序状态值 AppStartTime，并将其转换为一个 DateTime 类型的、名为 appStateTime 的变量。
if (Application["AppStartTime"] != null)
{
    DateTime myAppStartTime = (DateTime)Application["AppStartTime"];
}

如何：保存应用程序状态中的值
由于应用程序状态存储在服务器的内存中，因此应用程序状态中的大量数据可快速填充服务器内存。如果重新启动应用程序，应用程序状态数据便会丢失。应用程序状态无法在网络场中的多台服务器间或网络园中的辅