该资源为电脑版，暂无安卓版
IIS URL Rewrite中文版是一款功能强大的iis url重写工具，而且IIS服务器变量甚至复杂的URL重写行为 程序规则，有需要的小伙伴欢迎下载使用！
IIS URL Rewrite是一款由微软官方推出的IIS URL重写工具。它能够帮助Web管理员创建强大的规则来实现用户更容易记住的URL，并且更容易让搜索引擎找到。通过使用规则模板，重写映射，.NET提供程序和集成到IIS管理器中的其他功能，Web管理员可以轻松设置规则来定义基于HTTP标头，HTTP响应或请求标头，IIS服务器变量甚至复杂的URL重写行为程序规则。另外，Web管理员还可以根据重写规则中表达的逻辑执行重定向，发送自定义响应或停止HTTP请求。
1、基于规则的URL重写引擎
2、基于规则的响应重写引擎
3、支持自定义.NET重写提供程序
4、正则表达式模式匹配
5、通配符模式匹配
6、全局和分布式重写规则
7、在特定HTML标记的内容中重写
8、出站规则的前提条件
9、访问服务器变量和HTTP头
10、重写服务器变量和HTTP请求头
11、重写HTTP响应头
12、允许列表服务器变量
13、HtmlEncode函数
14、内置规则模板
15、反向代理规则模板
16、搜索引擎优化的规则模板
17、各种规则操作，包括重定向和请求中止
18、在规则条件下跟踪捕获组
19、记录重写的URL
20、IIS管理器中更新的用户界面
21、用于管理重写规则和重写地图的集成用户界面
22、用于导入Apache mod_rewrite规则的集成用户界面
23、用于测试正则表达式和通配符模式的集成用户界面
24、支持IIS内核模式和用户模式输出缓存
25、小写转换功能
26、重写映射以在重写期间生成替换URL
27、失败的请求追踪支持
1、定义强大的规则将复杂的URL转换为简单和一致的Web地址
IIS URL Rewrite允许Web管理员使用.NET编写的重写提供程序，正则表达式模式匹配和通配符映射轻松构建功能强大的规则，以检查URL和其他HTTP标头和IIS服务器变量中的信息。可以编写规则来生成用户可以更容易记住的URL，这对搜索引擎进行索引很简单，并且允许URL遵循一致且规范的主机名格式。进一步简化了规则创建过程，支持内容重写，规则模板，重写映射，规则验证以及现有mod_rewrite规则的导入。
2、轻松替换Web应用程序URL以生成用户和搜索引擎友好的结果
IIS URL Rewrite允许Web管理员轻松地将响应HTML中由Web应用程序生成的URL替换为更友好的用户界面和搜索引擎友好的等效项。可以在逆向代理背后的Web应用程序生成的HTML标记中修改链接。使出站响应内容和头部重写变得更容易，出站重写规则可与HTTP请求和响应头以及IIS服务器变量一起工作。
3、与现有IIS功能无缝集成，可改善管理，性能和故障排除
IIS URL Rewrite与IIS管理器紧密集成以实现更好的管理。此外，它还支持用户模式和内核模式缓存，以提高性能。IIS URL Rewrite还支持失败请求跟踪以增强应用程序逻辑执行的故障诊断。
1、提高安全性，屏蔽内部的url结构.
2、美化URL
3、更有利于搜索引擎的收入，通过对URL的一些优化，可以使搜索引擎更好的识别与收录网站的信息.
在IIS5和IIS6时代，我们使用URL REWRITING可实现URL重写，使得WEB程序实现伪静态，但默认情况下只能实现.ASPX的伪静态，如果要实现伪静态*.HTML的页面，需要将ISAPI里面的*.HTML应用程序映射改为.NET的ISAPI。但在IIS 7时代，这一切已经变得非常简单了，您在WEB.CONFIG中就可以管理这一切了。
控制URL重写规则的响应缓存能力
URL Rewrite v7.1.1909从可缓存的服务器变量集中移除了`HTTP_HOST`。这意味着在条件中引用`HTTP_HOST`或者其操作是重写/重定向并将`HTTP_HOST`设置为其操作的一部分的任何URL重写规则不再是内核可缓存的。此修复的目的是防止由于缓存导致客户陷入重写循环，因为URL Rewrite无法检测循环。但是，此更新消除了客户如果知道他们没有任何重定向循环，则允许他们的响应成为内核可缓存的能力。
引入一个responseCacheDirective
通过引入URL重写规则可明确标记为可缓存
规则元素 - responseCacheDirective上的新指令。
responseCacheDirective接受四个可能的值：
1.始终：响应始终可缓存。
2.从不：响应永远不可缓存
3. NotIfRuleMatched：如果规则匹配，则响应不可缓存。
4.自动(默认)：URL重写根据规则中使用的服务器变量确定规则的缓存友好性。
进入重定向循环的风险尚未得到缓解，因此设置responseCacheDirective时应始终仅在您可以验证没有重定向循环时使用。
当您使用不同的responseCacheDirective定义多个规则时会发生什么?
URL重写会尝试将传入的URL顺序匹配到一组规则。每个规则有三种可能的结果，因为它适用于传入的URL：不匹配，URL匹配和规则匹配，以增加匹配度。除匹配URL之外，符合规则条件时匹配的规则与匹配的URL不同。
每个规则都会重新考虑响应的可缓存性，初始状态为中性状态，URL重写不会以任何方式指示内核缓存。如果当前状态更改为不可缓存，则不会考虑进一步的规则来确定缓存功能。换句话说，执行的所有规则中的单个规则足以使整个响应无法缓存。这使得在发生“规则匹配”时处理停止的情况下，规则的排序很重要。考虑至少有一个规则评估为“URL匹配”，并且该规则设置为“从不”或“自动”且缓存不友好的服务器的情况。如果此规则在规则匹配之前顺序执行，则会导致内核缓存被禁用。另一方面，如果规则被跳过，因为它在“规则匹配”规则之后，它对缓存能力没有影响。
对于对缓存能力有影响的规则，该规则至少应该是“URL匹配”。如果针对给定规则的responseCacheDirective选择了“NotIfRuleMatched”，则整个规则与URL和条件匹配时，该响应的内核缓存将被禁用。请记住，“NotIfRuleMatched”不考虑缓存不友好的服务器变量。对于Never和Always而言，这也是如此，只有当存在缓存不友好的服务器变量导致禁用内核缓存时，Auto才会成为唯一的值。
保留原始网址编码
在v7.1.1980之前的URL Rewrite版本中，当您尝试使用UNENCODED_URL时，URL Rewrite将对其进行编码，如果原始URL已被编码，则可能会导致双重编码。这违反了RFC3986的第2.4节，其中规定“实施必须不是百分比 - 对同一个字符串进行多次编码或解码，因为对已经解码的字符串进行解码可能导致错误地将百分比数据八位字节解释为百分比编码的开始，反之亦然，编码的字符串“。它还使得UNENCODED_URL变得不切实际，特别是在ARR的反向转发器场景中，后端服务器希望URL未经修改就被传递。
在v7.1.1980中，我们添加了一个功能标志useOriginalURLEncoding，它允许您在设置为true时关闭此不符合的URL编码。默认行为将保持不变(useOriginalURLEncoding默认为true)。
为了进一步解释这一点，我们来看看下面的例子，传入的URL是https://contoso.com/ab%2fde/。在这个例子中，从IIS.SYS接收的URL的熟化表示是一旦解码/ ab / de /的URL。
当保留原始URL编码(useOriginalURLEncoding == true)时，UNENCODED_URL服务器变量通过对传入URL进行编码来计算，这会导致双重编码ab%252f。关闭不符合规定的行为(useOriginalURLEncoding = false)后，UNENCODED_URL现在就是我