国产成年人,在线www,国产一区h

　　可能已經(jīng)沒有人會使用上一篇文章中的方法進(jìn)行URL Rewrite了，因?yàn)樘峁︰RL Rewrite的組件早已鋪天蓋地了。

　　ASP.NET級別的URL Rewrite組件的原理很簡單，其實(shí)只是監(jiān)聽BeginRequest事件，并且根據(jù)配置來決定目標(biāo)URL。在我之前接觸過的項(xiàng)目中，發(fā)現(xiàn)使用URLRewriter作為URL Rewrite組件的頻率非常高，我想可能是因?yàn)槟鞘俏④浱峁┑臇|西吧。

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

<httpModules>
<add name="ModuleRewriter"
type="URLRewriter.ModuleRewriter, URLRewriter" />
httpModules>

　　然后就是進(jìn)行配置了（注：強(qiáng)烈建議使用configPath屬性將配置提取成額外的文件，便于管理）：

<configSections>
<section name="RewriterConfig"
           type="URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter" />
configSections>
<RewriterConfig>
<Rules>
    <RewriterRule>
      <LookFor>~/tag/([/w]+)/LookFor>
      <SendTo>~/Tags.ASPx?Tag=$1SendTo>
    RewriterRule>
Rules>
RewriterConfig>

　　正則表達(dá)式是一個(gè)非常了不得的東西，能匹配，能捕獲。在上面的例子中，我們把符合LookFor條件的“/tag/xxx”重新定位到Tags.ASPx頁面上，并且將xxx作為Tag這個(gè)QueryString項(xiàng)的值，這樣就能夠在代碼中通過HttpContext.Request.QueryString["Tag"]來獲得該值了。

　　URLRewriter的功能對于大多數(shù)應(yīng)用來說已經(jīng)足夠了，但是我總是不喜歡。但如果非要問我不喜歡的原因，我也難說出個(gè)子丑寅卯來。可能僅僅是這個(gè)配置方式的問題吧。在使用URL Rewriter時(shí)，配置段往往會非常長，每個(gè)配置項(xiàng)需要從到共4行代碼，一個(gè)規(guī)模不大的項(xiàng)目都很容易出現(xiàn)上百行的配置。“這也太XML了”，我想，為什么不用XML Attribute呢？這樣每個(gè)配置項(xiàng)就能縮短為1行了——不過，這是題外話。

　　所以如果我目前要做URL Rewrite，往往用的是Intelligencia出品的開源組件UrlRewriter.NET。雖然這個(gè)名字和前一個(gè)非常相似，但是功能卻遠(yuǎn)超前者。該組件在使用上和URLRewriter比較接近（其實(shí)似乎所有的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>

　　我們主要來看一下重寫規(guī)則的配置項(xiàng)。與URLRewriter不同的是，UrlRewriter.NET使用了我喜歡的每規(guī)則一個(gè)節(jié)點(diǎn)的方式，這讓整個(gè)項(xiàng)目的重寫規(guī)則簡潔不少。不過processing="stop"又是什么意思？這就要談到UrlRewriter.NET在處理重寫規(guī)則時(shí)的方法了。UrlRewriter.NET在找到一個(gè)匹配的重寫規(guī)則時(shí)，不會就此停止，而會繼續(xù)尋找其余的匹配項(xiàng)，最終生效的則是能夠匹配當(dāng)前請求的最后一個(gè)重寫規(guī)則。如果我們需要UrlRewriter.NET在找到某個(gè)匹配項(xiàng)之后即生效，就需要將processing屬性設(shè)為stop。例如在上面的配置里，如果“/User/”后緊跟著數(shù)字，則會使用用戶ID進(jìn)行查找，否則則認(rèn)為當(dāng)前所提供的是用戶名。

　　如果UrlRewriter.NET僅僅是因?yàn)榕渲蒙巷@得比較簡潔，它與URLRewriter相比實(shí)在沒有什么優(yōu)勢。但是UrlRewriter.NET的能力遠(yuǎn)不止此，我們剛才使用的其實(shí)只是它提供的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來“表示”復(fù)雜的邏輯。這哪還是配置，簡直就是編程了！沒錯(cuò)，用UrlRewriter.NET完全就可以通過配置來將一些請求——回復(fù)的邏輯表示出來，這無疑為我們帶來了很大的方便。在這里我不可能詳細(xì)說明UrlRewriter.NET的方方面面，感興趣的朋友可以從它官方網(wǎng)站所提供的Reference來一窺究竟。

　　“得組件如此，夫復(fù)何求”，不過我在這里還是要推薦另外一個(gè)組件。因?yàn)樵谀承┨厥馇闆r下，UrlRewriter.NET還不能滿足我們的要求。嗯？不是能自行擴(kuò)展嗎？沒錯(cuò)，可是——先賣個(gè)關(guān)子，本系列的最后一篇中來說明這個(gè)問題。UrlRewriter.NET提供了ASP.NET層面上的URL Rewriter。如果要在IIS層面上進(jìn)行URL Rewrite，那么還必須使用其他方式。ISAPI Rewrite是IIS層面上進(jìn)行URL Rewrite的著名組件，很可惜這是個(gè)商業(yè)組件，需要我們使用美刀來購買。因此我在這里推薦另一個(gè)開源產(chǎn)品：IIRF（Ionic's Isapi Rewrite Filter）。

　　由于是在IIS層面進(jìn)行URL Rewrite，IIRF的配置方式和UrlRewriter.NET是不同的。如果要使用IIRF，則需要將IsapiRewrite4.dll添加到Web Site的ISAPI Filter列表中：

Add 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的重寫規(guī)則是“RewriteRule []”，每個(gè)部分之間的空格數(shù)目沒有限制，不過一定要是空格，而不能是Tab等其他空白字符。“url-pattern”和“destination”自不必多說，關(guān)鍵在于modifier。IIRF的modifier有不少，在這里我先只介紹上面用到的兩個(gè)。“I”表示匹配時(shí)大小寫無關(guān)，“L”的作用和UrlRewriter.NET里的processing="stop"類似，IIRF在找到該匹配項(xiàng)時(shí)立即生效，而不會繼續(xù)查找下去。

　　IIRF雖然是一個(gè)開源的組件，但是功能依然比較強(qiáng)大。尤其是結(jié)合了RewriteCond（Rewrite Condition）之后，可以實(shí)現(xiàn)比較復(fù)雜的重寫規(guī)則。例如以下的配置則把UserAgent里包含Googlebot字樣的根目錄請求重寫到某個(gè)特定的資源上：

RewriteCond %{HTTP_USER_AGENT} ^Googlebot.*
RewriteRule ^/ $/Googlebot.html [L]

　　最后，我們來看一下兩種組件Rewrite的區(qū)別。顯然，最大的區(qū)別就在于它們是不同層面上的重寫，下面的兩幅示意圖就描述了在兩種情況下它們是如何將原本應(yīng)該得到“404 Resource Not Found”結(jié)果的“/User/jeffz”請求重寫至“/User/name=jeffz”的。

　　首先是UrlRewriter.NET在ASP.NET層面上的URL Rewrite：

<a href=/itjie/ASPjishu/ target=_blank class=infotextkey>ASP</a>.<a href=/itjie/NETjishu/ target=_blank class=infotextkey>NET</a>級別URL Rewrite