浅析ASP.NET MVC中关于URL Rewrite的完成-编程开发-知优网

我们这里将介绍在ASP.NET MVC中使用IIS级别的URL Rewrite，希望本文能对大家有所帮助。

本文将为咱们叙述如安在ASP.NET MVC中运用IIS等级的URL Rewrite，这种办法尽管用的不是很广泛，但也有其效果，51CTO修正向您引荐《ASP.NET MVC结构视频教程》。

大约一年半前，我在博客上写过一系列关于URL Rewrite的文章（2、3、4），把ASP.NET渠道上进行URL Rewrit的办法和各自地特色进行了较为详细的描绘。应该来说，现已讲的十分详细，能够应对90%的状况。其实IIS 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 
QueryString：keywords=helloworld

后来SEO鼓起之后，有人说这样的“动态地址”不利于搜索引擎中的权重优化，因而主张把关键字作为Path的一部分。所以就呈现了这样的URL：

http://51programming.com/products/helloworld这么看来问题并不大，可是您要知道，关键字往往是由用户输入的，可能会输入特别字符。例如，假如用户输入了“200%”作为关键字，则两种办法下的URL就分别是：

http://51programming.com/products?keywords=200%25
http://51programming.com/products/200%25假如您测验一下便能够知道，***个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来指定这个参数的获取方位：

publicclassFromQueryBinder:IModelBinder 
{ 
publicobjectBindModel(ControllerContextcontrollerContext,ModelBindingContextbindingContext) 
{ 
returncontrollerContext.HttpContext.Request.QueryString[bindingContext.ModelName]; 
} 
}

再将其运用到List的keywords参数上去：

publicActionResultList( 
[ModelBinder(typeof(FromQueryBinder))]stringkeywords)

因为参数名是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中运用IIS等级的URL Rewrite》

【修正引荐】