IIS默認領受的最大URL16384字符。
實際上URL非常首要，URL設想是Web假想中常被忽視的器材。這不僅是一個網頁唯一的門路，還涉及到站點是否干凈，友愛。本文報告URL這個習以為常的Web元素中包含的大批量不應為忽視的常識，準則與最佳實踐。必要注重的W3C建議利用URI庖代URL一說
對于URL一些準則
起首是與URL無關的一些準則。
永久地代表一個在線對象一個URL必須唯一地。
URL必須和Internet上的對象一對一婚配。然則現(xiàn)實中，URL最基本的任務是唯一地代表Internet上的一個對象。這很難實現(xiàn)，經?？梢曰蛟S通過多個URL達同一個頁面，好比，這種景遇在古代CMS中更是比比皆是針對這個成績，SEOmoz有一篇很好的文章，講到如何利用CanonURL機制處置懲罰站點中的反復URL成績
不得不變動URL必定利用HTTP301機制，URL應當是永遠的這就要求你站點上線前就非常謹慎地規(guī)劃URL如果有一天。見告瀏覽器和搜索引擎，誰人URL所代表的工具，已經搬家到新地址，這個機制可以或許保障你舊所在所獲得PR不會被清零。
盡可能用戶友愛
URL應該為最終用戶而設計。連結URL友愛的一個好辦法是保證可讀性的同時讓它盡可能短。好比/about就好過/about-acme-corp-pag固然，這是URL設想的底子。貫穿連接簡短不能殉國可讀性，/13d2一類的所在短則短矣，但并不友好。如果要在TwitterFacebook一類的社會媒體搜集分享你URL可以或許利用Bit.li一類的網址耽誤對象，但這種工具發(fā)生的延長URL并不友好，Wordpress一類的CMS中，可以或許利用PrettyLinkPro或ShortURLplugin一類的可控制的所在耽誤插件。
比如數(shù)據(jù)庫的ID號，URL假想切忌操縱一些對用戶來說沒有意思的內容信息。/products/23如許的URL所在對用戶是極不友好的應當利用/products/ballpoint-pen一類的地點。
貫穿連接不合性
這樣可以或許為用戶帶來相信感，站點內的一切URL必須貫穿連接分歧的格式和結構。若是你必須變動URL格式和結構，必要利用HTTP301機制。
可預測的URL
若是你URL擁有很好的不合性，這也是URL不合性的一個表現(xiàn)。用戶可以或許按照URL猜測別的內容信息的URL如果/events/2010/01指向2010年1月份的日程內容信息，那
/events/2009/01應當指向2009年1月的日程。
/events/2010應當指向2010年全年的日程。
/events/2010/01/21應當指向2010年1月21日的日程。
URL中的關鍵詞
URL本身就是對頁面內容的反映。URL包含重點內容信息關鍵詞，URL中應該包含本頁重點內容的關鍵詞。也可以提高SEO機能。SEO一個很重要的原則就是URL所在中包含內容信息關鍵詞。
對于URL技術細節(jié)
下面說的無關URL一些技術細節(jié)。
aspx,URL不應包括.html.cfm一類的后綴
一個例外是.atom,這類動靜對最終用戶是沒有意思的卻占了計劃外的空間。.rss,.json一類的不凡地點，這類地址是有特別的意思的譯者注：某些虛擬主機式Web服務器，這種做法必然實際。
URL不應包孕WWW部門
一個額外的承擔，WWW部分并不包含任何意思。不友好?？梢曰蛟S利用HTTP301機制，將www.domain.com定向到domain.com
URL花式
URL格式如下:
domain.com/[keyinformation]/[name]/?[modifiers]
不應古代表數(shù)據(jù)結構，Keiinform部分個體代表消息的典范榜樣或類別。Modifi部分則屬于盤問字符串范疇。應當代表數(shù)據(jù)的潤飾。Keiinform部分應當盡可能冗長，同時應當呈現(xiàn)出一種層級關系。
由于他會忽視年份數(shù)字，GooglNew對動靜源有一個有趣的請求Googl要求動靜源頁面的URL中必須包含至多3位唯一的數(shù)字。是以，應該操縱一個5位或5位以上的數(shù)字。別的，也應該提供GooglNew站點輿圖若是你想向Googl供給消息，必須按這樣的結構供應URL當然貫穿連接不合性，可以或許預測性也是必須的
操縱小寫字符
這更容易閱讀。URL中所有字符都應使用小寫。
URL中包含的步履元素
好比show,URL盤問字符串中可以或許包含一些表示行為的元素。delete,edit等。非破壞性的步履可以或許表現(xiàn)在URL中，破碎摧毀性的步履應該利用POST
利用URL和睦字符
經常會用到一些特殊字符，URL中浮現(xiàn)網頁題目的時辰。應當把它轉換為URL和睦字符：
全部大寫字符換成小寫
諸如é一類的字符應轉換成對應的e
空格操縱短劃線代替
@,諸如!.#,$,%,^,&,*一類的字符應該操縱短劃線代替
雙短劃線應該操縱單短劃線代替
沒有需要的話，別的。預防利用%20一類的URL逃逸符。
更多觀點
可以或許操縱一些類似句子的URL如：ChriShiflett提議。
chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done
譯者增補：URL長度下限
但是，URL最大長度是幾多？W3CHTTP協(xié)定并沒有限定。實際操縱中，經過實驗，不合瀏覽器和Web服務器有不同的商定：
其中純道路部分不能跨越2048字節(jié)。IEURL長度下限是2083字節(jié)。
Firefox瀏覽器的所在欄中超過65536字符后就不再顯示。
Safari瀏覽器一致測試到80000字符還使命得好好的
還正常工作。Opera瀏覽器測試到190000字符的時辰。
Web服務器：
A pachWeb服務器在領受到大概4000字符長的URL時刻發(fā)生413EntitiTooLarge"過錯。
