URL中的空格有時候被編碼成%20，有時候被編碼成加號+，曾經迷糊過一段時間，后來查了下資料才搞明白。
一個URL的基本組成部分包括協議(scheme),域名，端口號，路徑和查詢字符串（路徑參數和錨點標記就暫不考慮了）。路徑和查詢字符串之間用問號?分離。例如http://www.example.com/index?param=1，路徑為index，查詢字符串(Query String)為param=1。URL中關於空格的編碼正是與空格所在位置相關：空格被編碼成加號+的情況只會在查詢字符串部分出現，而被編碼成%20則可以出現在路徑和查詢字符串中。
造成這種混亂局面的原因在於：W3C標准規定，當Content-Type為application/x-www-form-urlencoded時，URL中查詢參數名和參數值中空格要用加號+替代，所以幾乎所有使用該規范的瀏覽器在表單提交后，URL查詢參數中空格都會被編成加號+。而在另一份規范(RFC 2396，定義URI)里, URI里的保留字符都需轉義成%HH格式(Section 3.4 Query Component)，因此空格會被編碼成%20，加號+本身也作為保留字而被編成%2B，對於某些遵循RFC 2396標准的應用來說，它可能不接受查詢字符串中出現加號+，認為它是非法字符。所以一個安全的舉措是URL中統一使用%20來編碼空格字符。
Java中的URLEncoder本意是用來把字符串編碼成application/x-www-form-urlencoded MIME格式字符串，也就是說僅僅適用於URL中的查詢字符串部分，但是URLEncoder經常被用來對URL的其他部分編碼，它的encode方法會把空格編成加號+，與之對應的是，URLDecoder的decode方法會把加號+和%20都解碼為空格，這種違反直覺的做法造成了當初我對空格URL編碼問題的困擾。因此后來我的做法都是，在調用URLEncoder.encode對URL進行編碼后(所有加號+已被編碼成%2B)，再調用replaceAll(“\\+”, “%20″)，將所有加號+替換為%20。