NET网页编程之浅析ASP.NET MVC中关于URL Rewrite的完成

我也不知道，我原来理解的，NET就是C++编程，只是与JAVA相对，呵呵。以为.ET就是高级C++编程。本文将为人人报告怎样在ASP.NETMVC中利用IIS级其余URLRewrite，这类办法固然用的不是很普遍，但也有其感化。
约莫一年半前，我在博客上写过一系列关于URLRewrite的文章（2、3、4），把ASP.NET平台长进行URLRewrit的体例和各自地特性举行了较为具体的形貌。应当来讲，已讲的十分详细，能够应对90%的情形。实在IISRewrite的道理十分简单了解，举行一些复杂的变更和揣度以后，即可以得出一些成绩的缘故原由息争决计划。如今我们就来看一个实在案例：在ASP.NETMVC中利用IIS级其余URLRewrite。
在事先的文章中我谈到，URLRewrite分有IIS级别和ASP.NET两种级别，而且各有各的特性和限定。在ASP.NETMVC中我们经常使用的体例是ASP.NET级其余URLRouting，它的感化是从URL中捕捉数据并交给程序利用（固然另有“机关”的功效，稍候再谈）。因而，在ASP.NETMVC中我们常常不必要利用ASP.NET级其余URLRewrite。而现在利用IIS级其余URLRewrite，也恰是由于有某些特别成绩没法躲避才“不得已而为之”的。
以下触及到的URL都以http://51programming.com为例，这个域名已被我泛剖析为127.0.0.1，假如您必要的话能够用它来做实行。
在很多年前，一个URL的Path就是一般的路径，而静态的参数，如查询路径，是经由过程QueryString供应的，比方：
http://www.lmwlove.com/ac/ID226?keywords=helloworld为了不搅浑，在这里我们先来廓清一些观点。甚么是URL，甚么是Path，而甚么是QueryString。比方在下面的地点，这三者分离是：
URL：http://www.lmwlove.com/ac/ID226?keywords=helloworld
Path：http://www.lmwlove.com/ac/ID226
QueryString：keywords=helloworld
厥后SEO衰亡以后，有人说如许的“静态地点”倒霉于搜刮引擎中的权重优化，因而倡议把关头字作为Path的一部分。因而就呈现了如许的URL：
http://www.lmwlove.com/ac/ID226这么看来成绩其实不年夜，可是您要晓得，关头字常常是由用户输出的，大概会输出特别字符。比方，假如用户输出了“200%”作为关头字，则两种情势下的URL就分离是：
http://www.lmwlove.com/ac/ID226?keywords=200%25
http://www.lmwlove.com/ac/ID226/200%25假如您实验一下即可以晓得，第一个URL能够一般会见，而第二个URL便会激发BadRequest非常：

登录/注册后可看大图

这是由于URL的Path部分呈现了特别字符，而这类字符只能呈现在QueryString中。
看到这个画面，您还意想到了甚么信息？在定位成绩的缘故原由，和想法办理成绩的时分，起首要明白的是究竟是那里呈现了成绩。比方看到这个画面，您应当分明地意想到一点：这是ASP.NET抛出的非常，换句话说，IIS并没有把它看成长短法的URL，它仍是老厚道实地将URL交给ASP.NETISAPI处置。因而，我们即可以动用IIS级其余URLRewrite，在进进ASP.NET实行引擎之前，就把URL交换成可承受的情势：
RewriteRule^/products/([^?]*)?(.+)/products?$2&keywords=$1[I,L,U]
RewriteRule^/products/([^?]*)/products?keywords=$1[I,L,U]第一行应对的是带有QueryString的情形，而第二行则是没有QueryString的情形。这里用到的组件是IIRF（IonicsIsapiRewriteFilter），这是一款开源产物，一年半前的文章里我保举的也是这个，如今它已有了晋级。它的功效即是在进进ASP.NETISAPI之前，就将URL重写为其他情势：

登录/注册后可看大图

底本在第3步会呈现的BadRequest，因为已在第2步被URLRewrite成正当的情势。因而残剩的处置也就没有任何成绩了。
这些内容在一年半前的文章内已提过，不外如今既然有了ASP.NETMVC，则事变又变得更加庞大。由于ASP.NETRouting除“婚配”URL的功效以外，还担当着“组装”URL的职责。因而，让ASP.NETRouting可以辨认出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划定规矩——只不外此时的RouteValue中的keywords字段已不是用户输出的内容了（由于用户输出的/products/xxx，已被重写为/products?keywords=xxx）。换句话说，假如有以下的Action，那末它的keywords参数则永久是空字符串：
publicActionResultList(stringkeywords){...}幸亏，ASP.NETMVC中存在ModelBinder机制，我们能够编写一个ModelBinder来指定这个参数的猎取地位：
publicclassFromQueryBinder:IModelBinder
{
publicobjectBindModel(ControllerContextcontrollerContext,ModelBindingContextbindingContext)
{
returncontrollerContext.HttpContext.Request.QueryString[bindingContext.ModelName];
}
}
再将其使用到List的keywords参数上往：
publicActionResultList(
[ModelBinder(typeof(FromQueryBinder))]stringkeywords)
因为参数名是keywords，因而bindingContext.ModelName也是keywords，因而从QueryString中即可以取到我们必要的内容了。至于在举行URL天生的时分，我们仍是能够之间一样增加一个keywords字段到RouteValue中往，因而在我们先前设置的Route划定规矩中便会组装成符合的Path了（即/products/xxx）。
在这个例子中，我们让keywords婚配Path后端全体内容，可是假如是Path两头某一段必要有特别字符怎样办呢？实在也一样，只是在举行URLRewrite的时分，必要在终极重写的时分填写一个“假”的值就能够了，如如许的Route划定规矩：
routes.MapRoute(
"Product.List",
"products/{keywords}/page",
new{controller="Product",action="List"});
而IIS级其余URLRewrite重写的划定规矩就能够是：
RewriteRule^/products/([^/]*)/(.*)/products/useless-segement/$2?keywords=$1[I,L,U]如许，假如用户输出/products/xxx/2就会被重写成/products/useless-token/2?keywords=xxx——现实上，在第一个示例中我们也能够这么做，只是我“不习气”增添一个假造的值罢了。
以上办理计划能够在IIS6与IIS7的ClassicMode中一般利用，只惋惜在IIS7的IntergratedMode中，多是因为ASP.NET接受了IIS的部分逻辑，因而会很早抛出“IIS级别”，而不是“ASP.NET级别”的BadRequest非常。假如您碰到了这类体例，就必需经由过程以下三个步骤来挣脱这个贫苦的成绩了：
设置AllowRestrictedChars：KB820129（让IIS7承受特别字符）
设置VerificationCompatibility：KB826437中除“安装.NET1.1SP1”之外的步骤（让ASP.NET承受特别字符）
将ASP.NET页面的ValidateRequest设为False
实在您只需经由了这三步修正，关于今朝这个案例，即便不必IIS级其余URLRewrite应当也没有成绩了。
语言是不是不是最重要的？

现在主流的网站开发语言无外乎asp、php、asp.net、jsp等。

由于JSP/Servlet都是基于Java的，所以它们也有Java语言的最大优点——平台无关性，也就是所谓的“一次编写，随处运行（WORA–WriteOnce,RunAnywhere）”。除了这个优点，JSP/Servlet的效率以及安全性也是相当惊人的。

PHP的源代码完全公开，在OpenSource意识抬头的今天，它更是这方面的中流砥柱。不断地有新的函数库加入，以及不停地更新，使得PHP无论在UNIX或是Win32的平台上都可以有更多新的功能。它提供丰富的函数，使得在程式设计方面有着更好的资源。目前PHP的最新版本为4.1.1，它可以在Win32以及UNIX/Linux等几乎所有的平台上良好工作。PHP在4.0版后使用了全新的Zend引擎，其在最佳化之后的效率，比较传统CGI或者ASP等技术有了更好的表现。

同时也感谢博客园给我们这个平台，也感谢博客园的编辑们做成专题引来这么多高人指点。

虽然在形式上JSP和ASP或PHP看上去很相似——都可以被内嵌在HTML代码中。但是，它的执行方式和ASP或PHP完全不同。在JSP被执行的时候，JSP文件被JSP解释器（JSPParser）转换成Servlet代码，然后Servlet代码被Java编译器编译成.class字节文件，这样就由生成的Servlet来对客户端应答。所以，JSP可以看做是Servlet的脚本语言（ScriptLanguage）版。

ASP.Net和ASP的最大区别在于编程思维的转换，而不仅仅在于功能的增强。ASP使用VBS/JS这样的脚本语言混合html来编程，而那些脚本语言属于弱类型、面向结构的编程语言，而非面向对象。

JSP/Servlet虽然在国内目前的应用并不广泛，但是其前途不可限量。

最强的技术支持WebService,而且有.NET的所有library做后盾。而且ASP.NET在.NET3.5中还有微软专门为AJAX开发的功能--ASP.NETAJAX。

由于CGI程序每响应一个客户就会打开一个新的进程，所以，当有多个用户同时进行CGI请求的时候，服务器就会打开多个进程，这样就加重了服务器的负担，使服务器的执行效率变得越来越低下。