前幾天看到園子里一篇關于 Url 重寫的文章《獲取ISAPI_Rewrite重寫后的URL》 ， URL-Rewrite 這項技術早已不是一項新技術了，這個話題也已經(jīng)被很多人討論過多次。搜索一下URL-Rewrite可以找到很多URL-Rewrite方面的文章和組件，自己以前也多次接觸過這個東東，也來說說吧。 ScottGu 有一篇非常經(jīng)典的 URL-Rewrite Blog
Tip/Trick: Url Rewriting with ASP.NET http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
為什么要進行URL-Rewrite
ScottGu的blog中給出了兩個重要的原因：
1.保證WebApplication在進行結構調(diào)整，移動頁面位置時，用戶收藏的URL不會因此而成為死鏈。
2. SEO優(yōu)化。
摘引自ScottGu Blog 的原文
---------------------------------------------------------------------------
Why does URL mapping and rewriting matter?
The most common scenarios where developers want greater flexibility with URLs are:
1) Handling cases where you want to restructure the pages within your web application, and you want to ensure that people who have bookmarked old URLs dont break when you move pages around. Url-rewriting enables you to transparently forward requests to the new page location without breaking browsers.
2) Improving the search relevancy of pages on your site with search engines like Google, Yahoo and Live. Specifically, URL Rewriting can often make it easier to embed common keywords into the URLs of the pages on your sites, which can often increase the chance of someone clicking your link. Moving from using querystring arguments to instead use fully qualified URLs can also in some cases increase your priority in search engine results. Using techniques that force referring links to use the same case and URL entrypoint (for example: weblogs.asp.net/scottgu instead of weblogs.asp.net/scottgu/default.aspx) can also avoid diluting your pagerank across multiple URLs, and increase your search results.
In a world where search engines increasingly drive traffic to sites, extracting any little improvement in your page ranking can yield very good ROI to your business. Increasingly this is driving developers to use URL-Rewriting and other SEO (search engine optimization) techniques to optimize sites (note that SEO is a fast moving space, and the recommendations for increasing your search relevancy evolve monthly). For a list of some good search engine optimization suggestions, Id recommend reading the SSW Rules to Better Google Rankings, as well as MarketPositions article on how URLs can affect top search engine ranking.
---------------------------------------------------------------------------
第一點原因中所描述的場景，在Web站點改版中經(jīng)常碰到。Web站點改版經(jīng)常會調(diào)整一些頁面的位置，QueryString中參數(shù)的結構等等。很可能使原來用戶在收藏夾中收藏的鏈接成為死鏈。在這種場景下URL-Rewrite像是軟件架構技術中的一個中間層的概念，URL-Rewrite對外公開的URL是被重寫過的，這個URL被用戶收藏，不會變，當Web站點調(diào)整，內(nèi)部Page的位置改變了，使得內(nèi)部實際的URL地址也改變了，這時修改內(nèi)部的重寫規(guī)則，讓原來對外公開的URL重寫到新的內(nèi)部URL上。從而保證了對外URL不變，其實對內(nèi)已經(jīng)完成了頁面位置的調(diào)整。雖然URL-Rewrite可以做到防止死鏈的產(chǎn)生，但是大多數(shù)站點在改版或調(diào)整時，不會使用URL-Rewrite來防止死鏈的產(chǎn)生，一般會直接修改404 The page cannot be found 頁面，把404出錯頁面改成一個更加友好的提示頁面，并且會在幾秒鐘之后跳轉到網(wǎng)站首頁。
第二點原因是SEO了，如果您的站點是個內(nèi)部OA ERP CRM這種站點，只需要自己內(nèi)部人員來訪問。其實完全可以不用做SEO，因為這種站點根本不需要搜索引擎來收錄，也不需要別人通過搜索引擎找到這個站點，所以這種站點完全沒有必要進行SEO優(yōu)化。如果您的站點是個商業(yè)站點，新聞站點，娛樂站點，越多人訪問越好的站點，SEO優(yōu)化是非常重要，此時通過URL-Rewrite進行SEO優(yōu)化也就非常必要了。隨著搜索引擎逐漸成為人們查找信息，索取資源的首選工具，搜索引擎對一個站點的影響也就愈來愈大，下面是 zhangsichu.com 9-1～9-10 這段時間內(nèi)的第三方來路數(shù)據(jù)統(tǒng)計。
來路統(tǒng)計是通過記錄httpheader中的Referer，來得知用戶在瀏覽這個頁面之前所在的那個頁面。從而得出用戶是通過那個頁面到達這個頁面的。
在266個獨立IP中，有200個IP是來自搜索引擎的。也就是說，用戶先通過搜索引擎的搜索結果，然后來到zhangsichu.com的用戶有200個。占到了75.2%。一大半的人是通過搜索來的。充分說明了SEO對站點的重要，在這種情況下，就必須做URL-Rewrite進行SEO優(yōu)化了。
如果您的站點既不需要考慮URL兼容防止死鏈問題，也不需要進行SEO優(yōu)化，就完全沒有必要進行URL-Rewrite。URL-Rewrite是一個對性能有害的處理過程。
常用的URL-Rewrite方案
URL-Rewrite既可以發(fā)生在Web服務器(IIS/Apache)一級，也可以發(fā)生在Web應用程序一級(Asp.Net/Jsp/PHP/…)。
1.Web應用程序級別的URL-Rewrite
在Web應用程序級別的URL-Rewrite。有三個比較著名的現(xiàn)成組件。
1) 微軟提供的 URL-Rewrite http://msdn2.microsoft.com/zh-cn/library/ms972974.aspx
2) Open Source的 UrlRewriter.NET http://urlrewriter.net/
3) UrlRewriting http://www.urlrewriting.net/en/Download.aspx
這種組件內(nèi)部核心的工作原理: 都是在自己的Web Application的web.config中添加httpModule。用這個httpModule來處理重寫。(其實也可繼承System.Web.HttpApplication，在Application_BeginRequest中插入一個自己的方法處理重寫)
其中核心的處理代碼，下面的代碼摘引自UrlRewriter.NET組件。
1)從IHttpModule繼承得到一個自己的HttpModule，這個HttpModule需要在web.config中配置，說明所有的請求都要經(jīng)過這個HttpModule。
public sealed class RewriterHttpModule : IHttpModule |
/// Initialises the module. |
/// <param name="context">The application context.</param> |
void IHttpModule.Init(HttpApplication context) |
context.BeginRequest += new EventHandler(BeginRequest); |
private void BeginRequest(object sender, EventArgs e) |
HttpContext.Current.Response.AddHeader(Constants.HeaderXPoweredBy, Configuration.XPoweredBy); |
2)讀取重寫規(guī)則，判斷是否需要重寫，確定如何重寫，進行重寫。
string originalUrl = ContextFacade.GetRawUrl().Replace("+", " "); |
RewriteContext context = new RewriteContext(this, originalUrl, |
ContextFacade.GetHttpMethod(), ContextFacade.MapPath, |
ContextFacade.GetServerVariables(), ContextFacade.GetHeaders(), ContextFacade.GetCookies()); |
ContextFacade.SetStatusCode((int)context.StatusCode); |
if ((context.Location != originalUrl) && ((int)context.StatusCode < 400)) |
if ((int)context.StatusCode < 300) |
_configuration.Logger.Info(MessageProvider.FormatString(Message.RewritingXtoY, |
ContextFacade.GetRawUrl(), context.Location)); |
HandleDefaultDocument(context); |
ContextFacade.RewritePath(context.Location); |
_configuration.Logger.Info(MessageProvider.FormatString(Message.RedirectingXtoY, |
ContextFacade.GetRawUrl(), context.Location)); |
ContextFacade.SetRedirectLocation(context.Location); |
else if ((int)context.StatusCode >= 400) |
else if (HandleDefaultDocument(context)) |
ContextFacade.RewritePath(context.Location); |
SetContextItems(context); |
這種重寫是ASP.NET Pipeline級別的重寫，可以重寫一切Asp.net接管的請求。
在這里對/Pd/Book.aspx的請求被重寫到了 /Pd.aspx?Cg=books.
Web應用程序級別的URL-Rewrite只能重寫Web應用程序接管的請求。它沒有辦法處理.js .jpg的重寫。原因是這些請求到達IIS后，IIS根本就沒有把這些請求分發(fā)到Asp.Net,所以這些請求就不會發(fā)生重寫的處理和操作。在IIS中可以配置，對哪些后綴的請求是被IIS分發(fā)到Asp.Net的。
如果您一定要在Asp.Net級別對.js的請求進行重寫，可以在這里指定.js的請求由Asp.Net接管，但是這時您需要自己處理.js的Response。Web服務器級別的URL-Rewrite可以比較好的解決這方面的問題吧。
2. Web服務器級別的URL-Rewrite
