URL重写，可以理解为"伪静态"，那实际上它并不是一个真正的静态页，我们在发出一个页面请求的时候发现其url很类似于或者类似于;  URL是没有任何参数。

　　我们这里是以一个文章发布版块为例，上面的网址我们看起来非常清晰简单，没有带任何参数；但在实际开发中，我们不可能为每篇文章都去新建一个aspx页面，这样太浪费资源了，因为每篇文章在页面中显示的格式都是一致，那么我们就会考虑根据文章的 ID 来获取不同文章的数据从而进行显示。也就是可以把文章ID作为请求参数,那实际请求就应该是或;

　　

　　这样问题就好解决了，我们的实质任务是要访问这样带参数的网页，但我们要求在发出页面请求的时候地址栏的url要呈现或，这里就要用到URL重写的技术了；同样是访问页面，那为什么就要将原来带参数的url显示为不带参数的url呢，就是我们为什么要使用URL重写技术？

 　　　　

　　URL重写对我们来说有什么好处：1.网页名称更准确，比较好看（其实好看不好看倒也无所谓） 2.利于SEO，增加网页的“权重”，这样利于搜索引擎收录页面（这也是坊间传说）；

　　

 　　我们暂且认为它有这么点好处吧，那如何实现？ HttpContext.Current.RewritePath("url");这就是url重写的核心方法，但在我们使用这个方法之前必须得了解 网页发出请求之后服务器是如何处理的

在asp.net应用程序中我们会发现有一个全局文件Global.asax，全局文件中有个方法 

       void Application_Start(object sender, EventArgs e)

        {

            // 在应用程序启动时运行的代码

        }

　　很明显这就是当应用程序启动时会执行这里的代码，同样我们每次发出页面请求时也会执行到这里，而且不管应用程序中是否存在该页面，每次同样会执行到这个方法（可以通过断点调试，随便给个不存在的页面，都会执行到这里）；

 

　　1.现在就可以到这个方法里面进行URL重写了，还是以文章列表为例，我们在页面前台显示文章目录时（把每个目录都可以做成一个超链接），超链接的地址就可以以这种形式显示（'1’--即通过前台获取后台数据源的文章列表的id），这样我们点击超链接的时候地址栏就会出现不带参数的url了；

     2.在全局文件的Application_Start(object sender, EventArgs e)方法中进行重写：

　　

void Application_Start(object sender, EventArgs e)        {            // 在应用程序启动时运行的代码            //获取来自客户端请求的url虚拟地址（HttpContext.Current.Request.Url也可以）            string url = HttpContext.Current.Request.AppRelativeCurrentExecutionFilePath;            //正则匹配请求的url是否符合我们规定的格式            Match match = Regex.Match(url, @"~/Art-(\d+)\.aspx");            if (match.Success)            {                //如果匹配成功，获取id参数                string id = match.Groups[1].Value;                //进行重写，内部执行 请求实际页面                HttpContext.Current.RewritePath("~Art.aspx?id=" + id);            }        }

　　　这样就达到我们的需求了；其实，微软曾在.net framework 1.1中提供过一个名为URLRewriter的小工具供开发人员轻松实现UrlRewrite；再者，我们还可以通过ASP.net的Http请求管道进行重写。

个人认为通过我们上述自己手写代码更能清楚的知道URL重写的的整个实现过程。