Url地址重写.doc

Url地址重写本文章描述了Url的概念，Url地址为什么要重写， Url重写的流程等方面的内容什么是Url地址重写2参照文件2适用范围2为什么要URL重写2Url地址重写的几种常见方法3使用 HTTP 模块执行 URL 重写4Known Issues7Conflict with Visual Studio Add-Ins7Cryptographic Services8Visual Studio Templates9Add View Tool and Unicode Characters9什么是Url地址重写URL重写就是首先获得一个进入的URL请求然后把它重新写成网站可以处理的另一个URL的过程。举个例子来说，如果通过浏览器进来的URL是“/UserProfile/1.aspx”，那么它可以被重写成 “/UserProfile.aspx?ID=1”这样的URL，这样的网址可以更好的被网站所阅读.参照文件微软技术文档 /zh-cn/library/bb507200.aspx.适用范围Microsoft ASP.NET为什么要URL重写创建数据驱动的 ASP.NET 网站时，通常会产生一个单个的网页，该网页基于查询字符串参数显示数据库数据的子集。例如，在设计电子商务站点时，您的任务之一便是允许用户浏览待售产品。为此，您可以创建一个名为 displayCategory.aspx 的页面，该页面将显示给定类别的产品。可以通过查询字符串参数来指定要查看的该类别的产品。也就是说，如果用户要浏览待售的 Widget 产品，并且所有 Widget 产品的 CategoryID 均为 5，则用户可以访问以下网址：/displayCategory.aspx?CategoryID=5。创建具有此类 URL 的网站有两点不足：首先，从最终用户的角度考虑，URL /displayCategory.aspx?CategoryID=5 比较杂乱。可用性专家 Jakob Neilsen 建议遵循以下标准来选择 URL： 简短。 易于键入。 可以看出站点的结构。 “可删节”，允许用户通过删除 URL 的组成部分来浏览站点。 我还要增加一条标准，即，URL 应该便于记忆。URL /displayCategory.aspx?CategoryID=5 不符合 Neilsen 的任何标准，也不容易记住。要求用户键入查询字符串值将使 URL 的键入变得非常困难，并且只有了解查询字符串参数的用途及其名称/值对结构的富有经验的 Web 开发人员才能够对 URL 进行“删节”。 较好的方法是允许使用切合实际且容易记忆的 URL，如 /products/Widgets。只要看一眼 URL，您便可以推断出将要显示的内容 - 有关 Widget 的信息。此 URL 也很容易记住和共享。我可以告诉我的同事“请查看 /products/Widgets，”，她可能无需再次问我 URL 是什么即可打开该页面。（尝试一下，您只需说出“A 页面”即可！）此 URL 还将显示出来，并且应该是“可删节”的。也就是说，如果用户删去 URL 的末端，键入 /products，他们应该看到所有产品的列表，或者至少应该看到他们可以查看的所有类别的产品列表。注意：要获得“可删节”URL 的最好示例，可考虑使用由许多 blog 引擎生成的 URL。要查看 2004 年 1 月 28 日的帖子，用户可以访问诸如 /2004/01/28 的 URL。如果该 URL 被删节为 /2004/01，用户将看到 2004 年 1 月的所有帖子。将该 URL 进一步删节为 /2004 将显示 2004 年的所有帖子。除了简化 URL 之外，URL 重写还经常用于处理网站重组，以免导致大量链接断开或书签过期。Url地址重写的几种常见方法1 可以使用 ISAPI 筛选器在 IIS Web 服务器级别实现 URL 重写.2 可以使用 HTTP 模块或 HTTP 处理程序在 ASP.NET 级别实现 URL 重写注：本文重点介绍如何使用 ASP.NET 实现 URL 重写（通过HTTP模块）使用 HTTP 模块执行 URL 重写为 URL 重写引擎指定配置信息让我们先介绍一下 Web.config 文件中重写规则的结构。首先，您需要在 Web.config 文件中指明要使用 HTTP 模块还是 HTTP 处理程序来执行 URL 重写。在下载代码中，Web.config 文件包含两个已注释掉的条目：!- -!- -注释掉 条目，以使用 HTTP 模块执行重写；注释掉 条目，以使用 HTTP 处理程序执行重写。除了指定使用 HTTP 模块还是 HTTP 处理程序执行重写外，Web.config 文件还包含重写规则：重写规则由两个字符串组成：要在被请求的 URL 中查找的模式；要替换此模式的字符串（如果找到）。在 Web.config 文件中，此信息是使用以下语法表达的： 要查找的模式 要用来替换模式的字符串 要查找的模式 要用来替换模式的字符串 . 每个重写规则均由 元素表达。要搜索的模式由 元素指定，而要替换所找到的模式的字符串将在 元素中输入。这些重写规则将从头到尾进行计算。如果发现与某个规则匹配，URL 将被重写，并且对重写规则的搜索将会终止。在 元素中指定模式时，请注意，要使用正则表达式来执行匹配和字符串替换。（稍后，我们将介绍一个真实的示例，说明如何使用正则表达式来搜索模式。）由于模式是正则表达式，应确保转义正则表达式中的任何保留字符。（一些正则表达式保留字符包括：.、?、$ 及其他。可以通过在前面加反斜杠（如 .）对这些字符进行转义，以匹配文字句点。）使用 HTTP 模块执行 URL 重写创建 HTTP 模块与创建可以实现 IHttpModule 接口的类一样简单。IHttpModule 接口定义了两种方法： Init(HttpApplication)。此方法在初始化 HTTP 模块后触发。在此方法中，您将把事件处理程序绑定到相应的 HttpApplication 事件。 Dispose()。当请求已完成并已发送回 IIS 时调用此方法。您应当在此处执行所有最终的清除操作。 为了便于为 URL 重写创建 HTTP 模块，我将从创建抽象基类 BaseModuleRewriter 开始介绍。此类将实现 IHttpModule。在 Init() 事件中，它将 HttpApplication 的 AuthorizeRequest 事件绑定到 BaseModuleRewriter_AuthorizeRequest 方法。BaseModuleRewriter_AuthorizeRequest 方法将调用该类传入被请求的 Path 的 Rewrite() 方法，以及传入 Init() 方法的 HttpApplication 对象。Rewrite() 方法是抽象的，也就是说，在 BaseModuleRewriter 类中，Rewrite() 方法没有方法主体；从 BaseModuleRewriter 派生而来的类必须覆盖此方法并提供方法主体。具有此基类后，只需创建由 BaseModuleRewriter 派生的类即可，该类可以覆盖 Rewrite() 并在那里执行 URL 重写逻辑。下面显示了 BaseModuleRewriter 的代码。public abstract class BaseModuleRewriter : IHttpModule public virtual void Init(HttpApplication app) / 警告！此代码不适用于 Windows 身份验证！ / 如果使用 Windows 身份验证， / 请改为 app.BeginRequest app.AuthorizeRequest += new EventHandler(this.BaseModuleRewriter_AuthorizeRequest); public virtual void Dispose() protected virtual void BaseModuleRewriter_AuthorizeRequest( object sender, EventArgs e) HttpApplication app = (HttpApplication) sender; Rewrite(app.Request.Path, app); protected abstract void Rewrite(string requestedPath, HttpApplication app);请注意，BaseModuleRewriter 类将在 AuthorizeRequest 事件中执行 URL 重写。如上所述，如果将 Windows 身份验证与文件授权结合使用，您需要对此做出更改，以便可以在 BeginRequest 或 AuthenticateRequest 事件中执行 URL 重写。ModuleRewriter 类扩展了 BaseModuleRewriter 类，并负责执行实际的 URL 重写。ModuleRewriter 包含单一覆盖方法（Rewrite()），如下所示：protected override void Rewrite(string requestedPath, System.Web.HttpApplication app) / 获得配置规则 RewriterRuleCollection rules = RewriterConfiguration.GetConfig().Rules; / 遍历每个规则. for(int i = 0; i rules.Count; i+) / 获得要查找的模式，并且 / 解析 Url（转换为相应的目录） string lookFor = + RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, rulesi.LookFor) + $; / 创建 regex（请注意，已设置 IgnoreCase.） Regex re = new Regex(lookFor, RegexOptions.IgnoreCase); / 查看是否找到了匹配的规则 if (re.IsMatch(requestedPath) / 找到了匹配的规则 - 进行必要的替换 string sendToUrl = RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath, re.Replace(requestedPath, rulesi.SendTo); / 重写 URL RewriterUtils.RewriteUrl(app.Context, sendToUrl); break; / 退出 For 循环 Rewrite() 方法从获取 Web.config 文件中的一组重写规则开始。然后，它将遍历重写规则，每次遍历一个，对于每个规则，它将获取规则的 LookFor 属性，并使用正则表达式来确定是否在被请求的 URL 中找到了匹配的规则。如果找到了匹配的规则，将在具有 SendTo 属性值的被请求路径上执行正则表达式替换。然后，替换后的 URL 将被传递到 RewriterUtils.RewriteUrl() 方法中。RewriterUtils 是一个 helper 类，此类将提供一对由 URL 重写 HTTP 模块和 HTTP 处理程序使用的静态方法。RewriterUrl() 方法仅调用 HttpContext 对象的 RewriteUrl() 方法。注意：您可能已注意到，执行正则表达式匹配和替换时，将调用 RewriterUtils.ResolveUrl()。此 helper 方法只替换具有应用程序路径值的字符串中的所有 实例。URL 重写引擎的整个代码可随本文下载。我们已经介绍了大部分密切相关的组件，但还有一些其他组件（例如，对 Web.config 文件中 XML 格式的重写规则进行反序列化以使其成为对象的类），以及用于 URL 重写的 HTTP 处理程序工厂。本文剩余的三个部分将对 URL 重写的实际使用情况进行介绍。配置IIS