本頁內(nèi)容

	引言
	URL 重寫的常見用法
	請求到達(dá) IIS 時將會發(fā)生什么情況
	實(shí)現(xiàn) URL 重寫
	構(gòu)建 URL 重寫引擎
	使用 URL 重寫引擎執(zhí)行簡單的 URL 重寫
	創(chuàng)建真正“可刪節(jié)”的 URL
	結(jié)論
	參考資料

引言

讓我們花點(diǎn)時間來看一下網(wǎng)站上的一些 URL。您是否發(fā)現(xiàn)一些類似于 http:///info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary 的 URL？或者，您可能將一系列網(wǎng)頁從一個目錄或網(wǎng)站移動到另一個目錄或網(wǎng)站，結(jié)果導(dǎo)致已將舊 URL 用作書簽的訪問者斷開鏈接。在本文中，我們將了解如何通過將 http:///info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary 替換為類似于 http:///people/sales/chuck.smith 的網(wǎng)址，使用 URL 重寫將那些冗長的 URL 縮寫為富有意義且容易記憶的 URL。我們還將了解如何將 URL 重寫用于創(chuàng)建智能 404 錯誤。

URL 重寫是截取傳入 Web 請求并自動將請求重定向到其他資源的過程。執(zhí)行 URL 重寫時，通常會檢查被請求的 URL，并基于 URL 的值將請求重定向到其他 URL。例如，在進(jìn)行網(wǎng)站重組而將 /people/ 目錄下的所有網(wǎng)頁移動到 /info/employees/ 目錄中時，您可能希望使用 URL 重寫來檢查 Web 請求是否指向了 /people/ 目錄中的文件。如果請求指向 /people/ 目錄中的文件，您可能希望自動將請求重定向到 /info/employees/ 目錄中的同一文件。

使用傳統(tǒng)的 ASP，應(yīng)用 URL 重寫的唯一方法是編寫 ISAPI 篩選器，或者購買提供 URL 重寫功能的第三方產(chǎn)品。但是，使用 Microsoft? ASP.NET，您可以通過很多方法來輕松地創(chuàng)建您自己的 URL 重寫軟件。本文討論了可供 ASP.NET 開發(fā)人員實(shí)現(xiàn) URL 重寫的各種技術(shù)，然后討論了 URL 重寫的一些實(shí)際使用情況。在深入討論 URL 重寫的技術(shù)細(xì)節(jié)之前，讓我們先看一些可以使用 URL 重寫的日常情景。

返回頁首

URL 重寫的常見用法

創(chuàng)建數(shù)據(jù)驅(qū)動的 ASP.NET 網(wǎng)站時，通常會產(chǎn)生一個單個的網(wǎng)頁，該網(wǎng)頁基于查詢字符串參數(shù)顯示數(shù)據(jù)庫數(shù)據(jù)的子集。例如，在設(shè)計(jì)電子商務(wù)站點(diǎn)時，您的任務(wù)之一便是允許用戶瀏覽待售產(chǎn)品。為此，您可以創(chuàng)建一個名為 displayCategory.aspx 的頁面，該頁面將顯示給定類別的產(chǎn)品。可以通過查詢字符串參數(shù)來指定要查看的該類別的產(chǎn)品。也就是說，如果用戶要瀏覽待售的 Widget 產(chǎn)品，并且所有 Widget 產(chǎn)品的 CategoryID 均為 5，則用戶可以訪問以下網(wǎng)址：http:///displayCategory.aspx?CategoryID=5。

創(chuàng)建具有此類 URL 的網(wǎng)站有兩點(diǎn)不足：首先，從最終用戶的角度考慮，URL http:///displayCategory.aspx?CategoryID=5 比較雜亂?？捎眯詫＜?Jakob Neilsen建議遵循以下標(biāo)準(zhǔn)來選擇 URL：

我還要增加一條標(biāo)準(zhǔn)，即，URL 應(yīng)該便于記憶。URL http:///displayCategory.aspx?CategoryID=5 不符合 Neilsen 的任何標(biāo)準(zhǔn)，也不容易記住。要求用戶鍵入查詢字符串值將使 URL 的鍵入變得非常困難，并且只有了解查詢字符串參數(shù)的用途及其名稱/值對結(jié)構(gòu)的富有經(jīng)驗(yàn)的 Web 開發(fā)人員才能夠?qū)?URL 進(jìn)行“刪節(jié)”。

較好的方法是允許使用切合實(shí)際且容易記憶的 URL，如 http:///products/Widgets。只要看一眼 URL，您便可以推斷出將要顯示的內(nèi)容 -- 有關(guān) Widget 的信息。此 URL 也很容易記住和共享。我可以告訴我的同事“請查看 /products/Widgets，”，她可能無需再次問我 URL 是什么即可打開該頁面。（嘗試一下，您只需說出“Amazon.com 頁面”即可?。┐?URL 還將顯示出來，并且應(yīng)該是“可刪節(jié)”的。也就是說，如果用戶刪去 URL 的末端，鍵入 http:///products，他們應(yīng)該看到所有產(chǎn)品的列表，或者至少應(yīng)該看到他們可以查看的所有類別的產(chǎn)品列表。

注意：要獲得“可刪節(jié)”URL 的最好示例，可考慮使用由許多 blog 引擎生成的 URL。要查看 2004 年 1 月 28 日的帖子，用戶可以訪問諸如 http:///2004/01/28 的 URL。如果該 URL 被刪節(jié)為 http:///2004/01，用戶將看到 2004 年 1 月的所有帖子。將該 URL 進(jìn)一步刪節(jié)為 http:///2004 將顯示 2004 年的所有帖子。

除了簡化 URL 之外，URL 重寫還經(jīng)常用于處理網(wǎng)站重組，以免導(dǎo)致大量鏈接斷開或書簽過期。

返回頁首

請求到達(dá) IIS 時將會發(fā)生什么情況

在正式研究 URL 如何實(shí)現(xiàn)重寫之前，應(yīng)首先了解 Microsoft? Internet Information Services (IIS) 如何處理傳入請求，這一點(diǎn)非常重要。當(dāng)請求到達(dá) IIS Web 服務(wù)器時，IIS 檢查被請求文件的擴(kuò)展名以確定如何處理該請求。IIS 可以自行處理請求（如 HTML 頁面、圖像以及其他靜態(tài)內(nèi)容），或者將請求路由到 ISAPI 擴(kuò)展。（ISAPI 擴(kuò)展是一個處理傳入 Web 請求的非托管編譯類。其任務(wù)是生成被請求資源的內(nèi)容。）

例如，當(dāng)傳入針對 Info.asp 網(wǎng)頁的請求時，IIS 會將此消息路由到 asp.dll ISAPI 擴(kuò)展。然后，該 ISAPI 擴(kuò)展將加載被請求的 ASP 頁面，執(zhí)行該頁面，并將所呈現(xiàn)的 HTML 返回給 IIS，然后，IIS 將該 HTML 發(fā)送回請求客戶端。對于 ASP.NET 頁面，IIS 會將此消息路由到 aspnet_isapi.dll ISAPI 擴(kuò)展。然后，aspnet_isapi.dll ISAPI 擴(kuò)展將處理操作傳遞給托管的 ASP.NET 輔助進(jìn)程，該輔助程序?qū)⑻幚碚埱?，并返?ASP.NET 網(wǎng)頁的呈現(xiàn) HTML。

您可以自定義 IIS，以指定擴(kuò)展名與 ISAPI 擴(kuò)展的映射關(guān)系。圖 1 顯示了 Internet Information Services 管理工具的“應(yīng)用程序配置”對話框。請注意，與 ASP.NET 有關(guān)的擴(kuò)展名（.aspx、ascx、config、asmx、rem、cs、vb 及其他）均已映射到 aspnet_isapi.dll ISAPI 擴(kuò)展。

圖 1. 已配置的文件擴(kuò)展名映射

討論 IIS 如何管理傳入請求稍稍超出了本文范圍。但是可以在 Michele Leroux Bustamante 的文章 Inside IIS and ASP.NET 中找到對此內(nèi)容的深入討論。ASP.NET 引擎僅處理那些擴(kuò)展名已明確映射至 IIS 中的 aspnet_isapi.dll 的傳入 Web 請求，了解這一點(diǎn)非常重要。

使用 ISAPI 篩選器檢查請求

IIS 除了可以將傳入 Web 請求的文件擴(kuò)展名映射到相應(yīng)的 ISAPI 擴(kuò)展之外，還將執(zhí)行許多其他任務(wù)。例如，IIS 將嘗試對發(fā)出請求的用戶進(jìn)行身份驗(yàn)證，并確定通過身份驗(yàn)證的用戶是否有權(quán)限訪問被請求的文件。在處理請求的有效期內(nèi)，IIS 將經(jīng)歷幾個狀態(tài)。在每個狀態(tài)下，IIS 都將引發(fā)可以使用 ISAPI 篩選器以編程方式進(jìn)行處理的事件。

與 ISAPI 擴(kuò)展一樣，ISAPI 篩選器是在 Web 服務(wù)器上安裝的非托管代碼塊。ISAPI 擴(kuò)展被設(shè)計(jì)為可以響應(yīng)針對特定文件類型的請求。另一方面，ISAPI 篩選器還包含可以對 IIS 引發(fā)的事件進(jìn)行響應(yīng)的代碼。ISAPI 篩選器可以截取甚至修改傳入和傳出的數(shù)據(jù)。ISAPI 篩選器可以應(yīng)用于很多方面，包括：

雖然 ISAPI 篩選器可用于執(zhí)行 URL 重寫，但本文將討論如何使用 ASP.NET 實(shí)現(xiàn) URL 重寫。不過，我們將對使用 ISAPI 篩選器與使用 ASP.NET 中的技術(shù)實(shí)現(xiàn) URL 重寫進(jìn)行權(quán)衡。

請求進(jìn)入 ASP.NET 引擎時將會發(fā)生什么情況

在 ASP.NET 之前，需要使用 ISAPI 篩選器來實(shí)現(xiàn) IIS Web 服務(wù)器上的 URL 重寫。由于 ASP.NET 引擎與 IIS 非常相似，因此可以使用 ASP.NET 進(jìn)行 URL 重寫。存在相似之處的原因在于 ASP.NET 引擎可以實(shí)現(xiàn)以下功能：

與 IIS 一樣，ASP.NET 引擎在請求的有效期內(nèi)將會觸發(fā)事件，通過發(fā)信號來表示其處理過程從一個狀態(tài)改變?yōu)榱肆硪粋€狀態(tài)。例如，當(dāng) ASP.NET 引擎首次響應(yīng)請求時，BeginRequest 事件將被觸發(fā)。接下來觸發(fā)的是 AuthenticateRequest 事件，該事件在已建立用戶標(biāo)識時出現(xiàn)。（此外，還有大量的其他事件：AuthorizeRequest、ResolveRequestCache 和 EndRequest，等等。這些事件屬于 System.Web.HttpApplication 類；有關(guān)詳細(xì)信息，請參閱位于以下網(wǎng)址的技術(shù)文檔：HttpApplication Class Overview。）

正如上一部分所討論的，可以創(chuàng)建 ISAPI 篩選器以響應(yīng) IIS 引發(fā)的事件。同樣，ASP.NET 提供了 HTTP 模塊，該模塊可以響應(yīng)由 ASP.NET 引擎引發(fā)的事件。可以將 ASP.NET Web 應(yīng)用程序配置為具有多個 HTTP 模塊。對于由 ASP.NET 引擎處理的每個請求，將初始化每個已配置的 HTTP 模塊，并允許將事件處理程序綁定到處理請求期間所引發(fā)的事件。請注意，對每個請求均使用了許多內(nèi)置 HTTP 模塊。其中的一個內(nèi)置 HTTP 模塊是 FormsAuthenticationModule，該模塊首先檢查是否使用了窗體身份驗(yàn)證，如果使用，將檢查是否對用戶進(jìn)行了身份驗(yàn)證。如果沒有使用，會自動將用戶重定向到指定的登錄頁面。

如上所述，通過使用 IIS，傳入請求將最終發(fā)送給 ISAPI 擴(kuò)展，而 ISAPI 擴(kuò)展的任務(wù)是返回特定請求的數(shù)據(jù)。例如，在請求傳統(tǒng)的 ASP 網(wǎng)頁時，IIS 將請求傳遞給 asp.dll ISAPI 擴(kuò)展，該擴(kuò)展的任務(wù)是返回被請求的 ASP 頁面的 HTML 標(biāo)記。ASP.NET 引擎使用相似的方法。初始化 HTTP 模塊后，ASP.NET 引擎的下一項(xiàng)任務(wù)是確定應(yīng)由哪個 HTTP 處理程序來處理請求。

所有通過 ASP.NET 引擎?zhèn)鬟f的請求最終都將到達(dá) HTTP 處理程序或 HTTP 處理程序工廠（HTTP 處理程序工廠僅返回 HTTP 處理程序的實(shí)例，然后使用該實(shí)例來處理請求）。最終的 HTTP 處理程序?qū)⒎祷仨憫?yīng)，即呈現(xiàn)被請求的資源。此響應(yīng)將被發(fā)送回 IIS，然后 IIS 將響應(yīng)返回給提出請求的用戶。

ASP.NET 包括許多內(nèi)置的 HTTP 處理程序。例如，PageHandlerFactory 用于呈現(xiàn) ASP.NET 網(wǎng)頁。WebServiceHandlerFactory 用于呈現(xiàn) ASP.NET Web 服務(wù)的響應(yīng) SOAP 信封。TraceHandler 將向 trace.axd 呈現(xiàn)請求的 HTML 標(biāo)記。

圖 2 描述了如何處理對 ASP.NET 資源的請求。首先，IIS 接收到請求，并將請求調(diào)度給 aspnet_isapi.dll。接下來，ASP.NET 引擎對已配置的 HTTP 模塊進(jìn)行初始化。最后將調(diào)用正確的 HTTP 處理程序，并呈現(xiàn)被請求的資源，將所生成的標(biāo)記返回給 IIS 和請求客戶端。

圖 2. IIS 和 ASP.NET 正在處理請求

創(chuàng)建和注冊自定義 HTTP 模塊和 HTTP 處理程序

創(chuàng)建自定義 HTTP 模塊和 HTTP 處理程序是相對簡單的任務(wù)，包括創(chuàng)建實(shí)現(xiàn)正確接口的托管類。HTTP 模塊必須實(shí)現(xiàn) System.Web.IHttpModule 接口，而 HTTP 處理程序和 HTTP 處理程序工廠必須分別實(shí)現(xiàn) System.Web.IHttpHandler 接口和 System.Web.IHttpHandlerFactory 接口。創(chuàng)建 HTTP 處理程序和 HTTP 模塊的細(xì)節(jié)超出了本文的范圍。要獲得詳細(xì)的背景知識，請閱讀 Mansoor Ahmed Siddiqui 的文章 HTTP Handlers and HTTP Modules in ASP.NET。

創(chuàng)建了自定義 HTTP 模塊或 HTTP 處理程序之后，必須將其注冊到 Web 應(yīng)用程序。為整個 Web 服務(wù)器注冊 HTTP 模塊和 HTTP 處理程序僅需在 machine.config 文件中進(jìn)行簡單的添加即可；而為特定 Web 應(yīng)用程序注冊 HTTP 模塊或 HTTP 處理程序包括向應(yīng)用程序的 Web.config 文件中添加幾行 XML。

特別要說明的是，要將 HTTP 模塊添加到 Web 應(yīng)用程序，應(yīng)在 Web.config 的 configuration/system.web 部分添加以下幾行：

<httpModules>
<add type="type" name="name" />
</httpModules>

type 值提供了 HTTP 模塊的程序集和類名稱，而 name 值提供了友好名稱，可以在 Global.asax 文件中使用此友好名稱來引用 HTTP 模塊。

Web.config 的 configuration/system.web 部分中的 <httpHandlers> 標(biāo)記對 HTTP 處理程序和 HTTP 處理程序工廠進(jìn)行了配置，如下所示：

<httpHandlers>
<add verb="verb" path="path" type="type" />
</httpHandlers>

如上所述，對于每個傳入請求，ASP.NET 引擎將確定應(yīng)使用哪個 HTTP 處理程序來呈現(xiàn)請求。此決定是基于傳入請求的動詞和路徑做出的。動詞將指定所作出的 HTTP 請求的類型（GET 或 POST），而路徑將指定被請求文件的位置和文件名。因此，如果我們希望 HTTP 處理程序處理對擴(kuò)展名為 .scott 的文件的所有請求（GET 或 POST），可以在 Web.config 文件中添加下面幾行：

<httpHandlers>
<add verb="*" path="*.scott" type="type" />
</httpHandlers>

其中，type 是 HTTP 處理程序的類型。

注意：注冊 HTTP 處理程序時，應(yīng)確保 HTTP 處理程序使用的擴(kuò)展名已從 IIS 映射到 ASP.NET 引擎，這一點(diǎn)非常重要。也就是說，在本 .scott 示例中，如果 .scott 擴(kuò)展名沒有從 IIS 映射到 aspnet_isapi.dll ISAPI 擴(kuò)展，則對文件 foo.scott 的請求將導(dǎo)致 IIS 試圖返回文件 foo.scott 的內(nèi)容。為了使 HTTP 處理程序可以處理此請求，必須將 .scott 擴(kuò)展名映射到 ASP.NET 引擎。然后，ASP.NET 引擎將把請求正確地路由到相應(yīng)的 HTTP 處理程序。

有關(guān)注冊 HTTP 模塊和 HTTP 處理程序的詳細(xì)信息，請務(wù)必參考 <httpModules> element documentation 和 <httpHandlers> element documentation。

返回頁首

實(shí)現(xiàn) URL 重寫

可以使用 ISAPI 篩選器在 IIS Web 服務(wù)器級別實(shí)現(xiàn) URL 重寫，也可以使用 HTTP 模塊或 HTTP 處理程序在 ASP.NET 級別實(shí)現(xiàn) URL 重寫。本文重點(diǎn)介紹如何使用 ASP.NET 實(shí)現(xiàn) URL 重寫，因此我們將不對使用 ISAPI 篩選器實(shí)現(xiàn) URL 重寫的細(xì)節(jié)進(jìn)行深入探討。但是，有大量的第三方 ISAPI 篩選器可用于 URL 重寫，例如：

通過 System.Web.HttpContext 類的 RewritePath() 方法，可以在 ASP.NET 級別實(shí)現(xiàn) URL 重寫。HttpContext 類包含有關(guān)特定 HTTP 請求的 HTTP 特定信息。對于 ASP.NET 引擎收到的每個請求，均為該請求創(chuàng)建一個 HttpContext 實(shí)例。此類具有如下屬性：Request 和 Response，提供對傳入請求和傳出響應(yīng)的訪問；Application 和 Session，提供對應(yīng)用程序和會話變量的訪問；User，提供有關(guān)通過了身份驗(yàn)證的用戶的信息；其他相關(guān)屬性。

使用 Microsoft? .NET Framework Version 1.0，RewritePath() 方法可以接受單個字符串作為要使用的新路徑。HttpContext 類的 RewritePath(string) 方法在內(nèi)部對 Request 對象的 Path 屬性和 QueryString 屬性進(jìn)行更新。除了 RewritePath(string)，.NET Framework 1.1 還包括另一種形式的 RewritePath() 方法，此方法可以接受三個字符串輸入?yún)?shù)。此備用重載形式不僅要設(shè)置 Request 對象的 Path 屬性和 QueryString 屬性，還要設(shè)置內(nèi)部成員變量，這些變量用于計(jì)算 Request 對象的 PhysicalPath、PathInfo 和 FilePath 屬性值。

要在 ASP.NET 中實(shí)現(xiàn) URL 重寫，需要創(chuàng)建 HTTP 模塊或 HTTP 處理程序，以便完成以下操作：

例如，假設(shè)我們的網(wǎng)站中包含每個員工通過 /info/employee.aspx?empID=employeeID 均可訪問的信息。為了使 URL 可以更多地被“刪節(jié)”，我們可以決定通過以下地址來訪問員工頁面：/people/EmployeeName.aspx。這就是我們要使用 URL 重寫的一個例子。也就是說，在請求 /people/ScottMitchell.aspx 頁面時，我們要重寫該 URL，以便使用 /info/employee.aspx?empID=1001 頁面。

使用 HTTP 模塊執(zhí)行 URL 重寫

在 ASP.NET 級別執(zhí)行 URL 重寫時，可以使用 HTTP 模塊或 HTTP 處理程序來執(zhí)行重寫。使用 HTTP 模塊時，必須決定在請求有效期內(nèi)的哪個時間點(diǎn)上來檢查 URL 是否需要重寫。乍一看，這似乎可以任意選擇，但決定會以一種明顯而微妙的方式對應(yīng)用程序產(chǎn)生影響。由于內(nèi)置 ASP.NET HTTP 模塊使用 Request 對象的屬性執(zhí)行任務(wù)，因此選擇在何處執(zhí)行重寫非常重要。（如上所述，重寫路徑將改變 Request 對象的屬性值。）下面列出了這些密切相關(guān)的內(nèi)置 HTTP 模塊及其捆綁到的事件：

如上所述，BeginRequest 事件在 AuthenticateRequest 之前觸發(fā)，后者在 AuthenticateRequest 之前觸發(fā)。

可以執(zhí)行 URL 重寫的一個安全位置是在 BeginRequest 事件中。也就是說，如果 URL 需要重寫，該操作將在任何一個內(nèi)置 HTTP 模塊運(yùn)行后執(zhí)行。使用窗體身份驗(yàn)證時，這種方法存在一定的缺陷。如果您以前使用過窗體身份驗(yàn)證，您會了解當(dāng)用戶訪問受限資源時，他們將被自動重定向到指定的登錄頁面。成功登錄后，用戶將被返回到他們第一次嘗試訪問的頁面。

如果在 BeginRequest 或 AuthenticateRequest 事件中執(zhí)行 URL 重寫，登錄頁面（提交后）將把用戶重定向到重寫后的頁面上。也就是說，假設(shè)用戶在其瀏覽窗口中鍵入了 /people/ScottMitchell.aspx，此地址將被重寫為 /info/employee.aspx?empID=1001。如果將 Web 應(yīng)用程序配置為使用窗體身份驗(yàn)證，當(dāng)用戶第一次訪問 /people/ScottMitchell.aspx 時，首先，URL 將被重寫為 /info/employee.aspx?empID=1001；接下來，FormsAuthenticationModule 將運(yùn)行，并將用戶重定向到登錄頁面（如果需要）。但是，用戶在成功登錄后將被發(fā)送到 /info/employee.aspx?empID=1001，因?yàn)楫?dāng) FormsAuthenticationModule 運(yùn)行后，此 URL 即是請求的 URL。

同樣，在 BeginRequest 或 AuthenticateRequest 事件中執(zhí)行重寫時，UrlAuthorizationModule 看到的將是重寫后的 URL。也就是說，如果您在 Web.config 文件中使用 <location> 元素來為特定的 URL 指定授權(quán)，則必須引用重寫后的 URL。

要解決這些細(xì)微問題，您可以決定在 AuthorizeRequest 事件中執(zhí)行 URL 重寫。此方法解決了 URL 授權(quán)和窗體身份驗(yàn)證的一些問題，但同時也產(chǎn)生了新的問題：文件授權(quán)無法工作。使用 Windows 身份驗(yàn)證時，FileAuthorizationModule 將檢查以確保通過身份驗(yàn)證的用戶具有訪問特定 ASP.NET 頁面的相應(yīng)權(quán)限。

假設(shè)一組用戶對 C:\Inetput\wwwroot\info\employee.aspx 沒有 Windows 級別的文件訪問權(quán)限，并要嘗試訪問 /info/employee.aspx?empID=1001，他們將會收到授權(quán)錯誤消息。但是，如果我們將 URL 重寫移到 AuthenticateRequest 事件中，當(dāng) FileAuthorizationModule 檢查安全設(shè)置時，仍然認(rèn)為被請求的文件是 people/ScottMitchell.aspx，因?yàn)樵?URL 必須被重寫。因此，文件授權(quán)檢查將通過，允許此用戶查看重寫后的 URL /info/employee.aspx?empID=1001 的內(nèi)容。

那么，應(yīng)該何時在 HTTP 模塊中執(zhí)行 URL 重寫？這取決于要使用的身份驗(yàn)證類型。如果不想使用任何身份驗(yàn)證，則無論 URL 重寫發(fā)生在 BeginRequest、AuthenticateRequest 還是 AuthorizeRequest 中都沒有什么關(guān)系。如果要使用窗體身份驗(yàn)證而不使用 Windows 身份驗(yàn)證，請將 URL 重寫放在 AuthorizeRequest 事件處理程序中執(zhí)行。最后，如果要使用 Windows 身份驗(yàn)證，請?jiān)?BeginRequest 或 AuthenticateRequest 事件進(jìn)行過程中安排 URL 重寫。

在 HTTP 處理程序中執(zhí)行 URL 重寫

也可以由 HTTP 處理程序或 HTTP 處理程序工廠執(zhí)行 URL 重寫。如上所述，HTTP 處理程序是負(fù)責(zé)生成特定類型請求的內(nèi)容的類；HTTP 處理程序工廠是負(fù)責(zé)返回 HTTP 處理程序?qū)嵗念悾搶?shí)例可以生成特定類型請求的內(nèi)容。

在本文中，我們將對如何為 ASP.NET 網(wǎng)頁創(chuàng)建 URL 重寫 HTTP 處理程序工廠進(jìn)行討論。HTTP 處理程序工廠必須實(shí)現(xiàn) IHttpHandlerFactory 接口，此接口包括 GetHandler() 方法。初始化相應(yīng)的 HTTP 模塊后，ASP.NET 引擎將確定為給定的請求調(diào)用哪個 HTTP 處理程序或 HTTP 處理程序工廠。如果要調(diào)用 HTTP 處理程序工廠，ASP.NET 引擎將為 Web 請求調(diào)用傳入 HttpContext 的 HTTP 處理程序工廠的 GetHandler() 方法，以及一些其他信息。然后，HTTP 處理程序工廠必須返回一個對象，該對象將實(shí)現(xiàn)可以處理請求的 IHttpHandler。

要通過 HTTP 程序程序執(zhí)行 URL 重寫，我們可以創(chuàng)建一個 HTTP 處理程序工廠，該處理程序工廠的 GetHandler() 方法將檢查被請求的路徑，以確定是否需要重寫 URL。如果需要，它可以調(diào)用傳入的 HttpContext 對象的 RewritePath() 方法，如前面所討論的。最后，HTTP 處理程序工廠可以返回由 System.Web.UI.PageParser 類的 GetCompiledPageInstance() 方法返回的 HTTP 處理程序。（此技術(shù)與內(nèi)置 ASP.NET 網(wǎng)頁 HTTP 處理程序工廠 PageHandlerFactory 工作時所應(yīng)用的技術(shù)相同。）

由于所有 HTTP 模塊都將在實(shí)例化自定義 HTTP 處理程序工廠之前進(jìn)行初始化，因此，在將 URL 重寫放在事件的后半段時，使用 HTTP 處理程序工廠就會帶來相同的風(fēng)險，即文件授權(quán)無法工作。因此，如果您依賴于 Windows 身份驗(yàn)證和文件授權(quán)，您可能希望為 URL 重寫使用 HTTP 模塊方法。

在下一部分中，我們將對構(gòu)建可重用的 URL 重寫引擎進(jìn)行討論。在介紹了 URL 重寫引擎（可通過下載本文的代碼獲得）之后，我們將在剩下的兩個部分中對 URL 重寫的實(shí)際使用情況進(jìn)行介紹。首先，我們將討論如何使用 URL 重寫引擎，并介紹一個簡單的 URL 重寫示例。接下來，我們將利用重寫引擎的正則表達(dá)式功能來提供真正“可刪節(jié)”的 URL。

返回頁首

構(gòu)建 URL 重寫引擎

為了有助于描述如何在 ASP.NET Web 應(yīng)用程序中實(shí)現(xiàn) URL 重寫，我創(chuàng)建了 URL 重寫引擎。此重寫引擎將提供以下功能：

在本文中，我們將介紹僅使用 HTTP 模塊的 URL 重寫。要查看如何使用 HTTP 處理程序來執(zhí)行 URL 重寫，請參考可隨本文下載的代碼。

為 URL 重寫引擎指定配置信息

讓我們先介紹一下 Web.config 文件中重寫規(guī)則的結(jié)構(gòu)。首先，您需要在 Web.config 文件中指明要使用 HTTP 模塊還是 HTTP 處理程序來執(zhí)行 URL 重寫。在下載代碼中，Web.config 文件包含兩個已注釋掉的條目：

<!--
<httpModules>
<add type="URLRewriter.ModuleRewriter, URLRewriter"
name="ModuleRewriter" />
</httpModules>
-->
<!--
<httpHandlers>
<add verb="*" path="*.aspx"
type="URLRewriter.RewriterFactoryHandler, URLRewriter" />
</httpHandlers>
-->

注釋掉 <httpModules> 條目，以使用 HTTP 模塊執(zhí)行重寫；注釋掉 <httpHandlers> 條目，以使用 HTTP 處理程序執(zhí)行重寫。

除了指定使用 HTTP 模塊還是 HTTP 處理程序執(zhí)行重寫外，Web.config 文件還包含重寫規(guī)則：重寫規(guī)則由兩個字符串組成：要在被請求的 URL 中查找的模式；要替換此模式的字符串（如果找到）。在 Web.config 文件中，此信息是使用以下語法表達(dá)的：

<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>要查找的模式</LookFor>
<SendTo>要用來替換模式的字符串</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>要查找的模式</LookFor>
<SendTo>要用來替換模式的字符串</SendTo>
</RewriterRule>
...
</Rules>
</RewriterConfig>

每個重寫規(guī)則均由 <RewriterRule> 元素表達(dá)。要搜索的模式由 <LookFor> 元素指定，而要替換所找到的模式的字符串將在 <SentTo> 元素中輸入。這些重寫規(guī)則將從頭到尾進(jìn)行計(jì)算。如果發(fā)現(xiàn)與某個規(guī)則匹配，URL 將被重寫，并且對重寫規(guī)則的搜索將會終止。

在 <LookFor> 元素中指定模式時，請注意，要使用正則表達(dá)式來執(zhí)行匹配和字符串替換。（稍后，我們將介紹一個真實(shí)的示例，說明如何使用正則表達(dá)式來搜索模式。）由于模式是正則表達(dá)式，應(yīng)確保轉(zhuǎn)義正則表達(dá)式中的任何保留字符。（一些正則表達(dá)式保留字符包括：.、?、^、$ 及其他。可以通過在前面加反斜杠（如 \.）對這些字符進(jìn)行轉(zhuǎn)義，以匹配文字句點(diǎn)。）

使用 HTTP 模塊執(zhí)行 URL 重寫

創(chuàng)建 HTTP 模塊與創(chuàng)建可以實(shí)現(xiàn) IHttpModule 接口的類一樣簡單。IHttpModule 接口定義了兩種方法：

為了便于為 URL 重寫創(chuàng)建 HTTP 模塊，我將從創(chuàng)建抽象基類 BaseModuleRewriter 開始介紹。此類將實(shí)現(xiàn) IHttpModule。在 Init() 事件中，它將 HttpApplication 的 AuthorizeRequest 事件綁定到 BaseModuleRewriter_AuthorizeRequest 方法。BaseModuleRewriter_AuthorizeRequest 方法將調(diào)用該類傳入被請求的 Path 的 Rewrite() 方法，以及傳入 Init() 方法的 HttpApplication 對象。Rewrite() 方法是抽象的，也就是說，在 BaseModuleRewriter 類中，Rewrite() 方法沒有方法主體；從 BaseModuleRewriter 派生而來的類必須覆蓋此方法并提供方法主體。

具有此基類后，只需創(chuàng)建由 BaseModuleRewriter 派生的類即可，該類可以覆蓋 Rewrite() 并在那里執(zhí)行 URL 重寫邏輯。下面顯示了 BaseModuleRewriter 的代碼。

public abstract class BaseModuleRewriter : IHttpModule
{
public virtual void Init(HttpApplication app)
{
// 警告！此代碼不適用于 Windows 身份驗(yàn)證！
// 如果使用 Windows 身份驗(yàn)證，
// 請改為 app.BeginRequest
app.AuthorizeRequest += new
EventHandler(this.BaseModuleRewriter_AuthorizeRequest);
}
public virtual void Dispose() {}
protected virtual void BaseModuleRewriter_AuthorizeRequest(
object sender, EventArgs e)
{
HttpApplication app = (HttpApplication) sender;
Rewrite(app.Request.Path, app);
}
protected abstract void Rewrite(string requestedPath,
HttpApplication app);
}

請注意，BaseModuleRewriter 類將在 AuthorizeRequest 事件中執(zhí)行 URL 重寫。如上所述，如果將 Windows 身份驗(yàn)證與文件授權(quán)結(jié)合使用，您需要對此做出更改，以便可以在 BeginRequest 或 AuthenticateRequest 事件中執(zhí)行 URL 重寫。

ModuleRewriter 類擴(kuò)展了 BaseModuleRewriter 類，并負(fù)責(zé)執(zhí)行實(shí)際的 URL 重寫。ModuleRewriter 包含單一覆蓋方法（Rewrite()），如下所示：

protected override void Rewrite(string requestedPath,
System.Web.HttpApplication app)
{
// 獲得配置規(guī)則
RewriterRuleCollection rules =
RewriterConfiguration.GetConfig().Rules;
// 遍歷每個規(guī)則...
for(int i = 0; i < rules.Count; i++)
{
// 獲得要查找的模式，并且
// 解析 Url（轉(zhuǎn)換為相應(yīng)的目錄）
string lookFor = "^" +
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,
rules[i].LookFor) + "$";
// 創(chuàng)建 regex（請注意，已設(shè)置 IgnoreCase...）
Regex re = new Regex(lookFor, RegexOptions.IgnoreCase);
// 查看是否找到了匹配的規(guī)則
if (re.IsMatch(requestedPath))
{
// 找到了匹配的規(guī)則 -- 進(jìn)行必要的替換
string sendToUrl =
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,
re.Replace(requestedPath, rules[i].SendTo));
// 重寫 URL
RewriterUtils.RewriteUrl(app.Context, sendToUrl);
break;      // 退出 For 循環(huán)
}
}
}

Rewrite() 方法從獲取 Web.config 文件中的一組重寫規(guī)則開始。然后，它將遍歷重寫規(guī)則，每次遍歷一個，對于每個規(guī)則，它將獲取規(guī)則的 LookFor 屬性，并使用正則表達(dá)式來確定是否在被請求的 URL 中找到了匹配的規(guī)則。

如果找到了匹配的規(guī)則，將在具有 SendTo 屬性值的被請求路徑上執(zhí)行正則表達(dá)式替換。然后，替換后的 URL 將被傳遞到 RewriterUtils.RewriteUrl() 方法中。RewriterUtils 是一個 helper 類，此類將提供一對由 URL 重寫 HTTP 模塊和 HTTP 處理程序使用的靜態(tài)方法。RewriterUrl() 方法僅調(diào)用 HttpContext 對象的 RewriteUrl() 方法。

注意：您可能已注意到，執(zhí)行正則表達(dá)式匹配和替換時，將調(diào)用 RewriterUtils.ResolveUrl()。此 helper 方法只替換具有應(yīng)用程序路徑值的字符串中的所有 ~ 實(shí)例。

URL 重寫引擎的整個代碼可隨本文下載。我們已經(jīng)介紹了大部分密切相關(guān)的組件，但還有一些其他組件（例如，對 Web.config 文件中 XML 格式的重寫規(guī)則進(jìn)行反序列化以使其成為對象的類），以及用于 URL 重寫的 HTTP 處理程序工廠。本文剩余的三個部分將對 URL 重寫的實(shí)際使用情況進(jìn)行介紹。

返回頁首

使用 URL 重寫引擎執(zhí)行簡單的 URL 重寫

為了實(shí)際演示 URL 重寫引擎，我們來構(gòu)建一個使用簡單 URL 重寫的 ASP.NET Web 應(yīng)用程序。假設(shè)我們所工作的公司通過網(wǎng)絡(luò)銷售分類產(chǎn)品。這些產(chǎn)品分為以下幾個類別：

假設(shè)我們已創(chuàng)建了名為 ListProductsByCategory.aspx 的 ASP.NET 網(wǎng)頁，該網(wǎng)頁在查詢字符串中接受類別 ID 值，并顯示屬于該類的所有產(chǎn)品。因此，要查看我們銷售的飲料的用戶可以訪問 ListProductsByCategory.aspx?CategoryID=1，而那些要查看奶制品的用戶可以訪問 ListProductsByCategory.aspx?CategoryID=4。此外，還假設(shè)我們有一個名為 ListCategories.aspx 的頁面，該頁面列出了待售的所有產(chǎn)品類別。

很顯然，這是一個 URL 重寫事例，因?yàn)樘峁┙o用戶的 URL 沒有為用戶帶來任何意義，也沒有為他們提供任何“可刪節(jié)性”。因此，讓我們使用 URL 重寫，以便在用戶訪問 /Products/Beverages.aspx 時，他們的 URL 將被重寫為 ListProductsByCategory.aspx?CategoryID=1。我們可以在 Web.config 文件中使用以下 URL 重寫規(guī)則來實(shí)現(xiàn)此功能。

<RewriterConfig>
<Rules>
<!-- 產(chǎn)品制表者規(guī)則 -->
<RewriterRule>
<LookFor>~/Products/Beverages\.aspx</LookFor>
<SendTo>~/ListProductsByCategory.aspx?CategoryID=1</SendTo>
</RewriterRule>
<RewriterRule>
</Rules>
</RewriterConfig>

正如您可以看到的，此規(guī)則將進(jìn)行搜索，以查看用戶請求的路徑是否為 /Products/Beverages.aspx。如果是，它便將 URL 重寫為 /ListProductsByCategory.aspx?CategoryID=1。

注意：請注意，<LookFor> 元素對 Beverages.aspx 中的句點(diǎn)進(jìn)行了轉(zhuǎn)義。這是因?yàn)樵谡齽t表達(dá)式模式中使用了 <LookFor> 值，并且句點(diǎn)是正則表達(dá)式中的特殊字符，該字符表示“匹配任意字符”，例如，與 URL /Products/BeveragesQaspx 匹配。通過轉(zhuǎn)義句點(diǎn)（使用 \.），可以表明我們要匹配的是文字句點(diǎn)，而不是任何舊的字符。

有了此規(guī)則之后，當(dāng)用戶訪問 /Products/Beverages.aspx 時，頁面上將顯示待售的飲料。圖 3 顯示了訪問 /Products/Beverages.aspx 的瀏覽器的快照。請注意，在瀏覽器的地址欄中，URL 將讀取 /Products/Beverages.aspx，但用戶實(shí)際看到的是 ListProductsByCategory.aspx?CategoryID=1 的內(nèi)容。（實(shí)際上，Web 服務(wù)器上根本不存在 /Products/Beverages.aspx 文件！）

圖 3. 重寫 URL 之后請求類別

與 /Products/Beverages.aspx 相似，下面我們要為其他產(chǎn)品類別添加重寫規(guī)則。此操作僅包括在 Web.config 文件的 <Rules> 元素內(nèi)添加附加的 <RewriterRule> 元素。請參閱下載內(nèi)容中的 Web.config 文件，以獲取用于此演示的一組完整的重寫規(guī)則。

為了使 URL 更具可刪節(jié)性，最好使用戶只需從 /Products/Beverages.aspx 中刪除 Beverages.aspx 即可看到產(chǎn)品類別的列表。乍一看，這可能是一項(xiàng)很普通的任務(wù)（只需添加一個將 /Products/ 映射到 /ListCategories.aspx 的重寫規(guī)則即可）。但此操作存在一個微妙之處，即您必須首先創(chuàng)建一個 /Products/ 目錄，并在 /Products/ 目錄中添加一個空的 Default.aspx 文件。

要理解需要執(zhí)行這些額外步驟的原因，可以參考前面的內(nèi)容，即 URL 重寫引擎位于 ASP.NET 級別上。也就是說，如果 ASP.NET 引擎永遠(yuǎn)沒有機(jī)會處理請求，URL 重寫引擎就沒有辦法檢測傳入的 URL。而且，請記住，僅當(dāng)被請求的文件具有相應(yīng)的擴(kuò)展名時，IIS 才會將傳入請求傳遞給 ASP.NET 引擎。因此，如果用戶訪問 /Products/，而 IIS 沒有看到任何文件擴(kuò)展名，那么它將檢查目錄，以查看是否存在這樣一個文件，即該文件名為默認(rèn)文件名中的一個。（Default.aspx、Default.htm、Default.asp 等等?！癐IS 管理”對話框中“Web 服務(wù)器屬性”對話框的“文檔”選項(xiàng)卡對這些默認(rèn)文件名進(jìn)行了定義。）當(dāng)然，如果 /Products/ 目錄不存在，IIS 將返回 HTTP 404 錯誤。

因此，我們需要創(chuàng)建 /Products/ 目錄。另外，我們還需要在此目錄中創(chuàng)建一個文件 Default.aspx。這樣，當(dāng)用戶訪問 /Products/ 時，IIS 將檢測目錄，查看是否存在一個名為 Default.aspx 的文件，然后將處理過程傳遞給 ASP.NET 引擎。然后，URL 重寫器將在重寫 URL 時分解。

創(chuàng)建目錄和 Default.aspx 文件后，請繼續(xù)操作，并向 <Rules> 元素中添加以下重寫規(guī)則：

<RewriterRule>
<LookFor>~/Products/Default\.aspx</LookFor>
<SendTo>~/ListCategories.aspx</SendTo>
</RewriterRule>

有了此規(guī)則之后，當(dāng)用戶訪問 /Products/ 或 /Products/Default.aspx 時，他們將看到產(chǎn)品類別列表，如圖 4 所示。

圖 4. 向 URL 添加“可刪節(jié)性”

處理回發(fā)

如果要重寫的 URL 中包含一個服務(wù)器端的 Web 窗體并執(zhí)行回發(fā)，則窗體回發(fā)后，將使用帶下劃線的 URL。也就是說，如果用戶在瀏覽器中輸入 /Products/Beverages.aspx，他們在瀏覽器地址欄中看到的將是 /Products/Beverages.aspx，但是他們看到的內(nèi)容將是 ListProductsByCategory.aspx?CategoryID=1 的內(nèi)容。如果 ListProductsByCategory.aspx 執(zhí)行了回發(fā)，用戶將被回發(fā)到 ListProductsByCategory.aspx?CategoryID=1，而不是 /Products/Beverages.aspx。這樣不會中斷任何內(nèi)容，但從用戶的角度考慮，如果單擊按鈕時突然看到 URL 更改會使他們感到不安。

出現(xiàn)這種情況的原因是：在呈現(xiàn) Web 窗體時，它會將其操作屬性直接設(shè)置為 Request 對象中文件路徑的值。當(dāng)然，在呈現(xiàn) Web 窗體時，URL 已從 /Products/Beverages.aspx 重寫為 ListProductsByCategory.aspx?CategoryID=1，這表明 Request 對象報告用戶要訪問 ListProductsByCategory.aspx?CategoryID=1。只需使服務(wù)器端窗體不呈現(xiàn)操作屬性即可解決此問題。（默認(rèn)情況下，如果窗體不包含操作屬性，瀏覽器將會回發(fā)。）

不幸的是，Web 窗體不允許您明確指定操作屬性，也不允許您設(shè)置某些屬性以禁用操作屬性的呈現(xiàn)。因此，我們必須自己來擴(kuò)展 System.Web.HtmlControls.HtmlForm 類，覆蓋 RenderAttribute() 方法并明確指出它不會呈現(xiàn)操作屬性。

由于繼承功能，我們可以獲得 HtmlForm 類的所有功能，并且只需添加幾行代碼即可獲得所需的行為。以下顯示了自定義類的完整代碼：

namespace ActionlessForm {
public class Form : System.Web.UI.HtmlControls.HtmlForm
{
protected override void RenderAttributes(HtmlTextWriter writer)
{
writer.WriteAttribute("name", this.Name);
base.Attributes.Remove("name");
writer.WriteAttribute("method", this.Method);
base.Attributes.Remove("method");
this.Attributes.Render(writer);
base.Attributes.Remove("action");
if (base.ID != null)
writer.WriteAttribute("id", base.ClientID);
}
}
}

已被覆蓋的 RenderAttributes() 方法的代碼僅包含 HtmlForm 類的 RenderAttributes() 方法的準(zhǔn)確代碼，而不設(shè)置操作屬性。（我使用 Lutz Roeder 的 Reflector 來查看 HtmlForm 類的源代碼。）

創(chuàng)建此類并對其進(jìn)行編譯之后，要在 ASP.NET Web 應(yīng)用程序中使用它，應(yīng)首先將其添加到 Web 應(yīng)用程序的 References 文件夾中。然后，要使用它來代替 HtmlForm 類，只需在 ASP.NET 網(wǎng)頁的頂部添加以下內(nèi)容即可：

<%@ Register TagPrefix="skm" Namespace="ActionlessForm"
Assembly="ActionlessForm" %>

然后，將 <form runat="server">（如果有）替換為：

<skm:Form id="Form1" method="post" runat="server">

并將右邊的 </form> 標(biāo)記替換為：

</skm:Form>

您可以在 ListProductsByCategory.aspx（包含在本文的下載代碼中）中發(fā)現(xiàn)操作中的此自定義 Web Form 類。下載內(nèi)容中還包含了用于無操作 Web Form 的 Visual Studio .NET 項(xiàng)目。

注意：如果要重寫的目標(biāo) URL 沒有執(zhí)行回發(fā)，則無需使用此自定義 Web Form 類。

返回頁首

創(chuàng)建真正“可刪節(jié)”的 URL

前一部分中介紹的簡單 URL 重寫顯示了如何輕松地為 URL 重寫引擎配置新的重寫規(guī)則。但在使用正則表達(dá)式時，重寫規(guī)則的真正功能才會發(fā)揮更大作用，本部分將對此進(jìn)行探討。

Blog 在當(dāng)今正變得越來越流行，似乎每個人都擁有自己的 blog。如果您不熟悉 blog：blog 是經(jīng)常更新的個人頁面，通常作為聯(lián)機(jī)期刊。大多數(shù) blog 只記錄每天發(fā)生的事情，還有一些 blog 可能關(guān)注于特定的主題（例如，電影回顧、體育團(tuán)隊(duì)或計(jì)算機(jī)技術(shù)）。

可以在任何地點(diǎn)對 blog 進(jìn)行更新，更新頻率為從每天幾次到每周一次或兩次，具體情況取決于作者。通常，blog 主頁將顯示最近的 10 個條目，但實(shí)際上，所有 blog 軟件均提供存檔，訪問者可以通過存檔讀取較早的帖子。Blog 是用于“可刪節(jié)”URL 的一個功能強(qiáng)大的應(yīng)用程序。假設(shè)在搜索 blog 的存檔時，您在 URL /2004/02/14.aspx 上發(fā)現(xiàn)了您自己。如果您發(fā)現(xiàn)自己在閱讀 2004 年 2 月 14 日的帖子，您是否覺得很驚訝？而且，您可能希望查看 2004 年 2 月的所有帖子，在這種情況下，您可以嘗試將 URL 刪節(jié)為 /2004/02/。要查看 2004 年的所有帖子，您可以嘗試訪問 /2004/。

維護(hù) blog 時，最好為訪問者提供此級別的 URL“可刪節(jié)性”。許多 blog 引擎都提供此功能，但我們將討論如何使用 URL 重寫來實(shí)現(xiàn)此功能。

首先，我們需要一個 ASP.NET 網(wǎng)頁，此頁面將按照日、月或年來顯示 blog 條目。假設(shè)我們有一個 ShowBlogContent.aspx 頁面，該頁面的查詢字符串參數(shù)為年、月和日。要查看 2004 年 2 月 14 日的帖子，我們可以訪問 ShowBlogContent.aspx?year=2004&month=2&day=14。要查看 2004 年 2 月的所有帖子，我們可以訪問 ShowBlogContent.aspx?year=2004&month=2。最后，要查看 2004 年的所有帖子，我們可以瀏覽到 ShowBlogContent.aspx?year=2004。（可以在本文的下載內(nèi)容中找到 ShowBlogContent.aspx 的代碼。）

在這種情況下，如果用戶訪問 /2004/02/14.aspx，我們需要將 URL 重寫為 ShowBlogContent.aspx?year=2004&month=2&day=14。所有三種情況（URL 指定了年、月和日時；URL 僅指定了年和月時；URL 僅指定了年時）均可使用重寫規(guī)則進(jìn)行處理：

<RewriterConfig>
<Rules>
<!-- Blog 內(nèi)容顯示程序規(guī)則 -->
<RewriterRule>
<LookFor>~/(\d{4})/(\d{2})/(\d{2})\.aspx</LookFor>
<SendTo>~/ShowBlogContent.aspx?year=$1&month=$2&day=$3</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/(\d{4})/(\d{2})/Default\.aspx</LookFor>
<SendTo><![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]></SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/(\d{4})/Default\.aspx</LookFor>
<SendTo>~/ShowBlogContent.aspx?year=$1</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>

這些重寫規(guī)則表明了正則表達(dá)式的功能。在第一個規(guī)則中，我們使用模式 (\d{4})/(\d{2})/(\d{2})\.aspx 查找 URL。在簡明英語中，它對應(yīng)了這樣一個字符串：首先是四個數(shù)字，后跟一個斜杠，然后是兩個數(shù)字，后跟一個斜杠，然后再跟兩個數(shù)字，最后是一個 .aspx。每個數(shù)字組周圍的括號非常重要，通過它可以在相應(yīng)的 <SendTo> 屬性中引用這些括號內(nèi)的匹配字符。 特別是，我們可以針對第一、第二和第三個括號組分別使用 $1、$2 和 $3 引用回括號內(nèi)的匹配組。

注意：由于 Web.config 文件采用 XML 格式，但是必須對元素文字部分中的字符（如 &、< 和 >）進(jìn)行轉(zhuǎn)義。在第一個規(guī)則的 <SendTo> 元素中，& 被轉(zhuǎn)義為 &。在第二個規(guī)則的 <SendTo> 中使用了另外一種技術(shù)（使用 <![CDATA[...]]> 元素），無需對內(nèi)部的內(nèi)容進(jìn)行轉(zhuǎn)義?？梢允褂脙煞N方法中的任何一種，并且都會得到相同的結(jié)果。

圖 5、6 和 7 顯示了操作中的 URL 重寫。數(shù)據(jù)實(shí)際上是從我的 blog http:/// 中拖過來的。圖 5 中顯示了 2003 年 11 月 7 日的帖子；圖 6 中顯示了 2003 年 11 月的所有帖子；圖 7 顯示了 2003 年的所有帖子。

圖 5. 2003 年 11 月 7 日的帖子

圖 6. 2003 年 11 月的所有帖子

圖 7. 2003 年的所有帖子

注意：URL 重寫引擎在 <LookFor> 元素中需要使用正則表達(dá)式模式。如果您對正則表達(dá)式不熟悉，可以閱讀我在早些時候編寫的一篇文章 An Introduction to Regular Expressions。另外，還有一個很好的網(wǎng)站：RegExLib.com，在那里您可以獲取有關(guān)常用正則表達(dá)式的幫助信息，還可以共享您自己的自定義正則表達(dá)式。

構(gòu)建必備的目錄結(jié)構(gòu)

當(dāng)請求 /2004/03/19.aspx 時，IIS 將通知 .aspx 擴(kuò)展，并將請求路由到 ASP.NET 引擎。請求在 ASP.NET 引擎的管道中移動時，URL 將被重寫為 ShowBlogContent.aspx?year=2004&month=03&day=19，并且訪問者會看到 2004 年 3 月 19 日的 blog 條目。但是當(dāng)用戶瀏覽到 /2004/03/ 時將會發(fā)生什么情況呢？除非有一個 /2004/03/ 目錄，否則 IIS 將返回一個 404 錯誤。此外，此目錄中還需要具有 Default.aspx 頁面，以便可以將請求傳遞給 ASP.NET 引擎。

因此，要使用這種方法，必須手動創(chuàng)建一個用于每年的目錄（其中包含 blog 條目），并且目錄中具有一個 Default.aspx 頁面。另外，在每年目錄中，您需要再手動創(chuàng)建十二個目錄（01、02、?、?...、12），并且每個目錄中均有一個 Default.aspx 文件。（如上所述，我們還必須執(zhí)行前面演示中的操作，即在 /Products/ 目錄中添加一個 Default.aspx 文件，以便訪問 /Products/ 時可以正確顯示 ListCategories.aspx。）

很顯然，添加這樣一個目錄結(jié)構(gòu)可能是一件很痛苦的事情。解決此問題的方法是使所有傳入的 IIS 請求都映射到 ASP.NET 引擎。通過這種方法，即使訪問 URL /2004/03/，IIS 也會如實(shí)地將請求傳遞給 ASP.NET 引擎（即使并不存在 /2004/03/ 目錄）。但是，使用這種方法將使 ASP.NET 引擎負(fù)責(zé)處理到達(dá) Web 服務(wù)器的所有類型的傳入請求，包括圖像、CSS 文件、外部 JavaScript 文件、Macromedia Flash 文件，等等。

對處理所有文件類型的全面討論遠(yuǎn)遠(yuǎn)超出了本文的范圍。有關(guān)使用此技術(shù)的 ASP.NET Web 應(yīng)用程序的示例，請參閱 .Text，一個開放源 blog 引擎。.Text 可以配置為將所有請求均映射到 ASP.NET 引擎。它可以使用自定義 HTTP 處理程序來處理生成所有文件類型的問題，自定義 HTTP 處理程序了解如何生成典型的靜態(tài)文件類型（圖像、CSS 文件，等等）。

返回頁首

結(jié)論

在本文中，我們討論了如何在 ASP.NET 級別通過 HttpContext 類的 RewriteUrl() 方法來執(zhí)行 URL 重寫。正如我們所看到的，RewriteUrl() 更新了特定的 HttpContext‘s Request 屬性，從而更新了被請求的文件和路徑。最終結(jié)果是，從用戶角度來看，他們要訪問某個特定的 URL，但從 Web 服務(wù)器端來看，被請求的卻是另一個 URL。

可以在 HTTP 模塊或 HTTP 處理程序中重寫 URL。在本文中，我們介紹了如何使用 HTTP 模塊執(zhí)行重寫，并討論了在管道中的不同階段執(zhí)行重寫的結(jié)果。

當(dāng)然，如果執(zhí)行 ASP.NET 級別的重寫，則僅當(dāng)已成功地將請求從 IIS 傳遞給 ASP.NET 引擎后才會發(fā)生 URL 重寫。實(shí)際上，只有用戶請求帶 .aspx 擴(kuò)展名的頁面時才會出現(xiàn)這種情況。但是，如果您要使用戶可以進(jìn)入實(shí)際并不存在的 URL，但又希望重寫到現(xiàn)有的 ASP.NET 頁面，則必須創(chuàng)建虛擬目錄和 Default.aspx 頁面，或者對 IIS 進(jìn)行配置，以使所有傳入請求一律被路由到 ASP.NET 引擎。