URL無處不在，不過似乎開發人員並沒有真正地理解它們，因為我在Stack Overflow上經常看到有人在問如何正確的創建一個URL。想知道URL語法是如何工作的，可以看下Lunatech的這篇文章，非常不錯。
本文不會深入介紹URL的全部語法(如果你想全面了解URL的話，可以讀下RFC 3986 ， RFC 1738 , 以及上面提到的那篇文章，還有W3上面的文檔)， 這裡我想講的是常見的一些庫在操作URL方面存在的錯誤，以及如何通過URL-builder 來正確的使用它，這是我們發布的一個用於正確地創建URL的Java庫。
問題1：Java的URLEncoder
這個類不僅名字取的很差，而且它的文檔上來第一句話就不太對頭。
Utility class for HTML form encoding.
你可能正納悶為什麼叫URLEncoder呢，看到這行就徹底無語了。
如果你讀過Lunatech的那篇博文，現在你應該明白了，你沒法通過這個類將一個URL串奇蹟般地轉化成一個安全，正確編碼的URL對象，當然如果你沒做足功課的話，這裡有個小例子可以幫助你理解下。
假設你有個HTTP的服務端點http://foo.com/search，它接受一個查詢參數p，p的值就是要查找的字符串。如果你搜索”You & I”這個串的話，你第一次創建的搜索的URL可能是這樣：http://foo.com/search?q=You & I。這個當然沒法工作，因為&是分隔查詢參數name/value對的分隔符。如果你拿到這個錯亂的URL串的話，你對它簡直束手無策，因為首先你就沒法正確的解析它。
那好，我們來使用下URLEncoder。 URLEncoder.encode(“You & I”, “UTF-8″)是結果是You+%26+I。這個%26解碼之後就是&，而+號在查詢串中代表的就是空格，因此這個URL是能正常工作的。
現在假設你想使用你的查詢串來拼接URL路徑，而不是放到URL參數里面。很明顯，http://foo.com/search/You & I是錯誤的。不幸的是，URLEncoder.encode()的結果也是錯的。 http://foo.com/search/You+%26+I解碼後會得到/search/You+&+I，因為+號在URL路徑中是不會解析成空格的。
URLEncoder或許能滿足你的一些場景。但不幸的是，它這個過於通用的名字使得開發人員很容易誤用它。因此最好的方法就是不要使用它，免得後面別的開發人員在你的基礎上又使用了別的功能時犯錯(除非，你真的是在進行”HTML表單編碼”)。
問題2：Groovy HttpBuilder以及Java的URI
HTTP Builder 是Groovy的一個HTTP客戶端庫。
創建一個普通的GET請求非常簡單：
new HTTPBuilder("http://localhost:18080").request(Method.GET) { uri.path = "/foo" }這段代碼會發送GET /foo HTTP/1.1到服務端(你可以運行nc -l -p 18080之後再執行這段代碼驗證下)。
我們來試一下包含空格的URL。
new HTTPBuilder("http://localhost:18080").request(Method.GET) { uri.path = "/foo bar" }這個發送的是GET /foo%20bar HTTP/1.1，看起來還不錯。
現在假設我們的路徑中有一段就叫做foo/bar。這可不能簡單地發送foo/bar就完了，因為這會被認為成路徑中包含兩段，foo和bar，那我們試下foo%2Fbar吧(把/替換成對應的編碼)。
new HTTPBuilder('http://localhost:18080').request(Method.GET) { uri.path = '/foo%2Fbar' }這個發送的則是GET /foo%252Fbar HTTP/1.1。這可不太妙。 %2F中的%被重複編碼了，這樣解碼後拿到的路徑是foo%2Fbar而不是foo/bar。這裡其實真正要怪的是java.net.URI，因為這個HTTPBuilder裡的URIBuilder類用的就是它。
上述代碼中的配置閉包中暴露的uri屬性的類型是URIBuilder。如果你通過uri.path = …來更新uri的path屬性的話，它最終會調用URI的一個構造方法，這個方法對於傳入的path屬性是這麼描述的：
如果提供了path參數，則將它追加到URL後面。 path裡面的字符，只要不是非保留，標點，轉義及其它分類(譯註：這幾個分類在RFC 2396中有詳細說明)的字符，同時又不是/或者@號的，都會進行編碼。
這個做法意義不大，因為如果未編碼前的文本包含特殊字符的話，它就無法生成一個正確編碼的路徑分段。換句話說，“我會對這個字符串進行編碼，而編碼之後它就是正確的”，這當然是個謬論，而URI正好是這個謬論的犧牲品。如果字符串已經正確編碼了，那就沒什麼問題，如果不是的話，那就完蛋了，因為這個串沒法解析。事實上，文檔裡說的不會對/號轉義的意思是，它假設path串已經正確地編碼了(就是說正確地使用/來分隔路徑)，同時又還沒有正確地編碼(除了/外的其它部分仍然需要進行編碼)。
如果HTTPBuilder不使用URI類的這個存在缺陷的功能就好了，當然了，如果URI自己本身沒問題的話就更好了。
正確的做法
我們寫了這個url-builder，它能幫助開發人員方便的拼接各種類型的URL。它遵循了篇首那幾個參考資料中的編碼規範，同時它還提供了流式的API。下面這個使用示例幾乎可以涵蓋所有的使用場景了：
UrlBuilder.forHost("http", "foo.com") .pathSegment("with spaces") .pathSegments("path", "with", "varArgs") .pathSegment("&=?/") .queryParam("fancy + name", "fancy?=value") .matrixParam("matrix", "param?") .fragment("#?=") .toUrlString()結果是: http://foo.com/with%20spaces/path/with/varArgs/&=%3F%2F;matrix=param%3F?fancy%20%2B%20name=fancy?%3Dvalue#%23?=
這個例子演示了URL各個部分的不同的編碼規則，比如說在路徑中未編碼的&=是允許的，而?/則是需要編碼的，但在查詢參數中=是需要編碼的，但?號則不需要，因為這裡已經是查詢串的部分了(譯註：查詢串是從一個?號開始的，因此後面可以包含?號)。
感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！