首頁>網絡編程教程>ASP.NET教程

URL Rewrite（2）：使用元件進行URL Rewrite

作者：Eve Cole 更新時間：2009-06-29 23:46:44
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、 ParLogger、Error Handler、Transform、Default Document、 ParLogger等功能，並且能夠通過 Parserger 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了。