可能已经没有人会使用上一篇文章中的方法进行URL Rewrite了，因为提供URL Rewrite的组件早已铺天盖地了。
ASP.NET级别的URL Rewrite组件的原理很简单，其实只是监听BeginRequest事件，并且根据配置来决定目标URL。在我之前接触过的项目中，发现使用URLRewriter作为URL Rewrite组件的频率非常高，我想可能是因为那是微软提供的东西吧。
如果要使用URLRewriter，首先自然就是在web.config中配置一个HttpModule：
<httpModules>
<add name="ModuleRewriter"
type="URLRewriter.ModuleRewriter, URLRewriter" />
</httpModules>
然后就是进行配置了（注：强烈建议使用configPath属性将配置提取成额外的文件，便于管理）：
<configSections>
<section name="RewriterConfig"
type="URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter" />
</configSections>
<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>~/tag/([\w]+)/</LookFor>
<SendTo>~/Tags.aspx?Tag=$1</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>
正则表达式是一个非常了不得的东西，能匹配，能捕获。在上面的例子中，我们把符合LookFor条件的“/tag/xxx”重新定位到Tags.aspx页面上，并且将xxx作为Tag这个QueryString项的值，这样就能够在代码中通过HttpContext.Request.QueryString["Tag"]来获得该值了。
URLRewriter的功能对于大多数应用来说已经足够了，但是我总是不喜欢。但如果非要问我不喜欢的原因，我也难说出个子丑寅卯来。可能仅仅是这个配置方式的问题吧。在使用URL Rewriter时，配置段往往会非常长，每个配置项需要从<RewriterRule>到</RewriterRule>共4行代码，一个规模不大的项目都很容易出现上百行的配置。“这也太XML了”，我想，为什么不用XML Attribute呢？这样每个配置项就能缩短为1行了——不过，这是题外话。
所以如果我目前要做URL Rewrite，往往用的是Intelligencia出品的开源组件UrlRewriter.NET。虽然这个名字和前一个非常相似，但是功能却远超前者。该组件在使用上和URLRewriter比较接近（其实似乎所有的URL Rewrite组件都差不多），我们要做的也只是配置：
<configSections>
<section name="rewriter"
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler,
Intelligencia.UrlRewriter" />
</configSections>
<rewriter>
<rewrite url="^/User/(\d+)$" to="~/User.aspx?id=$1" processing="stop" />
<rewrite url="^/User/(\w+)$" to="~/User.aspx?name=$1" processing="stop" />
</rewriter>
<system.web>
<httpModules>
<add name="UrlRewriter"
type="Intelligencia.UrlRewriter.RewriterHttpModule,
Intelligencia.UrlRewriter" />
</httpModules>
</system.web>
我们主要来看一下重写规则的配置项<rewriter />。与URLRewriter不同的是，UrlRewriter.NET使用了我喜欢的每规则一个节点的方式，这让整个项目的重写规则简洁不少。不过processing="stop"又是什么意思？这就要谈到UrlRewriter.NET在处理重写规则时的方法了。UrlRewriter.NET在找到一个匹配的重写规则时，不会就此停止，而会继续寻找其余的匹配项，最终生效的则是能够匹配当前请求的最后一个重写规则。如果我们需要UrlRewriter.NET在找到某个匹配项之后即生效，就需要将processing属性设为stop。例如在上面的配置里，如果“/User/”后紧跟着数字，则会使用用户ID进行查找，否则则认为当前所提供的是用户名。
如果UrlRewriter.NET仅仅是因为配置上显得比较简洁，它与URLRewriter相比实在没有什么优势。但是UrlRewriter.NET的能力远不止此，我们刚才使用的其实只是它提供的Action之一，初次之外它还提供了许多Action：
- if
- unless
- rewrite
- redirect
- setstatus
- forbidden
- gone
- not-allowed
- not-found
- not-implemented
- addheader
- setcookie
- setproperty
光有Action还不够，UrlRewriter.NET还提供了Condition、Transform、Default Document、 Parser、Error Handler、Logger等功能，并且能够通过Expression来“表示”复杂的逻辑。这哪还是配置，简直就是编程了！没错，用UrlRewriter.NET完全就可以通过配置来将一些请求——回复的逻辑表示出来，这无疑为我们带来了很大的方便。在这里我不可能详细说明UrlRewriter.NET的方方面面，感兴趣的朋友可以从它官方网站所提供的Reference来一窥究竟。
“得组件如此，夫复何求”，不过我在这里还是要推荐另外一个组件。因为在某些特殊情况下，UrlRewriter.NET还不能满足我们的要求。嗯？不是能自行扩展吗？没错，可是——先卖个关子，本系列的最后一篇中来说明这个问题。UrlRewriter.NET提供了ASP.NET层面上的URL Rewriter。如果要在IIS层面上进行URL Rewrite，那么还必须使用其他方式。ISAPI Rewrite是IIS层面上进行URL Rewrite的著名组件，很可惜这是个商业组件，需要我们使用美刀来购买。因此我在这里推荐另一个开源产品：IIRF（Ionic's Isapi Rewrite Filter）。
由于是在IIS层面进行URL Rewrite，IIRF的配置方式和UrlRewriter.NET是不同的。如果要使用IIRF，则需要将IsapiRewrite4.dll添加到Web Site的ISAPI Filter列表中：
IIRF是通过ini文件来配置的，IsapiRewrite4.ini与IsapiRewrite4.dll放在同样的目录中即可：
RewriteRule ^/User/(\d+)$ /User.aspx?id=$1 [I, L]
RewriteRule ^/User/(\w+)$ /User.aspx?name=$1 [I, L]
IIRF的重写规则是“RewriteRule <url-pattern> <destination> [<modifiers>]”，每个部分之间的空格数目没有限制，不过一定要是空格，而不能是Tab等其他空白字符。“url-pattern”和“destination”自不必多说，关键在于modifier。IIRF的modifier有不少，在这里我先只介绍上面用到的两个。“I”表示匹配时大小写无关，“L”的作用和UrlRewriter.NET里的processing="stop"类似，IIRF在找到该匹配项时立即生效，而不会继续查找下去。
IIRF虽然是一个开源的组件，但是功能依然比较强大。尤其是结合了RewriteCond（Rewrite Condition）之后，可以实现比较复杂的重写规则。例如以下的配置则把UserAgent里包含Googlebot字样的根目录请求重写到某个特定的资源上：
RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]
最后，我们来看一下两种组件Rewrite的区别。显然，最大的区别就在于它们是不同层面上的重写，下面的两幅示意图就描述了在两种情况下它们是如何将原本应该得到“404 Resource Not Found”结果的“/User/jeffz”请求重写至“/User/name=jeffz”的。
首先是UrlRewriter.NET在ASP.NET层面上的URL Rewrite：
接着是IIRF在IIS层面上的URL Rewrite：
有了这两个组件，相信我们已经再也不需要其他东西来实现URL Rewrite了。
相关链接：
（1）IIS与ASP.NET
（3）在URL Rewrite后保持PostBack地址
（4）不同级别URL Rewrite的一些细节与特点