我們有一個CMS系統，可以創建包含多個參數的長URL。我們想改變他們的方式，讓他們更友善。
由於我們已經在CMS上構建了許多站點，因此重寫CMS以創建友好的URL（儘管這是我們正在考慮的方法，如果找不到替代方法），我們正在尋找一種方法當用戶點擊較長的網址時，網址將變爲友好的 - 在瀏覽器中 - 而不使用Response.Redirect（）。
在Wordpress中存在這樣的方法（我不確定它是在代碼還是在Apache中完成），我想知道是否也可以在ASP.NET 2.0中完成。
需要考慮的另一件事是URL之間的變化必須通過訪問數據庫來完成。
UPDATE：我們使用IIS6在ASP.NET中不重定向的網址重寫
爲了迴應額外的評論，我認爲您需要做的就是咬緊牙關，修改CMS以將新鏈接寫入頁面。你已經說過你有正常的URL重寫功能，可以在新的URL傳入時將新的URL翻譯成舊的。如果你也要在你的標記中寫出新的URL，那麼一切都應該是簡單的。
從SEO的角度來看，如果您的CMS生成的頁面有舊鏈接，那麼這就是搜索引擎將會看到和索引的內容。沒有什麼可以做的，JavaScript，重定向或其他。 （雖然永久重定向會讓你有一點點）。
我也認爲，你必須在Wordpres中看到的可能是重定向。沒有找到一個例子，我不能確定。要做的事情是使用Fiddler或另一個http調試器來查看當你遵循其中一個鏈接時會發生什麼。
對於完美的搜索引擎優化，一旦你有新的網址工作出站和入站，你想要做的是決定你的新網址是權威的網址。使舊網址重新定向到新網址，或者使用canonical link tag回到舊網址的新網址。
我不能確定你在說什麼在這裏，但基本上一個頁面的用戶已經在讀包含老，長，網址，你想它在瀏覽器從服務器請求頁面之前，在客戶端動態更改爲新的短URL？
我認爲這樣做的唯一方法就是使用Javascript來更改網址，以響應onclick或document.ready，但這樣做毫無意義。你需要知道JavaScript重新寫入的新短url，如果你知道這一點，爲什麼不簡單地將該URL放入鏈接？
這聽起來更像是你想要的URL路由，包括ASP.Net 4和3.5？
標準URL重寫會修改服務器上的傳入請求對象，以便客戶端瀏覽器提交新URL，並且下游頁面處理程序將看到舊URL。我相信路由選擇將這個概念擴展到外出響應，在響應頁面中將舊URL重新寫入新URL，然後再發送到客戶端。
斯科特谷也有正常的URL的舊後改寫概述幾種不同的方式來做到這一點。也許你可以通過掛接Application_PreSendRequestContent並手動修改響應流中的所有href值來擴展這個概念，但我不會自己喜歡它。 http://weblogs.asp.net/scottgu/archive/2007/02/26/tip-trick-url-rewriting-with-asp-net.aspx
謝謝。我們不能使用URL路由解決方案，因爲我們仍然在ASP.NET 2.0中。至於Scott Gu的舊帖子 - 我們已經實現了該解決方案，但它不會更改用戶瀏覽器中的URL – 2010-11-11 07:00:52
如果您使用II7做到這一點，最簡單的方法是使用URL Rewrite Module根據這個鏈接，您可以
定義強大的規則進行改造 複雜的URL轉化爲簡單和 一致的Web地址
URL重寫允許Web管理員 使用.NET編寫 重寫提供商， 規則表達式匹配，0輕鬆構建強大的規則和通配符映射來檢查兩個URL中的 信息以及其他 HTTP標頭和IIS服務器變量。 可以編寫規則來生成網址 ，可以讓用戶更容易記住 ，簡單的搜索引擎就可以到 索引，並允許URL遵循 一致和規範的主機名 格式。URL重寫進一步簡化了 規則創建過程，支持 用於內容重寫，規則模板， 重寫映射，規則驗證和 導入現有的mod_rewrite規則。
否則，您將不得不使用Andrew M描述的技術或使用Response.Redirect。無論如何，我相當肯定所有這些方法都會導致http 301響應。我提到這個是因爲它不清楚你爲什麼不想做Response.Redirect。這是一個編碼約束嗎？
更新 由於您使用的是IIS 6，因此您需要使用其他方法進行URL重寫。
This Article來自Scott Mitchell詳細描述瞭如何去做。
實現URL重寫
URL重寫可以實現 要麼在IIS Web服務器級別的ISAPI篩選器，或使用HTTP 模塊或HTTP處理程序在ASP.NET 水平。本文重點介紹使用 ASP.NET實現URL重寫的 ，因此我們不會深入研究 實現使用ISAPI過濾器重寫URL 的具體細節。有 ，然而，衆多第三方 ISAPI篩選器可用於URL重寫 ，如：
和很多人一樣！
本文繼續介紹如何實現HTTP模塊或處理程序。
性能 重定向響應HTTP 301通常只包含少量的數據< 1K。所以我會很驚訝，如果它是顯而易見的。 例如，在這些網址的頁面加載的差別並不noticible
"https://stackoverflow.com/q/4144940/119477"
"https://stackoverflow.com/questions/4144940/url-rewrite-without-redirect-in-asp-net"
（我一直在使用ieHTTPHeaders證實，HTTP 301是做什麼用的URL中的變化）
網頁排名
This is是谷歌的網站管理員中心坐e不得不說約301。
如果您需要更改 頁面的URL，因爲它是在搜索引擎顯示 結果，我們建議您使用 服務器端的301重定向。這是 確保用戶和 搜索引擎定向到 正確頁面的最佳方式。
謝謝。我更新了我的問題，寫出我們使用IIS6。我們不希望重定向的原因是我們認爲它會a）花費更長的時間加載頁面，並且b）會傷害搜索引擎中的頁面排名。而且由於我們轉向友好的網站的原因是因爲搜索引擎，我們不想傷害同樣的原因 – 2010-11-11 06:56:06
非常感謝您的詳細解答。但是，涉及ISAPI篩選器或HTTP模塊的方法的問題在於，規則是在web.config級別編寫的，我們需要數據庫訪問權限才能進行重寫。另外，它們不能解決*創建短URL的問題，它們只能幫助解釋它們，對此我們已經有了一個實現（在Application_BeginRequest中使用Context.RewritePath）。 – 2010-11-17 06:41:24
@Lea沒問題。作爲一個附註，如果你編寫一個HTTP模塊，規則的來源可以是任何你喜歡的，它不必侷限於一個配置文件。同樣使用RewritePath不會更改您在原始帖子中作爲要求提及的瀏覽器中的URL。這是不同的用例，多個URL指向相同的位置，但作爲不同的URL顯示給用戶。 – 2010-11-17 22:39:52
爲什麼你認爲這樣的事情存在於WordPress？ – 2010-11-10 15:50:23
因爲我看到它發生 - 我看到有一個鏈接到一個帖子，並且鏈接是（例如）：http：// domainname /？p = 2430，並且當我點擊鏈接時，url更改爲包括職位slu。。我猜 - 儘管我不確定 - 在沒有重定向的情況下完成更改 – 2010-11-11 06:27:53
您可以使用fiddler或ieHttpHeaders來查看響應。如果你看到301，那麼它的重定向 – 2010-11-11 23:02:10