可能已经没有人会使用上一篇文章中的方法进行URL Rewrite了,因为提供URL Rewrite的组件早已铺天盖地了。
ASP.NET级别的URL Rewrite组件的原理很简单,其实只是监听BeginRequest事件,并且根据配置来决定目标URL。在我之前接触过的项目中,发现使用URLRewriter作为URL Rewrite组件的频率非常高,我想可能是因为那是微软提供的东西吧。
如果要使用URLRewriter,首先自然就是在web.config中配置一个HttpModule:
<httpModules> <add name="ModuleRewriter" type="URLRewriter.ModuleRewriter, URLRewriter" /> </httpModules>
然后就是进行配置了(注:强烈建议使用configPath属性将配置提取成额外的文件,便于管理):
<configSections> <section name="RewriterConfig" type="URLRewriter.Config.RewriterConfigSerializerSectionHandler, URLRewriter" /> </configSections> <RewriterConfig> <Rules> <RewriterRule> <LookFor>~/tag/([\w]+)/</LookFor> <SendTo>~/Tags.aspx?Tag=$1</SendTo> </RewriterRule> </Rules> </RewriterConfig>
正则表达式是一个非常了不得的东西,能匹配,能捕获。在上面的例子中,我们把符合LookFor条件的“/tag/xxx”重新定位到Tags.aspx页面上,并且将xxx作为Tag这个QueryString项的值,这样就能够在代码中通过HttpContext.Request.QueryString["Tag"]来获得该值了。
URLRewriter的功能对于大多数应用来说已经足够了,但是我总是不喜欢。但如果非要问我不喜欢的原因,我也难说出个子丑寅卯来。可能仅仅是这个配置方式的问题吧。在使用URL Rewriter时,配置段往往会非常长,每个配置项需要从<RewriterRule>到</RewriterRule>共4行代码,一个规模不大的项目都很容易出现上百行的配置。“这也太XML了”,我想,为什么不用XML Attribute呢?这样每个配置项就能缩短为1行了——不过,这是题外话。
以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索url
, urlrewriter
, 配置
, 组件
, rewrite
, url rewrite
, 一个
url组件
rewrite url重写、urlrewrite 重写、mvc url重写 rewrite、iis urlrewrite 重写、urlrewrite 重定向,以便于您获取更多的相关知识。