在URL中壓縮參數

我網站上的網址可能會變得很長，並且我的理解是，網址是通過http請求傳輸的。所以這個想法來壓縮url中的字符串。在URL中壓縮參數

從我在互聯網上的搜索中，我發現了使用短網址的建議，然後將該網址鏈接到長網址。編號傾向於不使用此解決方案，因爲我將不得不做一個額外的數據庫檢查來轉換長和短的網址。

，在我的頭上留下3個選項：

散列，我不認爲這是一個選項。如果你想要一個安全的哈希算法，它會很長。
壓縮url字符串，基本上讓服務器在獲取url參數時壓縮字符串。
更改網址，使其不具有描述性，這是不好的，因爲它會使我的開發更難（這是一個1人項目）。

考慮到大量的操作系統/瀏覽器在那裏，我認爲，就好像其他人已經嘗試過或有一些聰明的建議。

如果它的網址參數可以達到100 +字符。

例子：

mysite.com/Reports/Ability.aspx?PlayerID=7737&GuildID=132&AbilityID=1140&EventID=1609&EncounterID=-1&ServerID=17&IsPlayer=True

編輯：

讓我澄清一下這個ATM是不是打破了現場。它更多的是關於我學習如何找到一個好的解決方案（我深知這是微型優化，我的網站是非常快速的ATM），並使我的網站更快（挑戰自我，成爲更好的編碼器）。

還有一個整容問題，我個人認爲一個URL比地址欄長一些看起來不好。

來源

2010-01-13 EKS

我不確定我明白您的長URL有什麼問題？通常我會盡量避免它們，但如果這是必要的，那麼無論如何您都不會依賴於用戶記住它，那麼爲什麼要經歷所有的壓縮麻煩？即使使用1000個字符（〜2KB）的URL，頁面請求也不會很慢。

但是，如果可能的話，我會考慮使用POST而不是GET來優化URL，但這當然取決於您的實現/環境。

來源

2010-01-13 12:11:27 synhershko

大多數瀏覽器可以處理URL中的2048個字符;如果您不想使用長參數列表，則始終可以通過POST請求傳遞參數。

來源

2010-01-13 12:13:02

擴展網址存在理論問題。確切的限制因瀏覽器而不同（在IE的排序版本中約爲2k）和服務器（Apache中的4-8k，因版本和配置而異），並且在我知道的任何RFC中都沒有正式指定。

我同意synhershko，如果您擔心您的URL變長太長，請用表單POST參數替換URL。

來源

2010-01-13 12:15:01

你有一些衝突的要求，因爲你想縮短/壓縮的網址，而不使它更少描述。由於縮短了網址的本質，在某種程度上，您將不那麼具有描述性。

據我所知，您的目標是通過減少請求發送來優化。你提到100多個字符，而不是1000+，我假設他們沒有得到那大？在這種情況下，我認爲這是一種不必要的微觀優化。

要添加到使用POST的以前的建議，一個簡單的事情是隻縮短鍵而不是使用全名，如果你不想做完整的URL縮短例如：

mysite.com/Reports/Ability.aspx?pid=7737&GID=132&AID=1140&EID=1609&EnID=-1&SID=17&IsP=True

這些都是明顯較少描述性。

但正如我所說，你有一個真正的問題與長URL？

來源

2010-01-13 12:19:59 AdaTheDev

給原始帖子增加了一些信息。具有描述性的思想是當它處於調試模式時，它將基本支持未壓縮鏈接和壓縮鏈接。但基於反饋，它似乎改變了網址，所以它不那麼描述是現在最好的解決方案。 – EKS 2010-01-13 12:39:59

這裏推薦幾次使用POST而不是GET。我強烈建議AGAINST根據URL的外觀選擇HTTP動作。除了在瀏覽器中顯示的內容之外，還有更多選擇。

快速概述：

http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist

來源

2010-01-13 12:26:30 Paul

該網站主要是「靜態」內容，所以通過您的檢查列表我不應該使用POST。 – EKS 2010-01-13 12:37:44

我遇到過類似的情況，雖然我的理由是優化搜索引擎優化。對我而言，這取決於您對頁面網址變量所做的操作，它們是否被添加到所有/大多數頁面上？如果他們對我來說幾乎總是有一個更好的方法，但是如果你遠離發展道路，現在可能已經太晚了。

我喜歡能夠「讀取」一個URL，尤其是當我在導航中深入到2層或更多層的未知網站中，並且網站設計不佳時，它對於高級用戶來說通常是最簡單和最快的方式，找到他們在網站上的位置。

如果你是從一個角度SEO角度感興趣，其通常最好能有隻包含一個層次：/ - _ 搜索引擎會試圖讀取URL的，see this video by Matt Cutts（不記得有多遠成他提到它，但它是一個很好的觀賞反正視頻...）

來源

2010-01-13 12:52:27 Alex

有幾個選項添加到其他的答案：

使用爲您導航一個子類LinkButton。這將額外的數據（例如PlayerId）作爲屬性保存在其視圖狀態中。如果您通過電子郵件向用戶提供網址，這不會有太大的幫助。
使用MVC路由引擎產生稍微改進的URL - 查詢字符串沒有鍵。例如mysite.com/Reports/Ability/7737/132/1140/1609/-1/17/True
Create your own URL shortener like tinyurl.com。將URL與每個查詢字符串值一起存儲在數據庫中以進行查找。
只需爲最常見的報告設置一些友好的網址，例如mysite.com/Reports/JanuaryReport。您也可以使用MVC路由引擎進行此操作。

MVC路由引擎是獨立的，可以工作，而無需您的網站是一個MVC網站。

來源

2010-01-13 12:52:50

任何形式的URL的壓縮（散列，壓縮，非描述性）的是要：

使網址難以閱讀，記住並輸入正確
影響性能如您必須先解密/解壓縮/轉換網址，然後才能使用它。

而且，散列通常是considered to be non-reversible - 給你不應該能夠制定出產生它的散列值，但你可以用它來查找數據庫中的值，它可以讓你回到你的第一個短期長期查詢的問題。

您可以輕鬆地刪除每個參數末尾的冗餘「ID」，並可能刪除元音或類似的「縮短」url而不會從請求的語義中丟失太多。

但說實話，你的URL的長度是在性能方面擔心的最不必要的事情之一 - 查看你在瀏覽器和服務器之間來回發送的cookie的大小，以及您發回的頁面大小。

來源

2010-01-13 14:01:34

在URL中壓縮參數

回答

相關問題