MVC有路由在手,對於重寫URL那是小菜一碟,更或者說是與身就有的「技能」,而面對.Net的WebForm就比較尷尬了。對UrlRewriter處在相對比較薄弱的環節。而你們或許會經過對IHttpModule接口的繼承來實現對URL的寫。正則表達式
可能用的很少的園友對這塊不算的上技術的技術不是很瞭解。提及重寫,那咱們說說WebForm的URL請求。當瀏覽器客戶端請求地址後,瀏覽器會開始解析域名的DNS並找到IP。經過IP + 端口的方式會找到服務器的WEB服務器。(這裏舉咱們經常使用的IIS服務)api
IIS接受到請求後。根據主機頭 + 端口 來查找對應的站點。當找到站點後,交由站點的管理。站點經過URL的後綴,好比是.aspx/.html/.css 根據《處理程序映射》來肯定該交給誰來處理這個頁面。最後由負責處理的程序進行處理並返回顯示該頁面的內容到瀏覽器客戶端。(這一段說的比較粗略,博主只記得粗略的方式,有說的不對的地方,請見諒。)瀏覽器
上面講解了請求--->處理--->顯示 的過程。服務器
先來講說咱們的需求:app
A:將原:www.xxx.com/default.aspx 映射到 www.xxx.com/users/default.aspx框架
B:將原:www.xxx.com/default.html 映射到 www.xxx.com/users/default.aspxasp.net
前面A/B 的區別在於 第一個是.aspx 第二個是.html 。同時它們的原路徑都將被映射到/users/目錄下。這裏要注意的是 並非作跳轉操做。也就是說,用戶看到的路徑,仍然是原來的路徑。
說說.html後綴的請求。因爲IIS默認的對.html的請求《處理程序映射》是交給「StaticFileModule,DefaultDocumentModule,DirectoryListingModule」進行處理的。
換句話說,它是不通過asp.net處理的。因此當來自這個路徑的請求。都是跳過asp.net管道直接返回給客戶端瀏覽器的。
而咱們要作的目的是讓.html的請求交由asp.net處理。(只有經過asp.net處理,你才能用程序介入)。還有一種辦法是使用通配符映射的方式交給asp.net 處理。即全部的後綴、目錄都交由asp.net受理。
但這種方式的請求包括css、jpg、js等全部的請求都會由asp.net處理。這種方式是會嚴重影響到性能的哦。
如今咱們能夠經過Web.Config來改變這種請求方式
IIS7+:
1 <system.webServer> 2 <modules runAllManagedModulesForAllRequests="true"> 3 <add name="QynUrlRewriter" type="FS.Utils.IHttpModule.UrlRewriter" /> 4 <remove name="Session" /> 5 <add name="HtmlSession" type="System.Web.SessionState.SessionStateModule" /> 6 </modules> 7 <handlers> 8 <add name="Rewriter" path="*" verb="*" modules="IsapiModule" scriptProcessor="C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" resourceType="Unspecified" requireAccess="None" preCondition="classicMode,runtimeVersionv4.0,bitness32" /> 9 </handlers> 10 </system.webServer>
上圖中若是使用了經典模式,則使用<handlers>節點的配置。若是啓用集成模式,則使用<modules>節點。
IIS6-:
1 <system.web> 2 <httpModules> 3 <add name="UrlRewriter" type="FS.Utils.IHttpModule.UrlRewriter"/> 4 </httpModules> 5 </system.web>
對於IIS6,還須要在IIS中進行設置通配符的映射。將 * 的受理交由:"C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll" (注意區分32位/64位)若是IIS設置爲32位啓動,則應使用32位的aspnet_isapi.dll
回顧下,上面咱們作了什麼?其實我就只作了2件事情:
在上面的配置中,你們會看到使用了:FS.Utils.IHttpModule.UrlRewriter 的類。這個類就是用來受理重寫的。當交由asp.net處理時,都會經過這個類進行判斷如何操做。
有處理程序(FS.Utils.IHttpModule.UrlRewriter)就確定有配置重寫規則的文件。這個配置文件在:~/App_Data/UrlRewriter.config 中。使用的是正則表達式。
咱們來看看UrlRewriter.config的內容吧:爲了方便你們理解,我把這段程序放到了Demo中:SVN: \Farseer\Framework\V0.2\Demo
1 <?xml version="1.0"?> 2 <RewriterConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> 3 <Rules Descript="重寫演示"> 4 <RewriterRule Descript="URL映射"> 5 <LookFor>http://localhost:(\d+)/(\d+).html</LookFor> 6 <SendTo>~/UrlRewriter.aspx?ID=$2</SendTo> 7 </RewriterRule> 8 <RewriterRule Descript="URL映射"> 9 <LookFor>http://localhost:(\d+)/(\d+)-(\d+).html</LookFor> 10 <SendTo>~/UrlRewriter.aspx?ID=$2&ID2=$3</SendTo> 11 </RewriterRule> 12 </Rules> 13 </RewriterConfig>
看下咱們的UrlRewriter.aspx文件(文件命本身隨意命名)
1 <!DOCTYPE html> 2 <html xmlns="http://www.w3.org/1999/xhtml"> 3 <body> 4 個人ID 是:<%=FS.Utils.Web.Req.QS("ID")%> <br /> 5 個人ID2是:<%=FS.Utils.Web.Req.QS("ID2")%> 6 </body> 7 </html>
請在咱們看下請求不一樣的路徑返回的結果:
細心的讀者已經看到,咱們根本沒有333333.html或者333333-222.html的文件。這就是重寫URL的魅力。客戶端顯示的路徑仍然是xxx.html路徑。然而實際對應的物理文件確是:UrlRewriter.aspx文件。
到此,咱們的URL重寫就講完了。不過在這裏還有一個沒提到。就是在UrlRewriter.Config中。是支持域名變量的,什麼意思呢。有時候,測試環境跟生產環境的http地址是不同(甚至域名徹底不同)的。
考慮到這點。支持域名變量的形式。好比在上文中的正則用的是:
<LookFor>http://localhost:(\d+)/(\d+).html</LookFor>
而使用域名變量,咱們能夠轉變成:
<LookFor>http://{0}/(\d+).html</LookFor>
第二行中的{0}對應的是:General.config 配置文件的:RewriterDomain節點配置。而且用 ; 符合分隔。因此能夠支持多個這樣變量:{0}、{1}、{2}
這結講述了利用Farseer.Net的UrlRewriter技術在asp.net的WebForm下實現地址重寫。操做起來很簡單。你們趕忙試下吧。
QQ羣:116228666 (Farseer.net開源框架交流) 請註明:Farseer.Net
Farseer.Net是一款ORM框架 + 經常使用工具 + 擴展集合。
Farseer 意爲:先知、預言家 一般在某些場合時,提供計謀、策略。也但願該框架能給你們提供最大化的便捷。
ORM:其英文全稱是:Object(對象) Relational(關係) Mapping(映射)
Farseer.Net的目標是:快速上手、快速開發、簡單方便。
1 new User { ID = 1, Name = "張三" }.Insert()