在ASP.NET中执行URL重写(六)

在这种情况下，如果用户访问 /2004/02/14.aspx，我们需要将 URL 重写为 ShowBlogContent.aspx?year=2004&month=2&day=14。所有三种情况（URL 指定了年、月和日时；URL 仅指定了年和月时；URL 仅指定了年时）均可使用重写规则进行处理：

<RewriterConfig>
<Rules>
<!-- Blog 内容显示程序规则 -->
<RewriterRule>
<LookFor>~/(\d{4})/(\d{2})/(\d{2})\.aspx</LookFor>
<SendTo>~/ShowBlogContent.aspx?year=$1&month=$2&day=$3</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/(\d{4})/(\d{2})/Default\.aspx</LookFor>
<SendTo><![CDATA[~/ShowBlogContent.aspx?year=$1&month=$2]]></SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>~/(\d{4})/Default\.aspx</LookFor>
<SendTo>~/ShowBlogContent.aspx?year=$1</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>

这些重写规则表明了正则表达式的功能。在第一个规则中，我们使用模式 (\d{4})/(\d{2})/(\d{2})\.aspx 查找 URL。在简明英语中，它对应了这样一个字符串：首先是四个数字，后跟一个斜杠，然后是两个数字，后跟一个斜杠，然后再跟两个数字，最后是一个 .aspx。每个数字组周围的括号非常重要，通过它可以在相应的 <SendTo> 属性中引用这些括号内的匹配字符。 特别是，我们可以针对第一、第二和第三个括号组分别使用 $1、$2 和 $3 引用回括号内的匹配组。

注意：由于 Web.config 文件采用 XML 格式，但是必须对元素文字部分中的字符（如 &、< 和 >）进行转义。在第一个规则的 <SendTo> 元素中，& 被转义为 &。在第二个规则的 <SendTo> 中使用了另外一种技术（使用 <![CDATA[...]]> 元素），无需对内部的内容进行转义。可以使用两种方法中的任何一种，并且都会得到相同的结果。

图 5、6 和 7 显示了操作中的 URL 重写。数据实际上是从我的 blog http://scottonwriting.net/ 中拖过来的。图 5 中显示了 2003 年 11 月 7 日的帖子；图 6 中显示了 2003 年 11 月的所有帖子；图 7 显示了 2003 年的所有帖子。

 

图 5. 2003 年 11 月 7 日的帖子

图 6. 2003 年 11 月的所有帖子

图 7. 2003 年的所有帖子

注意：URL 重写引擎在 <LookFor> 元素中需要使用正则表达式模式。如果您对正则表达式不熟悉，可以阅读我在早些时候编写的一篇文章 An Introduction to Regular Expressions。另外，还有一个很好的网站：RegExLib.com，在那里您可以获取有关常用正则表达式的帮助信息，还可以共享您自己的自定义正则表达式。

构建必备的目录结构
当请求 /2004/03/19.aspx 时，IIS 将通知 .aspx 扩展，并将请求路由到 ASP.NET 引擎。请求在 ASP.NET 引擎的管道中移动时，URL 将被重写为 ShowBlogContent.aspx?year=2004&month=03&day=19，并且访问者会看到 2004 年 3 月 19 日的 blog 条目。但是当用户浏览到 /2004/03/ 时将会发生什么情况呢？除非有一个 /2004/03/ 目录，否则 IIS 将返回一个 404 错误。此外，此目录中还需要具有 Default.aspx 页面，以便可以将请求传递给 ASP.NET 引擎。

因此，要使用这种方法，必须手动创建一个用于每年的目录（其中包含 blog 条目），并且目录中具有一个 Default.aspx 页面。另外，在每年目录中，您需要再手动创建十二个目录（01、02、?、?...、12），并且每个目录中均有一个 Default.aspx 文件。（如上所述，我们还必须执行前面演示中的操作，即在 /Products/ 目录中添加一个 Default.aspx 文件，以便访问 /Products/ 时可以正确显示 ListCategories.aspx。）

很显然，添加这样一个目录结构可能是一件很痛苦的事情。解决此问题的方法是使所有传入的 IIS 请求都映射到 ASP.NET 引擎。通过这种方法，即使访问 URL /2004/03/，IIS 也会如实地将请求传递给 ASP.NET 引擎（即使并不存在 /2004/03/ 目录）。但是，使用这种方法将使 ASP.NET 引擎负责处理到达 Web 服务器的所有类型的传入请求，包括图像、CSS 文件、外部 &#106avascript 文件、Macromedia Flash 文件，等等。

对处理所有文件类型的全面讨论远远超出了本文的范围。有关使用此技术的 ASP.NET Web 应用程序的示例，请参阅 .Text，一个开放源 blog 引擎。.Text 可以配置为将所有请求均映射到 ASP.NET 引擎。它可以使用自定义 HTTP 处理程序来处理生成所有文件类型的问题，自定义 HTTP 处理程序了解如何生成典型的静态文件类型（图像、CSS 文件，等等）。

返回页首
结论
在本文中，我们讨论了如何在 ASP.NET 级别通过 HttpContext 类的 RewriteUrl() 方法来执行 URL 重写。正如我们所看到的，RewriteUrl() 更新了特定的 HttpContext's Request 属性，从而更新了被请求的文件和路径。最终结果是，从用户角度来看，他们要访问某个特定的 URL，但从 Web 服务器端来看，被请求的却是另一个 URL。

可以在 HTTP 模块或 HTTP 处理程序中重写 URL。在本文中，我们介绍了如何使用 HTTP 模块执行重写，并讨论了在管道中的不同阶段执行重写的结果。

当然，如果执行 ASP.NET 级别的重写，则仅当已成功地将请求从 IIS 传递给 ASP.NET 引擎后才会发生 URL 重写。实际上，只有用户请求带 .aspx 扩展名的页面时才会出现这种情况。但是，如果您要使用户可以进入实际并不存在的 URL，但又希望重写到现有的 ASP.NET 页面，则必须创建虚拟目录和 Default.aspx 页面，或者对 IIS 进行配置，以使所有传入请求一律被路由到 ASP.NET 引擎。