和淺析ASP.NET MVC中關于URL Rewrite的實現

這期內容當中小編將會給大家帶來有關和淺析ASP.NET MVC中關于URL Rewrite的實現，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

現在我們就來看一個真實案例：在ASP.NET MVC中使用IIS級別的URL Rewrite。

在當時的文章中我談到，URL Rewrite分有IIS級別和ASP.NET兩種級別，并且各有各的特點和限制。在ASP.NET MVC中我們常用的方式是ASP.NET級別的URL Routing，它的作用是從URL中捕獲數據并交給程序使用（當然還有“構造”的功能，稍候再談）。因此，在ASP.NET MVC中我們往往不需要使用ASP.NET級別的URL Rewrite。而如今使用IIS級別的URL Rewrite，也正是因為有某些特殊問題無法回避才“不得已而為之”的。

以下涉及到的URL都以http://51programming.com為例，這個域名已經被我泛解析為127.0.0.1，如果您需要的話可以用它來做實驗。

在許多年前，一個URL的Path就是普通的路徑，而動態的參數，如查詢路徑，是通過Query String提供的，例如：

http://51programming.com/products?keywords=helloworld為了避免混淆，在這里我們先來澄清一些概念。什么是URL，什么是Path，而什么是QueryString。例如在上面的地址，這三者分別是：

URL：http://51programming.com/products?keywords=helloworld   Path：http://51programming.com/products   Query String：keywords=helloworld

后來SEO興起之后，有人說這樣的“動態地址”不利于搜索引擎中的權重優化，因此建議把關鍵字作為Path的一部分。于是就出現了這樣的URL：

http://51programming.com/products/helloworld這么看來問題并不大，但是您要知道，關鍵字往往是由用戶輸入的，可能會輸入特殊字符。例如，如果用戶輸入了“200%”作為關鍵字，則兩種形式下的URL就分別是：

如果您嘗試一下便可以知道，第一個URL可以正常訪問，而第二個URL便會引發Bad Request異常：

這是因為URL的Path部分出現了特殊字符，而這種字符只能出現在Query String中。

看到這個畫面，您還意識到了什么信息？在定位問題的原因，以及設法解決問題的時候，首先要明確的是到底是哪里出現了問題。例如看到這個畫面，您應該清楚地意識到一點：這是ASP.NET拋出的異常，換句話說，IIS并沒有把它當作是非法的URL，它還是老老實實地將URL交給ASP.NET ISAPI處理。因此，我們便可以動用IIS級別的URL Rewrite，在進入ASP.NET執行引擎之前，就把URL替換成可接受的形式：

RewriteRule  ^/products/([^\?]*)\?(.+)    /products?$2&keywords=$1     [I,L,U]

RewriteRule  ^/products/([^\?]*)          /products?keywords=$1     [I,L,U]***行應對的是帶有Query String的情況，而第二行則是沒有Query String的情況。這里用到的組件是IIRF（Ionic's Isapi Rewrite Filter），這是一款開源產品，一年半前的文章里我推薦的也是這個，現在它已經有了升級。它的功能便是在進入ASP.NET ISAPI之前，就將URL重寫為其他形式：

原本在第3步會出現的Bad Request，由于已經在第2步被URL Rewrite成合法的形式。因此剩余的處理也就沒有任何問題了。

這些內容在一年半前的文章內已經提過，不過現在既然有了ASP.NET MVC，則事情又變得更為復雜。因為ASP.NET Routing除了“匹配”URL的功能之外，還擔負著“組裝”URL的職責。因此，讓ASP.NET Routing能夠識別出Rewrite后的URL不難，但是如何同時讓它又可以“組裝”出Rewrite前的URL，這就需要一些小技巧了。例如以下的Route配置只能識別出URL輸入（/products?keywords=xxx）但不能組裝出我們需要的URL（/products/xxx）：

routes.MapRoute(      "Product.List",      "products",      new { controller = "Product", action = "List" });

因此，我們必須這么做：

routes.MapRoute(      "Product.List",      "products/{*keywords}",      new { controller = "Product", action = "List", keywords = "" });

請注意我們讓keywords匹配Path后端全部內容，而由于我們又提供了keywords的默認值，因此即使是“/products”這樣的Path輸入，也能正確匹配到這條Route規則——只不過此時的Route Value中的keywords字段已經不是用戶輸入的內容了（因為用戶輸入的/products/xxx，已經被重寫為/products?keywords=xxx）。換句話說，如果有如下的Action，那么它的keywords參數則永遠是空字符串：

public ActionResult List(string keywords) { ... }幸好，ASP.NET MVC中存在Model Binder機制，我們可以編寫一個Model Binder來指定這個參數的獲取位置：

public class FromQueryBinder : IModelBinder  {      public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)      {          return controllerContext.HttpContext.Request.QueryString[bindingContext.ModelName];      }  }

再將其運用到List的keywords參數上去：

public ActionResult List(      [ModelBinder(typeof(FromQueryBinder))]string keywords)

由于參數名是keywords，因此bindingContext.ModelName也是keywords，于是從Query String中便可以取到我們需要的內容了。至于在進行URL生成的時候，我們還是可以之間一樣添加一個keywords字段到Route Value中去，于是在我們先前配置的Route規則中便會組裝成合適的Path了（即/products/xxx）。

在這個例子中，我們讓keywords匹配Path后端全部內容，但是如果是Path中間某一段需要有特殊字符怎么辦呢？其實也一樣，只是在進行URL Rewrite的時候，需要在最終重寫的時候填寫一個“假”的值就可以了，如這樣的Route規則：

routes.MapRoute(      "Product.List",      "products/{keywords}/page",      new { controller = "Product", action = "List" });

而IIS級別的URL Rewrite重寫的規則就可以是：

RewriteRule  ^/products/([^/]*)/(.*)     /products/useless-segement/$2?keywords=$1     [I,L,U]這樣，如果用戶輸入/products/xxx/2就會被重寫成/products/useless-token/2?keywords=xxx——事實上，在***個示例中我們也可以這么做，只是我“不習慣”增加一個偽造的值而已。

以上解決方案可以在IIS 6與IIS 7的Classic Mode中正常使用，只可惜在IIS 7的Intergrated Mode中，可能是由于ASP.NET接管了IIS的部分邏輯，因此會很早拋出“IIS級別”，而不是“ASP.NET級別”的Bad Request異常。如果您遇到了這種方式，就必須通過以下三個步驟來擺脫這個麻煩的問題了：

設置AllowRestrictedChars：KB820129（讓IIS 7接受特殊字符）

設置VerificationCompatibility：KB826437中除了“安裝.NET 1.1 SP1”以外的步驟（讓ASP.NET接受特殊字符）

將ASP.NET頁面的ValidateRequest設為False

其實您只要經過了這三步修改，對于目前這個案例，即使不用IIS級別的URL Rewrite應該也沒有問題了。

上述就是小編為大家分享的和淺析ASP.NET MVC中關于URL Rewrite的實現了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。