仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 611|回复: 7
打印 上一主题 下一主题

[学习教程] ASP.NET网页设计在ASP.NET中完成Url Rewriting

[复制链接]
小女巫 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:44:55 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
有专家说:java不是跨平台,java就是平台,这很好的定义了java的特点。有了java,你只需要等待java平台在新平台上移植。这还不错吧!只是,java不是一个平台,而是多个平台。你需要在这个java平台移植到另一个java平台。asp.net  提要

  剖析怎样利用微软供应的ASP.NET来对静态发生的URL地点举行网址重写。网址重写是完成一种截取网址哀求并将其举行处置后从头指向到一个指定的网址的历程。作者自己在对各类完成网址重写的手艺举行研讨和切磋后得出的履历和办法,但愿能对您有所匡助。

  内容简介

  略微花点工夫看一看你做的网站外头的URL地点,你看到相似如许的地点吗http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary?大概你会出于某种目标把大批的页面文件从一个目次乃至一个网站转移到其他中央,而很多会见者出于团体乐趣大概研讨目标之前就已将原有网址保藏了起来,假如这时候他从保藏夹翻开该页面的时分发明这已是坏链了。本文旨在先容怎样利用网址重写将那些“丢脸”的网址转换成对照有实践意义的网址,使其便于影象。比方将http://yoursite.com/info/dispEmployeeInfo.aspx?EmpID=459-099&type=summary转换成以下地点:http://yoursite.com/dispEmployeeInfo/459-099/summary.html。我们乃至发明网址重写手艺能够办理使人头疼的404毛病,大概说它能够创立一个智能化的404毛病办理计划。

  如上所述,网址重写是完成一种截取网址哀求并将其举行处置后从头指向到一个指定的网址的历程。在网址重写实行的时代,响应处置程序处置被哀求的网址,从中提掏出相干的值,然后从头指向一个新的指定地点。比方:因为一次网站目次调剂,原本的/people/子目次下的一切网页全体挪动到/info/employees/目次,原会见者从保藏夹大概其他甚么中央点击链接收回会见/people/目次下的文件的哀求时,你一定但愿他仍是能经由过程原有地点看到和本来不异的页面,但实践上看到的倒是网址重写指向的新目次下的响应文件。

  在老版本ASP中,利用网址重写手艺的路子很少,要末写一个ISAPI过滤器,要末购置第三方厂商供应的网址重写组件,但是在微软供应的ASP.NET下你能够经由过程多种办法很复杂地开辟出本人的网址重写软件,以满意本人各类分歧的必要。本文将和你一同会商这门针对ASP.NET开辟职员的完成网址重写的手艺,然后举一些网址重写实践使用的例子。在我们深切切磋网址重写手艺的细节之前,我们先看一下一样平常利用网址重写手艺完成的场景。

  网址重写的一样平常用处

  创立一个数据操纵的ASP.NET程序最多见的就是一个aspx页面前面带上一些查询参数汇合。比方在计划一个电子商务网站的时分,假定你计划了一项功效同意用户扫瞄待售的商品,为了加倍便利操纵,你计划了一个页面displayCategory.aspx将商品依照给定的分类显现,那末该分类下的商品显现页面上应当在页面文件对应网址前面加上了一个商品分类的查询参数,比方用户要查询待售的“粉饰品”,在数据库中一切的粉饰品数据对应的分类编号CategoryID的值为5,那末用户会会见以下网址:http://yoursite.com/displayCategory.aspx?CategoryID=5。

  创立一个包括相似如许网址的网站终极有两种了局,起首从终极用户的角度来察看,http://yoursite.com/displayCategory.aspx?CategoryID=5这个网址有些混乱,可行性剖析专家JakobNeilson(主页:http://useit.com/)倡议选择网址显现体例时分思索以下请求(参考网址:http://www.useit.com/alertbox/990321.html):

  ・是不是冗长

  ・是不是易于输出

  ・是不是将站点布局抽象化

  ・是不是具有潜伏性,也就是让用户经由过程一个假造的看似成心义的导航地点会见指向该地点

  我想还应当在上述列表中再增添一条:是不是便于影象。http://yoursite.com/displayCategory.aspx?CategoryID=5这个地点没有一个中央切合Neilson尺度的任何一条,也方便于影象。固然,关于有履历的收集开辟专家来讲,他们很熟习这类键值对组成的查询参数布局系统,但是关于一般用户来讲输出这些带有参数的网址其实是太贫苦了。

  一种较好的办法就是利用一种对照直不雅且简单影象的体例来将网址暗示为:http://yoursite.com/products/Widgets乍一看很简单就会揣度这个网址所对应的内容极有大概会是显现粉饰品(Widgets)信息,这个网址就变得加倍简单影象和传布!然后我告知我的同事:“请检察这个网址:http://yoursite.com/products/widgets”不必我说第二遍,她大概一次就把地点敲到扫瞄器上了(你也能够在亚马逊(Amazon.com)的网站上如许实验一下)。很快就扫瞄器上就列出了粉饰品(Widgets)的内容。这里“潜伏性”暗示:用户能够自行变动网址的开头,比方输出:http://yoursite.com/products就可以看到全体分类相干的商品列表大概列出一切相干商品分类目次列表。

  注:用上述复杂的变动网址内容的办法来构想一下现在的对照盛行的Blog网站天生的网址。比方:要查询2004年1月28日所发的帖子,只需输出http://someblog.com/2004/01/28便可,假如将网址扩充为http://someblog.com/2004/01则显现2004年1月份的帖子,一样将月份扩充失落失掉http://someblog.com/2004则显现出2004年整年所发的帖子。

  网址重写手艺除用于将庞大的网址复杂化以外,它还能用于处置因网站目次调剂大概其他缘故原由招致发生大批的有效链接和过时书签。

  当一个Web哀求传送到IIS会产生甚么?

  在切磋怎样完成网址重写这项手艺之前,很有需要懂得一下IIS是处置所吸收的Web哀求的机制。当一个Web哀求抵达IISWeb服务器时,IIS会依据所哀求的文件后缀名来决意怎样处置该哀求,IIS能够处置诸如HTML页面、图片、静态内容,大概将哀求转发给ISAPI使用程序,由该ISAPI使用程序处置后天生HTML静态内容前往给IIS,最初由IIS将哀求了局发送回给客户端。(一个ISAPI使用程序就是一套编译好能随时在背景运转的类库,它的义务就是依据哀求天生相干的内容。)

  比方:假如IIS吸收到一个对Info.asp的哀求,它会将该哀求转交给asp.dll来处置,该ISAPI使用程序修改并实行所哀求的ASP页面,然后把天生的HTML代码前往给IIS,IIS最初把内容发送回哀求客户端。关于ASP.NET页面,IIS则将哀求转交给名为aspnet_isapi.dll的ISAPI使用程序来处置,该ISAPI使用程序挪用托管的ASP.NET事情历程来处置该哀求,并将天生的HTML代码前往给哀求客户端。

  你能够自界说IIS,将某一类扩大名映照到指定的ISAPI使用程序,图一显现了IIS办理工具中的使用程序设置对话框。


图一.已设置的文件扩大名映照

  关于对IIS怎样办理所吸收的哀求的具体切磋有些超越本文内容,,主要的是要懂得ASP.NET引擎只卖力处置对扩大名已被准确设置映照到aspnet_isapi.dll的收集哀求。
  用ISAPI过滤器来剖析哀求

  除将哀求的文件扩大名映照到响应的ISAPI使用程序外,IIS还实行一些其他事情。比方IIS还自动对收回哀求的客户端用户举行受权,并判别已受权用户是不是对其哀求的文件具有会见权限,在一个哀求历程的全体性命期内,IIS的处置履历了几个阶段,在每个阶段IIS都天生一个事务,而该事务能够被ISAPI过滤器及时操控的。

  好像ISAPI使用程序一样,ISAPI过滤器也是一块块安装在Web服务器上的非托管代码。ISAPI使用程序用于对所吸收的特定文件范例做出呼应,而ISAPI过滤器含有对IIS天生的事务做出呼应的代码(containCode),乃至能够编纂收支的数据。ISAPI也含有浩瀚使用程序,包含:

  ・权限把持与受权(AuthenticationandAuthorization)

  ・日记纪录与监督(LoggingandMonitoring)

  ・HTTP内容紧缩(HTTPCompression)

  ・网址重写(URLRewriting)

  本文所切磋的用ASP.NET完成的网址重写手艺就是基于ISAPI过滤器用于网址重写的手艺内容,但是我们仍旧要会商一下事实是利用ISAPI过滤器仍是利用ASP.NET使用程序供应的手艺来完成网址重写手艺。

  当一个哀求传进ASP.NET引擎的时分会产生甚么?

  ASP.NET问世之前,在IISWeb服务器上的网址重写功效必要经由过程ISAPI过滤器来完成,自从这个家伙问世后我们就可以经由过程ASP.NET来完成URL重写了,由于ASP.NET的注释引擎与IIS有极年夜的类似的地方,发生这些类似性次要是由于ASP.NET:

  ・在处置吸收的哀求的性命期内也会发生事务;

  ・同意恣意数目的HttpModule操控发生的事务,这与IIS中的ISAPI过滤器相似;

  ・将哀求的资本托付给HttpHandler处置,这与IIS中的ISAPI使用程序相似。

  和IIS一样,在一个哀求的全部性命期内,ASP.NET对该哀求的处置形态收回的形态改动旌旗灯号激发响应的事务。比方:BeginRequest事务在ASP.NET入手下手呼应客户端哀求之始激发;AuthenticateRequest事务在ASP.NET建立用户身份后激发,固然另有诸如AuthorizeRequestResolveRequestCacheEndRequest等别的良多事务,这些都是System.Web.HttpApplication类下的事务,更多信息请参考手艺文档中的类HttpApplication提要。

  如上所述,能够创立ISAPI过滤器并用于响应IIS激发的事务,同理,ASP.NET也供应了HttpModule用于呼应ASP.NET引擎激发的事务,一个ASP.NET使用程序经由过程设置能够具有多个HttpModule。ASP.NET引擎每处置一个哀求,便初始化一个响应设置好的HttpModule,并同意它针对哀求处置时代激发的事务天生响应的事务托付。现实上ASP.NET引擎处置每个哀求挪用大批的事务托付。FormsAuthenticationModule就是浩瀚内嵌HttpModule中的一个,它起首反省是不是利用表单受权,假如是的话,它将反省用户是不是已受权,假如没有受权则主动把用户重定向到指定的登录页面。(即:在asp.net中能够间接纪录并辨别用户登录受权的成绩了!)

  回想在IIS中,一项哀求最初被转交给一个ISAPI使用程序处置,该使用程序针对每项哀求举行处置并前往响应的数据。比方,客户端收回一个会见典范ASP页面的哀求,IIS将该哀求转交给asp.dll程序处置,asp.dll针对该哀求实行asp页面内容,并前往HTML编码。ASP.NET也利用了相似的伎俩,ASP.NET引擎在将这些HttpModule初始化后,判别并决意挪用响应的HttpModule来处置该哀求。(问:怎样程序操纵httpModule)

  一切经由过程ASP.NET引擎剖析的哀求终极被送交一个HttpHandler大概HttpHandlerFactory(一个HttpHandler只是复杂地前往一个用于处置该哀求的HttpHandler的实例。)终极的托付出现并呼应所哀求的HTML编码,并发送回IIS,IIS则将HTML前往给哀求客户端。
ASP.NET包括很多HttpHandler,比方,PageHandlerFactory是用于出现ASP.NET页面内容,WebServiceHandlerFactory用于出现ASP.NETWeb服务的SOAP数据包,TraceHandler用于将ASP.NET哀求资本的HTML标志写进trace.axd。

  图二刻画了一个针对ASP.NET资本的哀求所经由的处置流程。起首,IIS吸收到该哀求并将其转交给aspnet_isapi.dll。其次,ASP.NET引擎将一些HttpModule初始化。最初,终极的HttpHandler被挪用,天生响应的标志言语,并将其前往给IIS,终极前往到哀求客户端。


图二.IIS和ASP.NET对哀求的处置历程

  创立并注册自界说HttpModule和HttpHandler

  创立自界说HttpModule的事情绝对较复杂,它包含一个完成以后接口的托管类,HttpModule必需完成System.Web.IHttpModule接口,一样HttpHandlerHttpHandlerFactory必需分离完成System.Web.IHttpHandler接口和System.Web.IhttpHandlerFactory接口。有关创立HttpHandlerHttpModule的细节已超越本书局限。

  一旦HttpModuleHttpHandler被创立后,必需向Web使用程序注册。假如要向全部Web服务器HttpModuleHttpHandler只需复杂的写进machine.config文件;假如是由指定的Web使用程序挪用则需在该程序的web.config设置文件中增加几行XML标志。

  比方,要向指定的Web使用程序注册HttpModuleHttpHandler,只需向该Web应程序的web.config设置文件中configurationSystem.Web节中增加以下几行:



<HttpModules>
<addtype="type"name="name"/>
</HttpModules>

  个中type属性为HttpModule的标识号和类库称号,name属性则为该模块取一个较为友爱的称号便利在Global.asax挪用。
HttpHandlerHttpHandlerFactory则是在web.config文件中configurationSystem.Web节中增加<httpHandler>标志,比方:

<httpHandlers>
<addverb="verb"path="path"type="type"/>
</HttpModules>

  回想上文,ASP.NET对每个吸收到的哀求指派响应的HttpHandler来处置并出现响应内容,该指派决意于所吸收哀求的verb和path的内容,verb为HTTP哀求的范例:GET大概POST,path则为哀求的文件的路径和文件名。假如我们盘算用一个HttpHandler来处置一切GET范例和POST范例的而且文件扩大名为.scott的内容,能够在web.config响应设置节中到场以下标志:

<httpHandlers>
<addvarb="*"path=".scott"type="type"/>
</httpHandlers>

  个中type是我们界说的HttpHandler的范例。

  注重:在注册HttpHandler的时分必需注重HttpHandler所利用的文件扩大名必需已在IIS中做指向ASP.NET引擎的映照,在下面.scott扩大名的例子中,假如我们所利用的.scott扩大名假如没有在IIS中做指向ASP.NET引擎的映照的话,假定对foo.scott文件收回哀求,该哀求将招致IIS将foo.scott文件内容间接出现给客户端,为了可以让HttpHandler处置该哀求,必需将.scott扩大名在IIS中做指向ASP.NET引擎的映照,以后IIS才干准确地将.scott的哀求转交给响应的HttpHandler
  完成网址重写

  网址重写手艺不仅能够在IISWeb服务器一级经由过程ISAPI过滤器完成,并且还能够在ASP.NET一级经由过程HttpModule大概HttpHandler完成。本文次要存眷在ASP.NET一级完成网址重写手艺,以是此时不用存眷在ISAPI使用程序中完成网址重写的手艺细节,并且有良多第三方厂商供应的ISAPI过滤器。

  构建网址重写引擎

  在ASP.NET中完成网址重写很复杂,只需挪用System.Web.HttpContext类的RewritePath()办法便可。HttpContext类中包括有关于特定HTTP哀求的HTTP标准信息。ASP.NET引擎每吸收到一个特定哀求后便针对该哀求创立一个特定的实例,这个类包括一些属性诸如:RequestResponse属性,分离供应对哀求和呼应的会见;ApplicationSession属性供应对Application变量和Session变量的会见;User属性供应对已受权用户信息的会见。

  在微软.NETFramework1.0版本中,RewritePath()办法吸收一个新路径的复杂字符串,在其外部HttpContext类的RewritePath(string)办法内涵地更新Request工具的路径和查询参数。除RewritePath(string)办法以外,.NETFramework1.1版还供应了别的一些重载版本,个中一个重载版本吸收三个输出字符串参数,这类瓜代的重载情势不单单只是设置Request工具的路径和查询参数这些属性,而是设置更深层的成员变量,这些成员变量用于为PhysicalPathPathInfoFilePath属性盘算Request工具值。

  为了完成ASP.NET中的网址重写,我们必要创立一个HttpHandlerHttpModule用于:

  ・依据哀求的路径决意所必要重写的路径;

  ・重写路径,假如必要的话能够挪用RewritePath办法;

  之前文所构建的谁人站点为例,能够经由过程/info/employee.aspx?empID=EmployeeID来会见每个雇员的信息。为了使这个网址加倍地具有“潜伏性”,我们大概会利用加倍简单了解的会见体例如:/people/雇员名.aspx。这里就有了一个网址重写的案例:当吸收到对/people/ScottMitchell.aspx的哀求的时分,我们就得利用网址重写使得对该页面的哀求被重写指向到先前利用的/info/employee?EmpID=1001地点。

  利用HttpModule来挪用网址重写

  在ASP.NET一级来实行网址重写,既可使用HttpHandler,也能够利用HttpModule。当利用HttpModule的时分,必需决意假如该网址必要被重写的话,事实应当在全部哀求的性命周期时代的那一个点来利用。乍一看着有些果断,可是这个决意以严重并且奇妙的体例影响到你的使用程序。之以是作出对网址重写点的选择是由于内嵌的ASP.NETHttpModule利用Request工具的属性值来完成本人的事情(回想一下重写路径对Request工具的属性值的改动),这些内嵌HttpModule和响应事务的亲切干系枚举以下:

HttpModule事务简介FormsAuthenticationModuleAuthenticateRequest判别用户是不是已经由过程表单受权体例猎取受权,假如没有的话则将用户重定向到指定的登录页面FileAuthorizationModuleAuthorizeRequest当利用Windows受权体例的时分,该HttpModule判别并断定该MicrosoftWindows帐户是不是对其哀求的资本具有充足的权限UrlAuthorizationModuleAuthorizeRequest反省并确认哀求者是不是对所会见的网址具有权限。该Url受权能够在web.config文件的<authorization>和<location>元素中设置
  回忆一下BeginRequest事务在AuthenticateRequest事务之前激发,而AuthenticateRequest事务又在AuthorizeRequest事务之前激发。

  完成网址重写的一个较为平安的场所就是把它放在在BeginRequest事务中实行,这意味着假如要实行网址重写的话,在浩瀚内嵌HttpModule运转的时分他已完成了。这类路子的终极用处极尽描摹地表现在表单考证上。当用户会见受限资本的时分,假如之前利用了表单考证,他会主动被重定向到指定的登录页面,在乐成登录以后,用户被重定向回先前试图会见的受限定页面。

  假如把网址重写放在BeginRequest事务大概AuthenticateRequest事务中,在登录页面上实行提交后,该页面会将用户重定向到网址重写指定的页面。假定当用户在扫瞄器上敲进/people/ScottMitchell.aspx地点,该地点是要被重定向到/info/employee.aspx?EmpID=1001的,假如该Web使用程序设定利用表单考证,当用户入手下手会见/people/ScottMitchell.aspx的时分,该网址将重写指向/info/employee.aspx?EmpID=1001,接着ForumAuthenticationModule启动,假如必要的话将用户重定向到登录页面,用户登录后重定向到的页面将是/info/employee.aspx?EmpID=1001,这也是自从FormAuthenticationModule启动运转时所收回哀求的页面。
同上相似,当把网址重写放在BeginRequest事务大概AuthenticateRequest事务中运转的时分,UrlAuthenticationModule也发明了网址重写指向的网址,这意味着假如在该使用程序的web.config文件中<location>节为特定的网址设置特定的受权地点的话,你得援用重写所指向的网址。

  为懂得决这个奇妙的成绩,一个大概就是把网址重写放在AuthorizeRequest事务中运转,可是在利用这类办法办理URL受权和表单受权的非常时又引进了一个新的缺点:文件受权会生效。当利用Windows考证的时分,FileAuthorizationModule反省并考证已经由过程考证的用户是不是具有充足的权限会见特定的ASP.NET页面。

  假定有一群用户并没有Windows级其余会见权限会见C:inetpubwwwrootinfoemployee.aspx,当这些用户试图会见/info/employee.aspx?EmpID=1001的时分,他们会失掉未受权的毛病,假如我们把网址重写放到AuthenticateRequest事务中运转,当FileAuthorizationModule考证该平安性设置的时分,他仍任工资被哀求的文件是/people/ScottMitchell.aspx,而这时候该网址已被重写了,因而FileAuthorizationModule会间接放行,让用户看到了网址重写指向的内容:/info/employee.aspx?Empid=1001。

  那末甚么时分在HttpModule挪用网址重写符合呢?他决意于所利用的考证体例,固然假如不利用考证体例的话,那末不管是在BeginRequest事务、AuthenticateRequest事务仍是AuthorizeRequest事务中挪用网址重写没有多年夜区分,假如利用表单考证体例而且不利用Windows考证体例的话,把网址重写放进AuthorizeRequest事务托付中挪用既可,假如利用Windows考证体例的话,把这项功效放进BeginRequest事务大概AuthenticateRequest事务挪用就好了。
  利用HttpHandler来挪用网址重写

  除下面所述办法外,网址重写也能够放进HttpHandler大概HttpHandlerFactory中挪用。HttpHandler是一个卖力针对特定哀求天生响应内容的类,而HttpHandlerFactory前往一个HTTP的实例,该实例针对特定哀求天生响应内容。

  本节将着眼于为这些ASP.NET页面创立一个网址重写的HttpHandlerFactory。创立HttpHandlerFactory必需完成IHTTPHandlerFactory接口,它包含一个GetHandler()办法。ASP.NET引擎在初始化这些HttpModule后做出决意针对该哀求挪用响应的HttpHandler大概HttpHandlerFactory,在挪用HttpHandlerFactory的时分,针对该Web哀求和伴同的其他信息的HttpContext中经由的的HttpHandlerFactoryGetHandler()办法将被ASP.NET引擎挪用,HttpHandlerFactory必需前往一个能托付该哀求的工具,而且该工具要能完成IHttpHandler接口。

  要经由过程一个HttpHandler来挪用网址重写,能够先创立一个HttpHandlerFactory,它的GetHandler()办法反省所哀求的网址并决意是不是必要挪用网址重写。假如要挪用网址重写的话则挪用前文所述的已经由过程反省的HttpContext工具的RewritePath()办法。最初该HttpHandlerFactory前往一个由类System.Web.UI.PageParserGetCompiledInstance()办法前往的HttpHandler。(这与内嵌于ASP.NET页面的HttpHandlerFactoryPageHandlerFactory)的事情道理不异。)

  在一切HttpModule被初始化后,HttpHandlerFactory就入手下手被实例化。把网址重写放在这些事务场合的最初一个外头挪用的时分,也会碰着不异的成绩:文件受权将会生效。假如非要依附于Windows考证和文件考证的时分,你大概得利用HttpModule来挪用网址重写了。
下一章我们着眼于怎样构建一个可重用的网址重写引擎,利用下文所提的这些示例均以实在案例作为参照,在作者主页上供应下载。先用用一个复杂的网址重写的例子来切磋怎样完成网址重写,紧接着将使用网址重写引擎中正则表达式的壮大处置才能来展现真正“潜伏”的网址重写手艺!

  利用网址重写引擎完成复杂的网址重写

  为了便于在Web使用程序中完成网址重写,我构建了一个网址重写引擎,该引擎供应以下功效:

  ・能够在web.config文件中为页面开辟者界说其所利用的网址重写引擎的划定规矩;

  ・经由过程利用正则表达式来使所制订的网址重写划定规矩具有加倍壮大的重写才能;

  ・可以经由过程复杂设置便可在HttpModuleHttpHandler中利用网址重写。

  本节只切磋经由过程HttpModule来完成网址重写,要懂得怎样经由过程HttpHandler来完成网址重写请下载本文供应的代码。

  1.设置网址重写引擎的设置信息

  我们来切磋一下在web.config中网址重写划定规矩的设置节。起首必需在web.config文件中指出是不是必要在HttpHandler大概HttpModule中挪用网址重写,在web.config中,下文已包括了两个已被正文失落的设置节:

<!--
<HttpModules>
<addtype="URLRewriter.ModuleRewriter,URLRewriter"name="ModuleRewriter"/>
</HttpModules>
-->

<!--
<httpHandlers>
<addverb="*"path="*.aspx"type="URLRewriter.RewriterFactoryHandler,URLRewriter"/>
</httpHandlers>
-->

  被正文失落的<HttpModules>为设置利用HttpModule挪用网址重写;正文失落的<httpHandler>为设置利用HttpHandler挪用网址重写。
不管设置利用<HttpModules>仍是<httpHandlers>挪用网址重写,除此以外还须设置网址重写划定规矩,一条重写划定规矩包含两项字符串:哀求URL中的查找形式和针对该形式的婚配乐成后的交换字符串。该信息在web.config文件顶用以下标签形貌:

<RewriterConfig>
<Rules>
<RewriterRule>
<LookFor>patterntolookfor</LookFor>
<SendTo>Stringtoreplacepatternwith</SendTo>
</RewriterRule>
<RewriterRule>
<LookFor>patterntolookfor</LookFor>
<SendTo>Stringtoreplacepatternwith</SendTo>
</RewriterRule>

</Rules>
</RewriterConfig>

  每条划定规矩都用一个<RewriterRule>元素暗示,以<LookFor>节暗示查询形式,当查询形式发明婚配字符串时便用<SendTo>节暗示的字符串举行交换。这些划定规矩从上到下举行查询婚配,假如找到一个婚配则按此划定规矩实行网址重写,而且中断查找。

  设置<LookFor>节要利用正则表达式来举行字符串婚配和交换。(在此我们举一个例子来讲明怎样利用正则表达式来对字符串举行婚配和交换。)既然该查找形式是一个正则表达式,那末要注重避开对正则表达式保存字符串的间接利用。(正则表达式的保存字符串包含有:.,?,^,$,等等,能够经由过程在后面加上一个反斜线来援用这些保存字符,比方.暗示援用一个句点)

  2.利用HttpModule来实行网址重写

  创立一个HttpModule很复杂,只需创立一个完成IHttpModule接口的类,该IHttpModule接口界说了两个办法:

  ・Init(HttpApplication),该办法在HttpModule初始化时激发,经由过程该办法为HttpApplication事务挪用响应的事务托付;

  ・Dispose(),当响应哀求处置停止并发送回IIS挪用此办法,经由过程此办法实行终极一切的清算和接纳程序。

  为了加倍便利地为网址重写创立HttpModule,从一入手下手我就创立一个笼统的基类(BaseModuleRewriter),该类完成了IHttpModule接口。在Init(HttpApplication)事务中,它经由过程BaseModuleRewriter_AuthorizeRequest办法激发了HttpApplicationAuthorizeRequest事务,该BaseModuleRewriter_AuthorizeRequest办法经由过程该类的Rewrite()办法重写传进参数HttpApplication工具的外部哀求假造路径(Path)。在BaseModuleRewriter工具中,该Rewrite()办法是笼统的,而且没有实践内容,但在承继自该类的工具中必需重载Rewrite()办法并为该办法供应实践内容。

  经由过程对该基类的承继,一切必要做的事情就是创立一个承继自BaseModuleRewriter的类,重载Rewrite()办法并在该办法中增加网址重写逻辑代码。下文列出BaseModuleRewriter代码:

publicabstractclassBaseModuleRewriter:IHttpModule
{
publicvirtualvoidInit(HttpApplicationapp){
//WARNING!ThisdoesnotworkwithWindowsauthentication!
//IfyouareusingWindowsauthentication,
//changetoapp.BeginRequest
app.AuthorizeRequest+=newEventHandler(this.BaseModuleRewriter_AuthorizeRequest);
}

publicvirtualvoidDispose(){}

protectedvirtualvoidBaseModuleRewriter_AuthorizeRequest(objectsender,EventArgse){
HttpApplicationapp=(HttpApplication)sender;
Rewrite(app.Request.Path,app);
}

protectedabstractvoidRewrite(stringrequestedPath,HttpApplicationapp);
}

  注重:该BaseModuleRewriter类将网址重写放在AuthorizeRequest事务中挪用,假如要利用Windows考证并利用文件考证形式时请修正代码将网址受权放在BeginRequest大概AuthenticateRequest事务中。

  ModuleRewriter承继自BaseModuleRewriter,并真正意义地完成了网址重写的操纵,该类仅包括一个重载了的办法Rewrite(),其内容以下文所示:

protectedoverridevoidRewrite(stringrequestedPath,System.Web.HttpApplicationapp)
{
//gettheconfigurationrules
RewriterRuleCollectionrules=RewriterConfiguration.GetConfig().Rules;
//iteratethrougheachrule
for(inti=0;i<rules.Count;i++)
{
//getthepatterntolookfor,and
//ResolvetheUrl(convert~intotheappropriatedirectory)
stringlookFor="^"+
RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,rules.LookFor)+"$";
//Createaregex(notethatIgnoreCaseisset)
Regexre=newRegex(lookFor,RegexOptions.IgnoreCase);
//Seeifamatchisfound
if(re.IsMatch(requestedPath))
{
//matchfound-doanyreplacementneeded
stringsendToUrl=RewriterUtils.ResolveUrl(app.Context.Request.ApplicationPath,re.Replace(requestedPath,rules.SendTo));
//RewritetheURL
RewriterUtils.RewriteUrl(app.Context,sendToUrl);
break;//exittheforloop
}
}
}

  该Rewriter()办法以猎取web.config文件中的网址重写划定规矩的设置为肇端,它经由过程轮回会见各条网址重写划定规矩,每次均猎取以后划定规矩中的LookFor属性,用正则表达式考证并判别是不是查找是不是对以后哀求的网址是不是有婚配。

  假如发明一条婚配,将用以后划定规矩的SendTo值对哀求的路径实行一个正则表达式交换,交换后的地点经由过程参数的情势传给RewriterUtils.RewriteUrl()办法,RewriterUtils是一个匡助类,它供应一对HttpModuleHttpHandler都可使用的静态办法,RewriterUrl()办法只是复杂地挪用了HttpContext工具的RewritePath()办法。

  注重:你已注重到了当实行正则表达式婚配和交换的时分挪用了一个RewriterUtils.ResolveUrl()办法。该匡助办法复杂地交换了使用程序路径中“~”的一切实例。

  我们已切磋了次要的部分,可是另有别的一些组件诸如将web.config文件中XML格局化了的网址重写划定规矩反序列化至一个工具的类界说、经由过程HttpHandlerFactory完成网址重写的类界说等。本文最初三节将经由过程一些实在案例来切磋网址重写的手艺。

  3.用网址重写引擎完成复杂的网址重写

  为了更好地树模网址重写引擎的运转,我们来创建一个ASP.NETWeb使用程序来完成复杂的网址重写引擎。假定我们为一家在线发卖各种商品的公司服务,这些产物分别为以下种别:

  分类编号(CategoryID)分类称号(CategoryName)
   1         饮料(Beverages)
   2         调味品(Condiments)
   3         工艺品(Confections)
   4          日志本(DiaryProducts)
   ......
  
  假定已创建好一个名为ListProductsByCategoryID.aspx的ASP.NET页面文件,它经由过程查询参数猎取一个分类编号,并依据此编号猎取一切该分类下的一切商品。假如用户想扫瞄所发卖的饮料类商品能够经由过程ListProductsByCategoryID.aspx?CategoryID=1来会见,假如用户想扫瞄所发卖的日志本类商品能够经由过程ListProductsByCategoryID.aspx?CategoryID=4来会见。假定另有一个页面ListCategories.aspx,它列出一切代售商品的分类编号。

  明显这里发明了一个网址重写的案例。关于用户来讲他们所输出的地点不具有任何实践意义而且不具有任何“潜伏性”,倒不如利用网址重写引擎让用户往会见/Products/Baverage.aspx地点,体系将该地点重写到ListProductsByCategoryID.aspx?CategoryID=1。我们能够在web.config文件中来完成网址重写义务:

<RewriterConfig>
<Rules>
<!―-Rulesforproductslister-->
<RewriterRule>
<LookFor>~/Products/Baverage.aspx</LookFor>
<SendTo>~/ListProductsByCategoryID.aspx?CategoryID=1</SendTo>
</RewriterRule>
</Rules>
</RewriterConfig>

  很分明地看到,搜刮用户会见的路径是不是婚配/Products/Baverage.aspx,假如婚配的话,则将网址重写到/ListProductsByCategoryID.aspx?CategoryID=1。

  注重:你会发明<LookFor>节点中制止间接在“Baverage.aspx”中利用句点“.”是由于<LookFor>节点的值是正则表达式的婚配形式,在正则表达式中句点标记是一个特别字符,它暗示婚配任何一个字符,也就是说假如会见BaverageQaspx时也会产生婚配,为了不产生这个句点引发的婚配我们得在该句点标记后面加上一个“”,暗示援用句点标记。

  经由过程该划定规矩界说,当用户会见/Products/Baverage.aspx文件的时分,他们将看到代售的饮料类商品列表信息。为会见/Products/Baverage.aspx地点时的扫瞄器截图,注重在扫瞄器中地点栏上显现的是用户输出的/Products/Baverage.aspx地点,可是实践会见的地点倒是网址重写后的/ListProductsByCategoryID.aspx?CategoryID=1。(现实上,在服务器上基本就不存在/Products/Baverage.aspx文件!)


图三.网址重写后的对商品分类的哀求

  和/Products/Baverage.aspx相似,下一步我们增加别的分类的重写划定规矩,只需复杂地在web.config文件中<Rules>中在增加其他<RewriteRule>节便可。该演示完全的重写划定规矩汇合请参考下载文档的web.config文件中的界说。

  为了让该网址更具有“潜伏性”,假如让用户把/Products/Baverage.aspx前面Baverage.aspx一段截往,在扫瞄器中输出/Products/来扫瞄产物分类列表会更好一些。乍一看,这项义务微乎其微,只需增加一条网址重写划定规矩将/Products/映照到/ListCategories.aspx便可。但是这里有一个奇妙的地方,你必需先创立一个/Products/目次,并在内里放一个空文件Default.aspx。

  要熟悉为何这些分外的步骤是必需的,先回忆一下前文。网址重写引擎是处于ASP.NET一级的,也就是说,假如ASP.NET没有取得处置哀求的时机的话,网址重写引擎就不克不及对输出的网址哀求作出判别。别的,IIS仅在哀求文件包括响应扩大名时才将哀求转交给ASP.NET引擎。假如用户会见/Products/,IIS其实不晓得其扩大名是甚么,因而它反省该目次下的文件看是不是包括有默许首页文件名(Default.aspx,Default.htm,Default.asp,等等,这些文件名在IIS办理工具对话框中Web服务器属性对话框中的文档标签中界说。)固然,假如/Products/目次不存在的话,IIS将前往一个HTTP404毛病。

  以是我们必要创立一个/Products/目次并在该目次下分外创立一个空文件Default.aspx,IIS会反省该目次下的文件,发明有一个默许文件名Default.aspx,因而将哀求转交给ASP.NET,如许,网址重写引擎才干失效。

<RewriterRule>
<LookFor>~/Products/Default.aspx</LookFor>
<SendTo>~ListCategories.aspx</SendTo>
</RewriterRule>

  经由过程该划定规矩,用户会见/Products/Default.aspx大概会见/Products/都能够看到如图四所示的产物分类列表。


图四.在网址上增加“潜伏性”
<P>  4.处置回送数据

  假如要重写的网址上包括有服务器端WebForm并实行数据回送,当该WebForm回送数据时会表露出实在的网址,也就是说,当用户会见/Products/Baverage.aspx时,扫瞄器上地点栏显现的也是/Products/Baverage.aspx,可是实践上是会见/ListProdutsByCategoryID.aspx?CategoryID=1的内容,假如ListProductsByCategoryID.aspx页面实行了数据回送的话,用户被数据回送定向给原始的/ListProductByCategoryID.aspx?CategoryID=1页面上,而不是/Products/Baverage.aspx页面。这固然不是甚么年夜成绩,可是用户会发觉到点击一个按钮时网址产生了的变更,这大概会使人不安,由于假如出于网址平安的角度来讲,间接把实在的网址表露出来了。
之以是产生这类征象的缘故原由是当WebForm在出现之时就明白地设置其action属性为以后Request工具中文件路径的值。固然,在WebForm出现之时,从/Produts/Baverage.aspx到/ListProductsByCategoryID.aspx?CategoryID=1的网址重写就已实行终了了,这意味着Request工具所报告的是以后用户所会见的地点是/ListProductsByCategoryID.aspx?CategoryID=1。这么看来,只需让该服务器端表单在出现之时不出现action属性便可办理成绩了。(对扫瞄器来讲,假如不设置action属性的话,那末在提交的时分将利用其默许值。)

  但是不幸的是该WebForm不会同意你指定action属性,也不会同意你经由过程设置一些属性来到达禁用出现action属性的目标。得自行承继System.Web.HtmlControls.HtmlForm这个类,偏重载该类的RenderAttribute()办法,明白指出该类不出现acton属性。

  感激承继这个壮大的功效,使得我们很复杂就猎取了HtmlForm这个类下一切的功效界说,只需大批几行代码就到达所需目标,完全代码以下所示:

namespaceActionlessForm
{
publicclassForm:System.Web.UI.HtmlControls.HtmlForm
{
protectedoverridevoidRenderAttributes(System.Web.UI.HtmlTextWriterwriter)
{
writer.WriteAttribute("name",this.Name);
base.Attributes.Remove("name");

writer.WriteAttribute("method",this.Method);
base.Attributes.Remove("method");

this.Attributes.Render(writer);
base.Attributes.Remove("action");
if(base.ID!=null)
{
writer.WriteAttribute("id",this.ClientID);
}
}
}
}

  对RenderAttributes()办法重载的代码包括了原类HtmlFormRenderAttributes()办法全体的代码内容,只是复杂地往失落了设置action属性这一节。

  当创立并编译了这个类后,将其增加到援用目次便可在该ASP.NETWeb使用程序中利用。为了将原有HtmlForm类交换,只需复杂地在页面顶部增加以下代码:

<%@RegisterTagPrefix="skm"Namespace="ActionlessForm"Assembly="ActionlessForm"%>

  然后将<Formrunat=”server”>标签交换为

<skm:Formid="Form1"method="post"runat="Server">

  并将停止标志</Form>交换为

<skm:Form>

  你能够检察该文档相干下载中的ListProductsByCategoryID.aspx文件中的自界说WebForm,该下载已供应了完全的VisualStudio.NET项目文件包。

  注重:假如你盘算举行网址重写的地点不实行数据回送,则没有需要利用该自界说WebForm的类。

  创立真正“潜伏”的网址

  上一节复杂网址重写的示例展现了怎样经由过程新的网址重写划定规矩来轻松地设置网址重写引擎,本节将经由过程出众的正则表达式来展现网址重写的壮大能力。

  时下正在盛行Blog,良多人都具有一个本人的Blog。不管你是不是对Blog感应生疏,他们正在不休地更新本人的Blog页面,这些页面就像一个团体日志本一样。年夜多半Bloger只是复杂地纪录天天产生的事变,也有一些聚焦于某一主题,好比影评、球迷构造、电脑手艺等。

  Blog能够在任何地址由作者举行更新,更新次数能够是一天屡次,也能够是一周一两次。在Blog页面上只显现比来10条更新,但现实上一切的Blog软件都供应了存档纪录,访客能够浏览其汗青纪录。有了“潜伏”的网址,Blog使用程序将变得加倍壮大。假定你经由过程/2004/02/14.aspx来查询本人的Blog上的文章,你会为浏览到2004年2月14日的Blog感应惊奇吗?别的你大概为了会见2004年2月一切的Blog而将该地点扩充为/2004/02/,要会见2004年一切的Blog,你大概会试着往会见/2004/。

  在保护一个Blog的时分,假如将这类具有“潜伏性”的网址供应给用户将会更好。实践上良多Blog引擎都供应了这类网址重写的功效,如今来看看这些是怎样经由过程网址重写完成的。

  起首,我们必要一个页面可以分离依照年、月、日分离显现Blog的内容。假定如今已做好了一个页面文件ShowBlogContent.aspx,它能分离猎取年、月、日的查询参数,要检察2004年2月14日所发的帖子,我们能够会见/ShowBlogContent.aspx?year=2004&month=2&day=14,要扫瞄2004年2月的数据能够会见/ShowBlogContent.aspx?year=2004&month=2,要查询2004年一切数据能够会见/ShowBlogContent.aspx?year=2004。(鄙人载文件中供应ShowBlogContent.aspx源代码。)

  然后,当用户会见/2004/02/14.aspx时,我们必要将他会见的网址重写到/ShowBlogContent.aspx?year=2004&month=2&day=14上。这里必要制订三条网址重写划定规矩:当指定会见年代日时、当指定会见年代时和当指定会见年时。

<RewriterConfig>
<Rules>
<!--RulesforBlogContentDisplayer-->
<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>
小女巫 该用户已被删除
沙发
 楼主| 发表于 2015-1-19 22:24:18 | 只看该作者
ASP在执行的时候,是由IIS调用程序引擎,解释执行嵌在HTML中的ASP代码,最终将结果和原来的HTML一同送往客户端。
深爱那片海 该用户已被删除
板凳
发表于 2015-1-25 13:36:25 | 只看该作者
提供基于组件、事件驱动的可编程网络表单,大大简化了编程。还可以用ASP.NET建立网络服务。
灵魂腐蚀 该用户已被删除
地板
发表于 2015-2-8 12:41:16 | 只看该作者
现在的ASP.net分为两个版本:1.1和2.0Asp.net1.1用VS2003(visualstudio2003)编程。Asp.net2.0用VS2005(visualstudio2005)编程。现在一般开发用的是VS2003。
谁可相欹 该用户已被删除
5#
发表于 2015-2-25 14:21:21 | 只看该作者
平台无关性是PHP的最大优点,但是在优点的背后,还是有一些小小的缺点的。如果在PHP中不使用ODBC,而用其自带的数据库函数(这样的效率要比使用ODBC高)来连接数据库的话,使用不同的数据库,PHP的函数名不能统一。这样,使得程序的移植变得有些麻烦。不过,作为目前应用最为广泛的一种后台语言,PHP的优点还是异常明显的。
若相依 该用户已被删除
6#
发表于 2015-3-7 21:50:49 | 只看该作者
是目前ASP在UNIX/Linux上的应用可以说几乎为0)。所以平台的局限性和ASP自身的安全性限制了ASP的广泛应用。
愤怒的大鸟 该用户已被删除
7#
发表于 2015-3-15 14:58:35 | 只看该作者
市场决定一切,我个人从经历上觉得两者至少在很长时间内还是要共存下去,包括C和C++,至少从找工作就看得出来,总不可能大家都像所谓的时尚一样,追捧一门语言并应用它。
8#
发表于 2015-3-22 02:06:08 | 只看该作者
CGI程序在运行的时候,首先是客户向服务器上的CGI程序发送一个请求,服务器接收到客户的请求后,就会打开一个新的Process(进程)来执行CGI程序,处理客户的请求。CGI程序最后将执行的结果(HTML页面代码)传回给客户。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-12-23 06:04

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表