【原文地址】Tip/Trick: Url Rewriting with ASP.NET
【原文发表日期】 Monday, February 26, 2007 9:27 PM
经常有人请我指导应该如何动态地“重写”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：
这些模块允许你用声明的方式在你应用的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重写技术的样例应用可以在这里下载。