ASP.NET 整理比较全的URL重写解决方案

常常有人请我指导应该如何动态地“重写”URL，以在他们的ASP.NETweb应用中发布比较干净的URL端点。这个博客帖子概述了几个方法，你能够用来在ASP.NET中干净地映射或重写URL，以及按照你本身的需求组织你的URL的结构。

为何URL映射和重写很重要？

下面是开发人员想要对URL有更大的灵活性的最多见的场景：

1) 处理这样的情形：你要更改你的web应用中网页的结构，但你同时也要确保在你移动网页后，那些被人收藏的老URL不会成为死连接。重写URL容许你透明地将请求转交到新的网页地址而不出错。

2) 在象Google，Yahoo 和 Live 这样的搜索引擎中提升你网站上网页的搜索相关性。具体地来讲，URL重写常常能使你在你网站上网页的URL里更加容易地嵌入关键词，这么作每每会增长别人 点击你的连接的机会。从使用查询字符串参数到使用彻底限定(fully qualified)的URL也能在某些情形下提升你在搜索引擎结果中的优先顺序。使用强制referring连接使用一样的大小写(same case)和URL入口(譬如，使用weblogs.asp.net/scottgu 而不是 weblogs.asp.net/scottgu/default.aspx)的技术也能避免因跨越多个URL而形成的网页排名(pagerank)的降 低(avoid diluting your pagerank across multiple URLs)，从而增长你的搜索结果。

在一个搜索引擎日渐驱动网站访问量的世界里，在你的网页排名上稍微获得一些提升就能给你的业务带来不错的投资回报(ROI)。逐渐地，这驱使开发人 员使用URL重写以及其余SEO(搜索引擎优化 )技术来优化网站(注，SEO是个步调很快的空间，增长你的搜索相关性的建议月月在演变)。想了解一些关于搜索引擎优化方面好的建议的话，我建议你阅读一 下《SSW Rules to Better Google Rankings (SSW的提升Google排名之要领)》，以及MarketPosition关于《how URLs can affect top search engine ranking (URL会如何影响顶级搜索引擎排名)》的文章。

例程的URL重写场景

为这个博客贴子起见，我将假设咱们将在一个应用里建造一套电子商务的产品目录网页，产品是按种类来组织的(譬如，图书，录像，CD，DVD等等)。

让咱们假定一开始咱们有个网页叫Products.aspx，经过查询字符串参数接受一个类别名称，相应地过滤显示的产品。与这个Products.aspx网页对应类别的URL看上去象这样：

http://www.store.com/products.aspx?category=books
http://www.store.com/products.aspx?category=DVDs
http://www.store.com/products.aspx?category=CDs

但咱们不想使用查询字符串来呈示每一个类别，咱们想修改应用，让每一个产品类别对搜索引擎来讲看上去象是一个独特的URL，而且在实际的URL中嵌入关 键词(而不是经过查询字符串参数)。咱们将在这个博客帖子剩下来的篇幅里，讨论一下达成这个目的咱们能够采起的4种不一样方法。

方法一：使用Request.PathInfo 参数而不是查询字符串

我将示范的第一个方法根本不使用URL重写，而是使用ASP.NET中不太为人所知的一个特性，Request的PathInfo属性。为帮助解释这个属性的有用之处，考虑一下咱们电子商店下面这些URL的情形：

http://www.store.com/products.aspx/Books
http://www.store.com/products.aspx/DVDs
http://www.store.com/products.aspx/CDs

你会在上面这些URL中注意到的一个东西是，他们再也不含有查询字符串值，取而代之的是，类别参数的值是附加到URL上的，是以 Products.aspx网页处理器名称以后的/参数 值的方式出现的。而后，一个自动化的搜索引擎爬虫(search engine crawler)会把这些URL解释成三个不一样的URL，而不是一个URL带有三个不一样的输入值 (搜索引擎是不理会文件扩展名的，只把它看成URL中的另外一个字符而已)。

你也许很想知道怎么在ASP.NET中处理这个附加的参数的情形。好消息是，这很是简单。只要使用Request的PathInfo属性就能够了， 该属性返回URL中紧随 products.aspx 后面的那部份内容。因此，对上面这些URL， Request.PathInfo会分别返回 “/Books”， “/DVDs”，和 “/CDs”(万一你想知道的话， Request的Path 属性返回“/products.aspx” )。

而后，你能够轻易地编写一个函数来获取产品类别，象这样(下面这个函数去除前面的斜杠字符，只返回“Books”，“DVDs”，或 “CDs”)：

     Function  GetCategory()  As String

        If  (Request.PathInfo.Length  =  0 )  Then
            Return  ""
         Else
            Return  Request.PathInfo.Substring( 1 )
         End If

    End Function

样例下载：我创建的一个展现这个技术的样例应用能够在这里下载。这个样例和这个技术的很好的地方在于，为部署使用这个方法的ASP.NET应用，不需做任何服务器配置改动。在共享主机的环境里，这个技术也行之有效。

方法二：使用HttpModule实现URL重写

上述Request.PathInfo技术的替换方法是，利用ASP.NET提供的HttpContext.RewritePath方法。这个方法容许开发人员动态地重写收到的URL的处理路径，而后让ASP.NET使用刚重写事后的路径来继续执行请求。

譬如，咱们能够选择向大众呈示下列URL：

http://www.store.com/products/Books.aspx
http://www.store.com/products/DVDs.aspx
http://www.store.com/products/CDs.aspx

在外界看来，网站上有三个单独的网页(对搜索爬虫而言，这看上去很棒)。经过使用 HttpContext的RewritePath方法，咱们能够在这些请求刚进入服务器时，动态地把收到的URL重写成单个Products.aspx网 页接受一个查询字符串的类别名称或者PathInfo参数。譬如，咱们可使用Global.asax中的 Application_BeginRequest事件，来这么作：

     void  Application_BeginRequest( object  sender, EventArgs e) {

         string  fullOrigionalpath  =  Request.Url.ToString() ;
        
        if  (fullOrigionalpath.Contains( "/Products/Books.aspx" )) {
            Context.RewritePath( "/Products.aspx?Category=Books" ) ;
         }
         else if  (fullOrigionalpath.Contains( "/Products/DVDs.aspx" )) {
            Context.RewritePath( "/Products.aspx?Category=DVDs" ) ;
         }
    } 

手工编写象上面这样的编码的坏处是，很枯燥乏味，并且容易犯错。我建议你别本身写，而是使用网上现成的HttpModule来完成这项工做。这有几个你如今就能够下载和使用的免费的HttpModule：

• UrlRewriter.net
•  
• UrlRewriting.net

这些模块容许你用声明的方式在你应用的web.config文件里表达匹配规则。譬如，在你应用的web.config文件里使用UrlRewriter.Net模块来把上面的那些URL映射到单个Products.aspx页上，咱们只要把这个web.config文件添加到咱们的应用里去就能够了(不用任何编码)：

< ?xml  version ="1.0"?>

< configuration >

   < configSections >
     < section  name ="rewriter"   
             requirePermission ="false"  
             type ="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter"   />
  </ configSections >
  
   < system.web >
      
     < httpModules >
       < add  name ="UrlRewriter"  type ="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"/>
    </ httpModules >
    
   </ system.web >

   < rewriter >
     < rewrite  url ="~/products/books.aspx"  to ="~/products.aspx?category=books"   />
    < rewrite  url ="~/products/CDs.aspx"  to ="~/products.aspx?category=CDs"   />
    < rewrite  url ="~/products/DVDs.aspx"  to ="~/products.aspx?category=DVDs"   />
  </ rewriter >   
  
</ configuration >  

上面的HttpModule URL重写模块还支持正则表达式和URL模式匹配(以免你在web.config 文件里硬写每一个URL)。因此，不用写死类别名称，你能够象下面这样重写匹配规则，把类别名称动态地从任何/products/[类别].aspx组合的 URL里取出来：

   < rewriter >
     < rewrite  url ="~/products/(.+).aspx"  to ="~/products.aspx?category=$1"   />
  </ rewriter >   

这使得你的编码极其干净，而且扩展性很是之好。

样例下载：我创建的一个使用UrlRewriter.Net模块展现这个技术的样例应用能够在这里下载。

这个样例和这个技术的很好的地方在于，为部署使用这个方法的ASP.NET应用，不需做任何服务器配置改动。在设置为中等信任安全等级 (medium trust)的共享主机的环境里，这个技术也行之有效 (只要把文件FTP/XCOPY到远程服务器就能够了，不须要安装)。

方法三：在IIS7中使用HttpModule 实现无扩展名的URL重写

上述的HttpModule方法在你要重写的URL含有.aspx 扩展名或者包含另外一个被设置为ASP.NET处理的扩展名的情形下一切都工做。你这么作的话，不须要任何特定的服务器配置，你只要把你的应用拷贝到远程服务器，它会正常工做的。

但有的时候，你要重写的URL要么拥有一个不为ASP.NET处理的文件扩展名(譬如， .jpg， .gif， 或 .htm)，要么根本没有扩展名。譬如，咱们也许要把这些URL呈示成公开的产品目录网页(注意，它们没有 .aspx 扩展名)：

http://www.store.com/products/Books
http://www.store.com/products/DVDs
http://www.store.com/products/CDs

在 IIS5 和 IIS6 中，使用ASP.NET处理上面这样的URL不是很容易。 IIS 5/6 使得在ISAPI扩展(ASP.NET就是这样一个扩展)里很是难以重写这些类型的URLS。你须要作的是使用ISAPI过滤器在IIS请求管道 (request pipeline)的较早期实现重写。我将在下面的第四个方法里示范如何在 IIS5/6 实现这样的重写。

但好消息是， IIS 7.0使得处理这类情形容易之极。你如今能够在 IIS 请求管道的任何地方执行一个HttpModule，这意味着你可使用上面的URLRewriter 模块 来处理和重写无扩展名的URL(甚至是带有 .asp，.php，或 .jsp 扩展名的URL)。下面示范了你在IIS7中该如何配置：

< ?xml  version ="1.0"  encoding ="UTF-8"?>

< configuration >

   < configSections >
     < section  name ="rewriter"  
             requirePermission ="false"  
             type ="Intelligencia.UrlRewriter.Configuration.RewriterConfigurationSectionHandler, Intelligencia.UrlRewriter"   />
  </ configSections >
  
   < system.web >
      
     < httpModules >
       < add  name ="UrlRewriter"  type ="Intelligencia.UrlRewriter.RewriterHttpModule, Intelligencia.UrlRewriter"   />
    </ httpModules >
    
   </ system.web >

   < system.webServer >

     < modules  runAllManagedModulesForAllRequests ="true">
       < add  name ="UrlRewriter"  type ="Intelligencia.UrlRewriter.RewriterHttpModule"   />
    </ modules >

     < validation  validateIntegratedModeConfiguration ="false"   />

  </ system.webServer >

   < rewriter >
     < rewrite  url ="~/products/(.+)"  to ="~/products.aspx?category=$1"   />
  </ rewriter >
  
</ configuration >

注意一下<system.webServer>内<modules>部分设置为true的 runAllManagedModulesForAllRequests属性。这个属性确保来自Intelligencia的 UrlRewriter.Net模块(是在IIS7正式发布前编写的)，会被调用，有机会重写到服务器的全部URL请求(包括文件夹)。上面的 web.config文件很是酷之处在于：

1) 它在任何IIS7机器上都会工做，你不须要管理员在远程主机上启用任何东西，它也能在设置为中等信任安全等级(medium trust)的共享主机的环境场景下工做。

2) 由于我在<httpModules>和 IIS7 的<modules> 部分同时配置了UrlRewriter，我既能在 VS内置的web服务器(即Cassini)中，也能在IIS7下使用一样的URL重写规则。二者彻底支持无扩展名的URL重写。这使得测试和开发很是容 易。

IIS 7.0 将在今年的晚些时候做为Windows Longhorn服务器的一部分发布，将在几个星期内随Beta3版本的发布支持go-live许可。因为添加到IIS7中的全部的新宿主 (hosting)特性，咱们预期主机供应商将会很是快地开始积极提供IIS7帐号，这意味着你应该很快就能够开始利用上述的无扩展名的URL重写支持。 咱们将在 IIS7 RTM 时段里发布一个为微软所支持的URL重写模块，该模板是免费的，你能够在IIS7上使用，而且这模块将对你web服务器上的全部内容的高级URL重写场景 提供很好的支持。

样例下载：我创建的一个使用IIS7和UrlRewriter.Net模块展现无扩展名URL重写技术的样例应用能够在这里下载。

方法四：在IIS5和IIS6中使用 ISAPIRewrite 来实现无扩展名的URL重写

若是你不想等到IIS7出来才利用无扩展名的URL重写，那么你最好的措施是使用ISAPI过滤器来重写URL。我知道有2个ISAPI过滤器方案，你也许要去看一下：

• Helicon Tech's ISAPI Rewrite: 他们提供一个99美圆(可免费试用30天)的ISAPI URL重写产品完整版，以及一个免费的轻量级版本。
•  
• Ionic's ISAPI Rewrite: 这能够免费下载(源码和可执行文件均可如下载)

我没亲手用过上面的产品，虽然我听过到对这2个产品的好评。Scott Hanselman和 Jeff Atwood 最近都写了精彩的博客贴子讲述使用这些产品的体验，同时提供了一些如何在这些产品中配置匹配规则的例子。Helicon Tech的ISAPI Rewrite的规则使用跟 Apache的mod_rewrite一样的句法，譬如(取自Jeff的博客贴子)：

[ISAPI_Rewrite]
# fix missing slash on folders
# note, this assumes we have no folders with periods!
RewriteCond Host: (.*)
RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [RP]

# remove index pages from URLs
RewriteRule (.*)/default.htm$ $1/ [I,RP]
RewriteRule (.*)/default.aspx$ $1/ [I,RP]
RewriteRule (.*)/index.htm$ $1/ [I,RP]
RewriteRule (.*)/index.html$ $1/ [I,RP]

# force proper www. prefix on all requests
RewriteCond %HTTP_HOST ^test\.com [I]
RewriteRule ^/(.*) http://www.test.com/$1 [RP]

# only allow whitelisted referers to hotlink images
RewriteCond Referer: (?!http://(?:www\.good\.com|www\.better\.com)).+
RewriteRule .*\.(?:gif|jpg|jpeg|png) /images/block.jpg [I,O]

必定要去读一下Scott和Jeff的贴子以了解这些ISAPI 模块的详情，以及你都能用它们作些什么。

注：使用ISAPI过滤器的一个坏处是，共享主机环境通常不容许你安装这样的组件，因此你要用它们的话，你要么须要一个专用的虚拟主机服务器，要么 须要一个专用的主机服务器。但，若是你有一个主机计划容许你安装ISAPI的话，这会在IIS5/6下会提供最大的灵活性，让你过渡到IIS7推出为止。

在URL重写里处理ASP.NET PostBack

你们在使用ASP.NET和重写URL时常常遇到的一个疑难杂症跟处理postback场景有关。具体地来讲，当你在一个网页上放置一个 <form runat="server"> 控件时，ASP.NET 会自动地默认输出标识的action属性指向当前所在页面。当使用URL重写时，会出现这样的问题，<form> 控件显示的URL不是原先请求的URL(譬如，/products/books)，而是重写事后的URL(譬如， /products.aspx?category=books)。这意味着，当你作一个postback到服务器时，URL再也不是你原先干净利落的那个 了。

在 ASP.NET 1.0 和1.1 中，你们常常诉诸于继承<form> 控件生成他们本身的控件，来正确地输出要使用的action属性。虽然这能够工做，但结果有点乱，由于这意味着你须要更新你全部的页面来使用这个另外的表 单控件，并且有时在Visual Studio所见即所得设计器里也会赶上问题。

好消息是，在ASP.NET 2.0中，有个比较干净的诀窍你能够用来重写<form>控件的action属性。具体地来讲，你可利用新的ASP.NET 2.0控件适配器扩展架构来定制控件的输出，用你提供的值来覆盖action属性的值。这不要求在你的.aspx页面里作任何编码改动，而只要在你的/app_browsers文件夹里添加一个.browser文件，注册使用一个控件适配类便可输出新的action属性。

 

你可在这里查看一个我建立的样例实现，其展现了该如何实现与URL重写协做的表单控件适配器(Form Control Adapter) 。它在我上面使用的第一个(Request.PathInfo)，第二个方法(UrlRewriter.Net 模块)中都工做，它使用Request的RawUrl属性获取原先没改写过的 URL来显示。而在第四个方法(ISAPIRewrite过滤器)中，你能够获取ISAPI过滤器保存在 Request.ServerVariables["HTTP_X_REWRITE_URL"] 中的原先的URL值。

我上面的FormRewriter类实如今标准的ASP.NET和ASP.NET AJAX 1.0网页上应该都工做(若是你赶上问题的话，告诉我一声)。

正确地处理CSS和图像引用

很多人在第一次使用URL重写时，有时会赶上一个疑难杂症，就是他们发现他们的图像和CSS样式表引用有时会中止工做。这是由于他们在HTML网页 里有对这些文件的相对引用，当你开始在应用里重写URL时，你须要意识到浏览器常常会在不一样的逻辑层次结构层上(logical hierarchy levels)请求文件，而不是实际存储在服务器上的东西。

譬如，若是咱们上面的/products.aspx网页对.aspx 网页里的logo.jpg有一个相对引用，可是经过 /products/books.aspx这个URL来请求的，那么浏览器在显示网页时，将会发出一个对/products/logo.jpg的请求，而 不是对/logo.jpg的请求。要正确地引用这个文件，确认你用根目录限定了(root qualify)CSS和图像引用(“/style.css”，而不是 “style.css”)。对于ASP.NET控件，你也可使用“~”句法从你应用的根目录来引用文件(譬如，<asp:image imageurl="~/images/logo.jpg" runat="server"/>) 。

 

出处：http://www.cnblogs.com/ajunForNet/archive/2012/05/19/2509212.html