可能已經沒有人會使用上一篇文章中的方法進行URL Rewrite了，因為提供URL Rewrite的元件早已鋪天蓋地了。

ASP.NET級別的URL Rewrite元件的原理很簡單，其實只是監聽BeginRequest事件，並且根據配置來決定目標URL。在我之前接觸過的專案中，發現使用URLRewriter作為URL Rewrite元件的頻率非常高，我想可能是因為那是微軟提供的東西吧。

如果要使用URLRewriter，首先自然就是在web.config中配置一個HttpModule：

<httpModules>
<addname="ModuleRewriter"
type="URLRewriter.ModuleRewriter, URLRewriter
 
" />
</httpModules>

然後就是進行配置了（注：強烈建議使用configPath屬性將配置提取成額外的檔案，便於管理）：

<configSections>
<sectionname="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>
<sectionname="rewriter"
type="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler,
Intelligencia.UrlRewriter" />
</configSections>

<rewriter>
<rewriteurl="^/User/(\d+)$"to="~/User.aspx?id=$1"processing="stop" />
<rewriteurl="^/User/(\w+)$"to="~/User.aspx?name=$1"processing="stop" />
</rewriter>

<system.web>
<httpModules>
<addname="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了。

相關連結：