细说 Request[]与Request.Params[]

时间  2019-11-30
标签 细说 request request.params params 繁體版
原文   原文链接

细说 Request[]与Request.Params[]

今天我来谈一谈容易被人混淆的二个集合：Request[]与Request.Params[]ajax

这二个集合我在博客【我心目中的Asp.net核心对象】中就提到过它们， 并且还给出了一个示例，并以截图的形式揭示过它们的差异。但因为那篇博客中有更多有价值的对象要介绍， 所以也就没有花太多的篇幅着重介绍这二个集合。但我发现，不知道这二个集合差异的人确实太多，以致于我认为颇有必要为它们写个专题来细说它们的差异了。数据库

在ASP.NET编程中，有三个比较常见的来自于客户端的数据来源：QueryString, Form, Cookie 。 咱们能够在HttpRequest中访问这三大对象， 好比，能够从QueryString中获取包含在URL中的一些参数， 能够从Form中获取用户输入的表单数据， 能够从Cookie中获取一些会话状态以及其它的用户个性化参数信息。 除了这三大对象，HttpRequest还提供ServerVariables来让咱们获取一些来自于Web服务器变量。 一般，这4个数据来源都很明确，我想没人会混淆它们。编程

通常状况下，若是咱们在事先就能明确知道某个参数是来源于哪一个集合，那么直接访问那个集合，问题也就简单了。 然而，更常见的数据来源一般只会是QueryString, Form ，并且尤为是当在客户端使用Jquery的$.ajax()这类技术时， 能够很随意地将参数放到QueryString或者是Form中，那么，服务端一般为了也能灵活地应对这一现况， 可使用Request[]与Request.Params[] 这二种方式来访问这些来自于用户提交的数据。 本文的故事也所以而产生了：Request[]与Request.Params[] 有什么差异？？浏览器

回顾博客原文

因为【我心目中的Asp.net核心对象】有对它们的一些介绍以及示例截图， 无奈，有些人可能因为各类缘由，没看到那段文字，这里我也只好再贴一次了：服务器

这二个属性均可以让咱们方便地根据一个KEY去【同时搜索】QueryString、Form、Cookies 或 ServerVariables这4个集合。 一般若是请求是用GET方法发出的，那咱们通常是访问QueryString去获取用户的数据，若是请求是用POST方法提交的， 咱们通常使用Form去访问用户提交的表单数据。而使用Params，Item可让咱们在写代码时没必要区分是GET仍是POST。 这二个属性惟一不一样的是：Item是依次访问这4个集合，找到就返回结果，而Params是在访问时，先将4个集合的数据合并到一个新集合(集合不存在时建立)， 而后再查找指定的结果。
为了更清楚地演示这们的差异，请看如下示例代码：cookie

<body>    
    <p>Item结果：<%= this.ItemValue %></p>
    <p>Params结果：<%= this.ParamsValue %></p>
    
    <hr />
    
    <form action="<%= Request.RawUrl %>" method="post">
        <input type="text" name="name" value="123" />
        <input type="submit" value="提交" />
    </form>
</body>

 

public partial class ShowItem : System.Web.UI.Page
{
    protected string ItemValue;
    protected string ParamsValue;

    protected void Page_Load(object sender, EventArgs e)
    {
        string[] allkeys = Request.QueryString.AllKeys;
        if( allkeys.Length == 0 )
            Response.Redirect("ShowItem.aspx?name=abc", true);


        ItemValue = Request["name"];
        ParamsValue = Request.Params["name"];        
    }
}

页面在未提交前浏览器的显示：并发

点击提交按钮后，浏览器的显示：工具

差异很明显，我也很少说了。说下个人建议吧：尽可能不要使用Params，不光是上面的结果致使的判断问题， 不必多建立一个集合出来吧，并且更糟糕的是写Cookie后，也会更新集合。post

正如我前面所说的客观缘由：因为那篇博客中有更多有价值的对象要介绍，所以也就没有花太多的篇幅着重介绍这二个集合。 下面，我来仔细地说说它们的差异。

实现方式分析

前面的示例中，我演示了在访问Request[]与Request.Params[] 时获得了不一样的结果。为何会有不一样的结果呢，我想咱们仍是先去看一下微软在.net framework中的实现吧。

首先，咱们来看一下Request[]的实现，它是一个默认的索引器，实现代码以下：

public string this[string key]
{
    get
    {
        string str = this.QueryString[key];
        if( str != null ) {
            return str;
        }
        str = this.Form[key];
        if( str != null ) {
            return str;
        }
        HttpCookie cookie = this.Cookies[key];
        if( cookie != null ) {
            return cookie.Value;
        }
        str = this.ServerVariables[key];
        if( str != null ) {
            return str;
        }
        return null;
    }
}

这段代码的意思是：根据指定的key，依次访问QueryString，Form，Cookies，ServerVariables这4个集合，若是在任意一个集合中找到了，就当即返回。

Request.Params[]的实现以下：

public NameValueCollection Params
{
    get
    {
        //if (HttpRuntime.HasAspNetHostingPermission(AspNetHostingPermissionLevel.Low))
        //{
        //    return this.GetParams();
        //}
        //return this.GetParamsWithDemand();

        // 为了便于理解，我注释了上面的代码，其实关键仍是下面的调用。
        return this.GetParams();
    }
}
private NameValueCollection GetParams()
{
    if( this._params == null ) {
        this._params = new HttpValueCollection(0x40);
        this.FillInParamsCollection();
        this._params.MakeReadOnly();
    }
    return this._params;
}
private void FillInParamsCollection()
{
    this._params.Add(this.QueryString);
    this._params.Add(this.Form);
    this._params.Add(this.Cookies);
    this._params.Add(this.ServerVariables);
}

它的实现方式是：先判断_params这个Field成员是否为null，若是是，则建立一个集合，并把QueryString，Form，Cookies，ServerVariables这4个集合的数据所有填充进来， 之后的查询都直接在这个集合中进行。

咱们能够看到，这是二个大相径庭的实现方式。也就是由于这个缘由，在某些特殊状况下访问它们获得的结果将会不同。 
不同的缘由是：Request.Params[]建立了一个新集合，并合并了这4个数据源，遇到同名的key，天然结果就会不一样了。

再谈Cookie

在博客【我心目中的Asp.net核心对象】中， 说到Request.Params[]时，我简单地说了一句：并且更糟糕的是写Cookie后，也会更新集合。 如何理解这句话呢？

我想咱们仍是来看一下咱们是如何写一个Cookie，并发送到客户端的吧。下面我就COPY一段 【细说Coookie】中的一段原文吧：

Cookie写入浏览器的过程：咱们可使用以下代码在Asp.net项目中写一个Cookie 并发送到客户端的浏览器（为了简单我没有设置其它属性）。

HttpCookie cookie = new HttpCookie("MyCookieName", "string value");
Response.Cookies.Add(cookie);

代码的关键点在于调用了Response.Cookies.Add()，咱们来看看它们是如何实现的。首先来看Response.Cookies

public HttpCookieCollection Cookies
{
    get
    {
        if (this._cookies == null)
        {
            this._cookies = new HttpCookieCollection(this, false);
        }
        return this._cookies;
    }
}

再来看HttpCookieCollection这个集合的实现：

public sealed class HttpCookieCollection : NameObjectCollectionBase
{
    public HttpCookieCollection() : base(StringComparer.OrdinalIgnoreCase)
    {
    }

    internal HttpCookieCollection(HttpResponse response, bool readOnly) 
        : base(StringComparer.OrdinalIgnoreCase)
    {
        this._response = response;
        base.IsReadOnly = readOnly;
    }

    public void Add(HttpCookie cookie)
    {
        if (this._response != null)
        {
            this._response.BeforeCookieCollectionChange();
        }
        this.AddCookie(cookie, true);
        if (this._response != null)
        {
            this._response.OnCookieAdd(cookie);
        }
    }

注意：因为在HttpResponse中建立HttpCookieCollection时，把HttpResponse对象传入了，所以，在调用HttpCookieCollection.Add()方法时， 会调用HttpResponse的OnCookieAdd(cookie); 咱们接着看：

internal void OnCookieAdd(HttpCookie cookie)
{
    this.Request.AddResponseCookie(cookie);
}

又转到Request对象的调用了，接着看：

internal void AddResponseCookie(HttpCookie cookie)
{
    if (this._cookies != null)
    {
        this._cookies.AddCookie(cookie, true);
    }
    if (this._params != null)
    {
        this._params.MakeReadWrite();
        this._params.Add(cookie.Name, cookie.Value);
        this._params.MakeReadOnly();
    }
}

从以上的代码分析中，咱们能够看到，咱们调用Response.Cookies.Add()时，Cookie也会加到HttpRequest.Cookies中。
并且，若是咱们访问过程Request.Params[]，也会加到那个集合中。

再谈NameValueCollection

本文一开始的示例中，为何代码 ParamsValue = Request.Params["name"]; 获得的结果是：【abc,123】？

根据前面示例代码咱们能够得知：abc这个值是由QueryString提供的，123这值是由Form提供的，最后由Request.Params[]合并在一块儿了就变成这个样子了。 有没有人想过：为何合起来就变成了这个样子了呢？

要回答这个问题，咱们须要回顾一下Params的定义：

public NameValueCollection Params

注意：它的类型是NameValueCollection 。MSDN对这个集合有个简单的说明：

此集合基于 NameObjectCollectionBase 类。但与 NameObjectCollectionBase 不一样，该类在一个键下存储多个字符串值。

为了便于你们更容易理解这个类的工做方式，我画了一张草图：

【name】这个key对应差一个ArrayList，而那个ArrayList中，包含了二个字符串：abc 和 123 ，这就是它的工做方式。

既然它能在一个键值下存储多个字符串，那咱们就来看一下它究竟是如何实现的，直接转到Add()方法：（注意我在代码中添加的注释）

public virtual void Add(string name, string value)
{
    if( base.IsReadOnly ) {
        throw new NotSupportedException(SR.GetString("CollectionReadOnly"));
    }
    this.InvalidateCachedArrays();

    // 这是一个关键的调用，它调用基类，获得每一个name对应的元素，
    // 而每一个name对应的元素是一个ArrayList
    ArrayList list = (ArrayList)base.BaseGet(name);

    if( list == null ) {
        // 若是不存在name对应的元素，则建立ArrayList
        list = new ArrayList(1);
        if( value != null ) {
            // 添加value到ArrayList，它将是第一个值
            list.Add(value);
        }
        base.BaseAdd(name, list);
    }
    else if( value != null ) {
        // 在原有的ArrayList中继续添加新的值
        list.Add(value);
    }
}

咱们再来看一下当咱们访问Params[]这个索引器时，.net framework又是如何实现的：

public string this[string name]
{
    get { return this.Get(name); }
    set { this.Set(name, value); }
}
public virtual string Get(string name)
{
    // 根据name获得ArrayList
    ArrayList list = (ArrayList) base.BaseGet(name);
    // 将ArrayList变成一个字符串行
    return GetAsOneString(list);
}

private static string GetAsOneString(ArrayList list)
{
    int num = (list != null) ? list.Count : 0;
    if( num == 1 ) {
        return (string)list[0];
    }
    if( num <= 1 ) {
        return null;
    }
    StringBuilder builder = new StringBuilder((string)list[0]);
    for( int i = 1; i < num; i++ ) {
        builder.Append(',');    // 逗号就来源于此。
        builder.Append((string)list[i]);
    }
    return builder.ToString();
}

如今，您该明白了为何当一个key有多个值时，为何会用逗号分开来了吧。

或许，看到这里，您又有了一个新的想法：对于有多值的状况，还要我来按逗号拆分它们，太麻烦了，有没有不要拆分的方法呢？

答案是：有的，您能够访问NameValueCollection的GetValues方法，这个方法的实现以下：

public virtual string[] GetValues(string name)
{
    ArrayList list = (ArrayList)base.BaseGet(name);
    return GetAsStringArray(list);
}
private static string[] GetAsStringArray(ArrayList list)
{
    int count = (list != null) ? list.Count : 0;
    if( count == 0 ) {
        return null;
    }
    string[] array = new string[count];
    list.CopyTo(0, array, 0, count);
    return array;
}

我想结果必定是您所期待的，它是一个string[] ，咱们能够方便的遍历它：

string[] array = Request.Params.GetValues("name");
if( array != null )
    foreach(string val in array)

再谈QueryString, Form

前面我解释了NameValueCollection的工做原理，并揭示了Request.Params["name"]; 获得【abc,123】这个结果的缘由。
事实上，这个怪异的结果有时并不仅是Params会有，一样的故事还可能由QueryString, Form这二个对象上演（最终会在Request[]那里也有体现）。

我仍是拿【我心目中的Asp.net核心对象】的示例来讲明吧：

protected void Page_Load(object sender, EventArgs e)
{
    string[] allkeys = Request.QueryString.AllKeys;
    if( allkeys.Length == 0 )
        Response.Redirect(
            Request.RawUrl + "?aa=1&bb=2&cc=3&aa=" + HttpUtility.UrlEncode("5,6,7"), true);

    StringBuilder sb = new StringBuilder();
    foreach( string key in allkeys )
        sb.AppendFormat("{0} = {1}<br />", 
            HttpUtility.HtmlEncode(key), HttpUtility.HtmlEncode(Request.QueryString[key]));

    this.labResult.Text = sb.ToString();
}

页面最终显示结果以下（注意键值为aa的结果）：

示例代码中，开始部分用于检查URL是否包含参数，若是没有，则加入一些参数。写成这样的缘由是： 第一次访问这个页面时，URL中确定是不包含参数的，为了能演示，因此我就加了一些固定的参数，这样便于后面的讲解。

这个示例也演示了：遇到同名的多个值，用逗号分开的作法，并非Params才会有的，QueryString也可能会有， 固然，Form也逃不掉这个特性的缠绕，不过，我如今倒想举个有使用价值的示例。

我有这样一个录入界面（左边），并但愿最终的录入结果以右图的方式显示：

我想这个功能的实现并不难，但如何作才是最简单呢？

下面我贴出个人实现方法，你们看看算不算比较容易：

    <tr><td style="vertical-align: top">项目类型</td><td>
    <% foreach( string pt in AppHelper.ProjectTypes ) { %>
        <label><input type="checkbox" name="ProjectType" value="<%= pt %>" /><%= pt%></label><br />
    <% } %>
        </td></tr>

注意：全部的checkbox的name都是同样的。

服务端嘛，我认为没有必要再贴代码了，我想您懂的。

在这个示例中，我正好利用了NameValueCollection的这个特色，让它帮我实现了这个逗号分隔的效果，要否则，我还得本身去作！

如何处理冲突

经过前面的一些示例，咱们能够看到并不是只有Params[]会有冲突，只要类型是NameValueCollection的数据源，都有这个问题。
我要再重申一次：QueryString, Form，Param都有这样的冲突问题，只是Param须要合并４种数据源，它将冲突的机率变大了。

那么，咱们如何正确的处理这类冲突呢？ 还记得我前面提到的NameValueCollection的GetValues方法吧，也只好用它了。（除非你愿意本身手工拆分字符串） 而后再用一个循环就能够访问全部冲突值了，就像下面这样：

string[] array = Request.Params.GetValues("name");
if( array != null )
    foreach(string val in array)

注意：Request[]的返回结果是一个字符串，就不能使用这种方法。可是，它的冲突机率要少不少。

如今，还有个现实的问题：QueryString, Form是最经常使用的数据源，咱们要不要这样处理它呢？
这的确是个很现实的问题，我认为在回答这个问题前，咱们须要分析一下这二个集合出现KEY冲突时是个什么样子的。

1. "abc.aspx?id=1 &id=2" 在这URL中，我想问问各位：看到这个URL，您会怎么想？我认为它是错的，错在拼接URL的操做中。 其次，我认为URL的修改或者拼接一般由一个工具类来控制，咱们有理由保证它不会出现冲突，毕竟范围相应较小，咱们容易给出这个保证。 所以，我认为，直接访问QueryString能够忽略这种冲突的可能。

2. 表单数据中name重复的状况。我认为这个集合却是有可能出现冲突，但也极有多是咱们故意安排的，就像前面的示例同样。 其次，表单的内容在开发阶段相对固定，各个输入控件的name也是比较清楚的，不存在动态变换的可能，所以， 我认为，直接访问Form也能够忽略这种冲突的可能。

另外一方面，咱们平时写QueryString[], Form[]都太习惯了，这样的代码太多了，也不可能改为循环的判断， 所以，咱们只能尽可能保证在一个数据源的范围内，它们是不重复的。 事实上，前二个集合一般仅仅与某一个页面相关，范围也相对较小，更容易保证。 所以，若是有了这个保证，在访问这二类集合时，忽略冲突也是可接受的。

可是，Params须要合并４种数据源，尤为是包含Cookies，ServerVariables这二类对象并不是与某个页面相关，它们是全局的， 所以冲突的可能性会更大，因此，我认为：若是您要访问Params[]，那么，请改为Params.GetValues() ，由于这样才更合适。

Request[]仍是Request.Params[] ??

前面说了这么多，我想Request[]和Request.Params[]的差异，此次应该是说清楚了，到此也该给个结论了： 到底选择Request[]仍是Request.Params[] ？？

我想不少人应该会比较关注这个答案，这里我也想说说个人观点，不过，我要说明一点： 本文的全部文字，都只表示个人我的观点，仅供参考。

我认为：要想清楚地回答这个问题，有必要从二个角度再来观察这两者：常见用法和设计缘由。

1. 常见用法: 我一直认为设计这二个集合是为了方便，让咱们能够没必要区分GET, POST而直接获得所需的用户数据。 若是没有这二个集合，而咱们又须要不区分GET,POST时，显然就要本身去实现这类的集合， 而在本身实现时，也极有可能是先尝试访问QueryString, 若是没有，再去找Form ...。看到了吗，这不正是Request[]的实现方式吗？ 也正是基于这个前提，遇到前面那种【abc,123】场景时，Request[]获得的结果或许更符合咱们的预期。毕竟在获取到结果后， 咱们会基于结果作一些判断，好比：name参数可能对应一个数据库的表字段，用它能够找到一个实际数据行， 若是结果是abc或者是123，这时程序都能处理（都有匹配的记录），但来个【abc,123】，这个还真无法处理了。

另外一方面，在前面的例子中，我也解释了这并非Params[]特有的，QueryString, Form都有这样的问题，天然地Request[]也有这个问题， 只是因为Params须要合并4类数据源，让这种冲突的机会更大了。

说到这里，有必要再来谈谈前面的几个例子，【abc,123】中，name在QueryString, Form中重复了，显然这属于不合理的设计， 现实状况中，应该是不会产生这类事情的，除非偶然。不过，当偶然的不幸发生时，也正好能体现这两者的差异了。 至于我前面所举的几个例子，虽然在现实中不太可能会出现，但个人意图是在向您展现这些技术的细节差别， 展现一些可能偶然会发生的状况，所以，请不要认为那是个技术误导。

2. 设计缘由：让咱们再从设计严谨性这个角度来看待这两者的差异，仍是拿【abc,123】这个例子来讲吧， Request[]这种依次判断的方式，显然会遗漏一些信息，所以，从严谨性这个角度来看，Request[]是不完美的。 毕竟，最终用户会如何以某种想法使用这二个API，没人知道。微软是设计平台的，他们不得不考虑这个问题，不设计这二个集合， 是.net framework的不完善，用错了，就是咱们本身的错了。

基于以上观点，我给出个人4点意见：1. 不建议使用Params[]，由于：a. 不但愿被偶然状况影响，b. 较高的使用成本。2. Request[] 使用简单，适合要求不高的场合：示例代码。3. 若是须要兼顾性能和易用性，能够模仿Request[]自行设计。（一般并不须要访问4个集合）4. 了解差别，体会细节，有时会发现它仍是有利用价值的。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程