• 也谈 ASP.NET 1.1 中 QueryString 的安全获取写法


    刚才读到这个帖子:
    http://www.cnblogs.com/arielyang/archive/2006/01/16/318044.html?Pending=true#Post
    作者利用反射的方法,并且结合页面基类的做法,实现了一种 QueryString 的方便的读取方法。
    然而,在我看来,这种做法有些太重了。而我通常采用的做法如下叙述如下。
    在一个公共的方法类里面这样写,

    public class Util {
      
    private Util() {}

      
    // 从 querystring 集合中安全的取得一个 string. (总是不会有 null,所以叫做 'Safe')
      public static string GetStringSafeFromQueryString(Page page, string key) {
        
    string value = page.Request.QueryString[key];
        
    return (value == null? string.Empty : value;
      }

      
      
    // 在上述基础上,实现几个常用类型的获取方法。
      public static int GetInt32SafeFromQueryString(Page page, string key, int defaultValue) {
        
    string value = GetStringSafeFromQueryString(page, key);
        
    int i = defaultValue;
        
    try {
          i 
    = int.Parse(value);
        }
     catch {}
        
    return i;
      }

      
    // double 的实现
      public static double GetDoubleSafeFromQueryString(Page page,
        
    string key, double defaultValue) {
        
    string value = GetStringSafeFromQueryString(page, key);
        
    double d = defaultValue;
        
    try {
          d 
    = double.Parse(value);
        }
     catch {}
        
    return d;
      }

      
    // 同理可以写出 float,  的实现
    }

    在我的任何页面里面,要获取 querystring 的时候,只要这样就可以了:
    比如我要获取一个 string:
    string name = Util.GetStringSafeFromQueryString(this"name");
    if (name.Length > 0{
      
    // 进行正常的处理
    }
     else {
      
    // 不处理。
    }

    获取 int:
    int id = Util.GetInt32SafeFromQueryString(this"id"0);


    处理 double, float 等等方法完全一样。

    我认为就一个 QueryString 的处理没必要上升到反射的高度,其实有时候反过来想想,实现的那么复杂也许会丧失一定的灵活性。比如我某个值忽然要改为从 Form 里面得到呢?从 Session 得到呢?这时候就可以比较出哪种做法更适合敏捷的适应需求。

    页面里的 QueryString 的处理,之所以大家都很痛恨手工写编码,无非是因为这么几点:
    1. 需要判断是否 == null 才敢用 .ToString(), 很不爽。稍微不注意,就会抛出异常导致页面错误。
    2. 整形,double 等值类型从 QueryString 里面获取的时候,不知道是否为合法的数值,因此 Parse 的时候总是要写重复的处理异常的代码。

    归纳一下,其实,一个页面用下列语法获取一个 QueryString 的时候,他得到的是如下东西:
    (假设用 string name = Request.QueryString["name"]; 来获取。)
    1. ...test.aspx   得到 null
    2. ...test.aspx?name=     得到 ""
    3. ...test.aspx?name=abc  得到 "abc"

    我认为 1 和 2 的情况实际上从程序处理上来讲,是没有区别的。因此判断 null 没有必要,我们每次都将 null 的值自动让他转为 string.Empty 应该是比较安全的做法。

    基于上述理由,我觉得如我上面所写的简单的工具类,就可以轻量级的解决安全的读取 QueryString 的问题。

    有不对的地方,请大家多多指教。

  • 相关阅读:
    计算机原理 发展简史
    计算机原理 系统构成
    网络工程师级考试大纲
    软件工程师能力要求
    数据库主体在该数据库中拥有架构,无法删除解决方法
    【转】时时间已到。超时时间已到,但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用,并且达到了最大池大小。
    Rabbit mq订阅方式获取消息并可设置持久化
    OpenGL 核心技术之立方体贴图
    ArcGIS Engine问答:为什么地理数据库中不能产生同名要素类
    Cocos2d-X中的声音和音效
  • 原文地址:https://www.cnblogs.com/RChen/p/318561.html
Copyright © 2020-2023  润新知