在之前的文章里我們已經(jīng)談?wù)摿擞嘘P(guān)URL Rewrite的幾個(gè)主要的方面。在本系列的最后一篇文章中，我們就來(lái)討論一下有關(guān)不同級(jí)別URL Rewrite的一些細(xì)節(jié)與特點(diǎn)。

　　理論上說(shuō)，IIS級(jí)別的URL Rewrite使用C或C++編寫，比使用托管代碼編寫的ASP.NET級(jí)別URL Rewrite性能要高。但是我認(rèn)為這方面的差距在大部分情況下可以忽略不計(jì)，這種性能幾乎不可能成為性能瓶頸。因此選擇何種級(jí)別的URL Rewrite一般不會(huì)由您應(yīng)用程序的性能要求來(lái)決定。那么到底應(yīng)該使用哪種級(jí)別的URL Rewrite呢？在使用不同級(jí)別的URL Rewrite之后，我們又該注意點(diǎn)什么呢？我在這里談?wù)勎覀€(gè)人的看法。

對(duì)URL Rewrite功能上的要求

　　雖說(shuō)目前的URL Rewrite組件在功能上已經(jīng)能夠滿足大部分的應(yīng)用，但是在某些時(shí)候，我們的確還是會(huì)需要一些特殊的功能。例如根據(jù)域名進(jìn)行URL Rewrite，就目前的URL Rewrite組件來(lái)說(shuō)，想要實(shí)現(xiàn)這個(gè)并不容易。商業(yè)化的ISAPI Rewrite目前已經(jīng)可以支持這一點(diǎn)，可惜開(kāi)源的UrlRewriter.NET和IIRF在這方面功能都有所不足。它們都是根據(jù)請(qǐng)求相對(duì)于該站點(diǎn)的路徑來(lái)匹配，至于請(qǐng)求的是哪個(gè)域名并不能作為匹配條件來(lái)使用。這就要求我們對(duì)URL Rewrite組件進(jìn)行擴(kuò)展。對(duì)于大部分.NET開(kāi)發(fā)人員來(lái)說(shuō)，托管代碼自然是開(kāi)發(fā)首選，這時(shí)可能就要選擇ASP.NET級(jí)別的URL Rewrite重寫組件了。不過(guò)目前網(wǎng)上能找到不少擴(kuò)展的例子，無(wú)論是ASP.NET級(jí)別的UrlRewriter.NET還是IIS級(jí)別的IIRF。

　　不過(guò)事實(shí)上，如果要實(shí)現(xiàn)上述功能，我們也可以分兩步進(jìn)行。首先我們?cè)贗IS級(jí)別使用IIRF進(jìn)行URL Rewrite，接著在ASP.NET級(jí)別作進(jìn)一步的URL Rewrite。例如我們現(xiàn)在要實(shí)現(xiàn)將“http://jeffz.domain.com/articles”重寫為“/ArticleList.ASPx?owner=jeffz”，就可以先在讓IIRF做第一次URL Rewrite，目的是將“/articles”重寫至“/ArticleList.ASPx”。

RewriteRule    ^/Articles$    /ArticleList.ASPx      [I, L, U]

　　這樣，ASP.NET引擎就會(huì)直接接收到一個(gè)針對(duì)/ArticleList.ASPx的請(qǐng)求了。然后在ASP.NET內(nèi)部，我們可以作第二次的URL Rewrite（方便起見(jiàn)，我這里還是在Global.asax里寫，在項(xiàng)目中還是建議使用額外的HttpModule來(lái)實(shí)現(xiàn)）。

protected void Application_BeginRequest(object sender, EventArgs e)
{
    HttpContext context = HttpContext.Current;
 
    string host = context.Request.Url.Host;
    string owner = host.Substring(0, host.IndexOf('.'));
 
    context.RewritePath(context.Request.RawUrl + "?owner=" + owner);
}

　　經(jīng)過(guò)兩次URL Rewrite，已經(jīng)實(shí)現(xiàn)了我們想要的效果（在實(shí)際項(xiàng)目中，上面的代碼不能直接使用，因?yàn)樾枰袛嗍欠裼蠶uery String等等）。

　　此外，ASP.NET級(jí)別的URL Rewrite只能在ASP.NET里工作（顯然的事情），如果要讓URL Rewrite支持php，RoR等其他服務(wù)器技術(shù)，就只能使用IIS級(jí)別的URL Rewrite了（或者其他服務(wù)器技術(shù)提供的URL Rewrite功能）。

對(duì)URL中特殊字符的處理

　　有些特殊字符是不允許出現(xiàn)在URL中的，或者一旦出現(xiàn)在URL里以后，請(qǐng)求的含義就被改變了。例如我們需要對(duì)搜索頁(yè)面進(jìn)行URL Rewrite，將“/Search/xxx”重寫為“/Search.ASPx?xxx”，然后可以根據(jù)問(wèn)號(hào)后面的字符串獲得用戶提供的關(guān)鍵字。如果使用UrlRewriter.NET，我們就會(huì)使用如下的配置：

<rewriter>
  <rewrite url="^/Search/(.+)$" to="~/Search.ASPx?$1" processing="stop" />
rewriter>

　　普通情況下，這個(gè)URL Rewrite工作正常。但是如果用戶使用“%” 作為關(guān)鍵字，情況就不一樣了，因?yàn)槲覀儠?huì)收到如下的錯(cuò)誤頁(yè)面提示：

　　這是因?yàn)閁RL中是不允許出現(xiàn)“%”的。大家可以去各種網(wǎng)站上嘗試著請(qǐng)求一些例如“ABC%25DEF”的路徑（“%25”之后即為“%”），大都能發(fā)現(xiàn)“400 Bad Request”錯(cuò)誤。不過(guò)將“%”放在Query String里倒是合法的——對(duì)阿，我們不是將keyword重寫到Query String里了嗎？為什么還是不行呢？這還是由于ASP.NET執(zhí)行方式?jīng)Q定的。

　　Bad Request是在上圖的步驟3，也就是還在進(jìn)行初始化的時(shí)候就被確定了。而我們的URL Rewrite是在第4步BeginRequest事件中才發(fā)生的。當(dāng)請(qǐng)求中帶有非法字符時(shí)，我們根本還沒(méi)有機(jī)會(huì)進(jìn)行URL Rewrite。

　　那么我們?cè)趺刺幚磉@個(gè)問(wèn)題呢？在一般情況下，我們?cè)诳蛻舳藢?去除也不會(huì)有太大問(wèn)題（有些站點(diǎn)的確是這么做的），但是如果非要保留呢？那么就使用Query String來(lái)傳遞參數(shù)吧，或者我們也可以使用IIS級(jí)別的URL Rewrite。還是以IIRF為例：

RewriteRule    ^/Search/(.+)$    /Search.ASPx?$1      [I, L, U]

  當(dāng)請(qǐng)求被發(fā)送到IIS之后（步驟一），并且在選擇應(yīng)該交給哪個(gè)ISAPI執(zhí)行（步驟二）之前就發(fā)生了URL Rewrite。經(jīng)過(guò)了URL Rewrite之后的地址，其中的“%”已經(jīng)被轉(zhuǎn)移到了Query String中，這時(shí)候交由ASP.NET處理時(shí)自然已經(jīng)合法了。

出錯(cuò)頁(yè)面配置

　　最后我們來(lái)討論出錯(cuò)頁(yè)面的配置。例如，一般來(lái)說(shuō)我們都會(huì)為應(yīng)用配置一個(gè)404錯(cuò)誤頁(yè)面，這樣用戶在訪問(wèn)一個(gè)不存在的資源時(shí)我們可以給他查看一個(gè)特定的頁(yè)面，而不是默認(rèn)的錯(cuò)誤提示。但是在這一點(diǎn)上，不同級(jí)別的URL Rewrite就要使用不同的方法進(jìn)行配置。

　　如果我們使用了ASP.NET級(jí)別的URL Rewrite，一般來(lái)說(shuō)我們已經(jīng)在IIS里設(shè)置了Wildcard Mapping，這樣任意的請(qǐng)求（包括html，jpg等）都會(huì)交由ASP.NET處理。如果請(qǐng)求了一個(gè)不存在的資源，404錯(cuò)誤將由ASP.NET發(fā)出，因此404錯(cuò)誤頁(yè)面應(yīng)該在web.config中進(jìn)行配置：

<customErrors mode="On" defaultRedirect="GenericErrorPage.htm">
  <error statusCode="404" redirect="FileNotFound.htm" />
customErrors>

　　如果我們使用了IIS級(jí)別的Url Rewrite，我們不會(huì)配置Wildcard Mapping。也就是說(shuō)我們只有在Rewrite之后的地址為ASPx（或其他原本就該交由ASP.NET ISAPI處理）的情況下，ASP.NET引擎才會(huì)開(kāi)始工作。如果用戶請(qǐng)求了一個(gè)不存在的資源，那么404錯(cuò)誤將由IIS發(fā)出，這時(shí)候404錯(cuò)誤頁(yè)面應(yīng)該在IIS里進(jìn)行配置：

　　至此，有關(guān)URL Rewrite的話題已經(jīng)討論完了。在實(shí)際開(kāi)發(fā)中肯定還會(huì)遇到各種各樣不同的情況，但是只要理解了URL Rewrite方式的關(guān)鍵，按照程序運(yùn)行的方式來(lái)思考，相信一般情況下不太會(huì)遇到難以處理的問(wèn)題。

相關(guān)鏈接：

（1）IIS與ASP.NET

（2）使用已有組件進(jìn)行URL Rewrite

（3）在URL Rewrite后保持PostBack地址

NET技術(shù)：重提URL Rewrite（4）：不同級(jí)別URL Rewrite的一些細(xì)節(jié)與特點(diǎn)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。