發現現在幾乎所有的網站都對url中的漢字和特殊的字符，進行了urlencode操作， 也就是：
http://hi.baidu.com/%BE%B2%D0%C4%C0%CF%C8%CB/creat/blog/
這個樣子，中間%形式的，肯定就是我的登錄用戶名稱了吧。
為什么對這些字符進行了u的編碼形式，是為了字符編碼（gbk、utf8）還是為了不出現特殊的字符在url中？都知道要轉，但是轉了的真正好處呢。查看了網上的很多資料，也沒有找到更加准確的說法。
url轉義其實也只是為了符合url的規范而已。因為在標准的url規范中中文和很多的字符是不允許出現在url中的。
那哪些字符是需要轉化的呢？
-
ASCII 的控制字符
這些字符都是不可打印的，自然需要進行轉化。
-
一些非ASCII字符
這些字符自然是非法的字符范圍。轉化也是理所當然的了。
-
一些保留字符
很明顯最常見的就是“&”了，這個如果出現在url中了，那你認為是url中的一個字符呢，還是特殊的參數分割用的呢？
-
就是一些不安全的字符了。
例如：空格。為了防止引起歧義，需要被轉化為“+”。
明白了這些，也就知道了為什么需要轉化了，而轉化的規則也是很簡單的。
按照每個字符對應的字符編碼，不是符合我們范圍的，統統的轉化為%的形式也就是了。自然也是16進制的形式。
和字符編碼無關
通過urlencode的轉化規則和目的，我們也很容易的看出，urleocode是基於字符編碼的。同樣的一個漢字，不同的編碼類型，肯定對應不同的urleocode的串。gbk編碼的有gbk的encode結果。
apache等服務器，接受到字符串后，可以進行decode，但是還是無法解決編碼的問題。編碼問題，還是需要靠約定或者字符編碼的判斷解決。
因此，urleocode只是為了url中一些非ascii字符，可以正確無誤的被傳輸，至於使用哪種編碼，就不是eocode所關心和解決的問題了。
詳細https://blog.csdn.net/u013833031/article/details/78828539
Java中轉化
URLEncode和URLDecode用於完成普通字符串和 application/x-www-from-urlencoded MIME字符串之間的相互轉化
如果傳遞的字符串中包含非西歐字符的字符串，會被轉化成%XX%XX XX為十六進制的數字
try { // 將application/x-www-from-urlencoded字符串轉換成普通字符串 String keyWord = URLDecoder.decode("%C4%E3%BA%C3", "GBK"); System.out.println(keyWord); //輸出你好 // 將普通字符創轉換成application/x-www-from-urlencoded字符串 String urlString = URLEncoder.encode("你好", "GBK"); //輸出%C4%E3%BA%C3 System.out.println(urlString); } catch (UnsupportedEncodingException e) { // TODO Auto-generated catch block e.printStackTrace(); }
URL特殊字符需轉義
1、空格換成加號(+)
2、正斜杠(/)分隔目錄和子目錄
3、問號(?)分隔URL和查詢
4、百分號(%)制定特殊字符
5、#號指定書簽
6、&號分隔參數
轉義字符的原因：
如果你的表單使用get方法提交，並且提交的參數中有“&”等特殊符的話，如果不做處理，在service端就會將&后面的作為另外一個參數來看待。例如
表單的action為list.jsf?act=go&state=5
則提交時通過request.getParameter可以分別取得act和state的值。
如果你的本意是act='go&state=5'這個字符串，那么為了在服務端拿到act的准確值，你必須對&進行轉義
url轉義字符原理：
將這些特殊的字符轉換成ASCII碼，格式為：%加字符的ASCII碼，即一個百分號%，后面跟對應字符的ASCII（16進制）碼值。例如 空格的編碼值是"%20"。
URL特殊符號及對應的十六進制值編碼：
1. + URL 中+號表示空格 %2B
2. 空格 URL中的空格可以用+號或者編碼 %20
3. / 分隔目錄和子目錄 %2F
4. ? 分隔實際的 URL 和參數 %3F
5. % 指定特殊字符 %25
6. # 表示書簽 %23
7. & URL 中指定的參數間的分隔符 %26
8. = URL 中指定參數的值 %3D