今天寫代碼要發起一個HTTP GET請求，WebService接口我們隨處可見，作為一個“業務程序員”我們也每天都在寫。。。所以指尖跳動，分分鐘就出現了下面的代碼：
<code>try {
encode = URLEncoder.encode(JsonUtil.convertObject2Json(reqParamsMap), "UTF-8").replace("\\\\+", "%20");
} catch (UnsupportedEncodingException e) {
logger.error("URLEncoder.encodec出錯：", e);
}/<code>擼完碼我回頭看了一眼，我習以為常的URL編碼，到底是為什麼呢？我想大概是怕傳輸數據中的特殊字符造成什麼不可預知的問題吧。
工作完成，測試沒有問題。我今天打算打破砂鍋問到底，讓我們一探究竟，到底為什麼要編碼？
知道了How，我們還要知道Why！！！
找資料
打開bing，國際搜索（梯子斷了很久了……）在stackoverflow上看到也有很多人提出了這個問題，很多的人回答都指向了一個RFC
<code>RFC(Request For Comments)-意即“請求評議”，包含了關於Internet的幾乎所有重要的文字資料。
通常，當某家機構或團體開發出了一套標準或提出對某種標準的設想，
想要徵詢外界的意見時，就會在Internet上發放一份RFC，
對這一問題感興趣的人可以閱讀該RFC並提出自己的意見；
絕大部分網絡標準的指定都是以RFC的形式開始，經過大量的論證和修改過程，
由主要的標準化組織所指定的，但在RFC中所收錄的文件並不都是正在使用或為大家所公認的，
也有很大一部分只在某個局部領域被使用或並沒有被採用，
一份RFC具體處於什麼狀態都在文件中作了明確的標識./<code>
RFC1738
可以看到這個RFC是小LEE提出來的，哈哈。裡面規定了很多東西，比如url的格式、編碼、字符，還有很多scheme，我沒看全，看到了FTP和HTTP。
總結一波
URL（統一資源定位符）是萬維網中資源的地址。URL具有明確定義的結構，該結構由萬維網的發明者Tim Berners-Lee在RFC 1738中提出。
每個網址都採用通用語法，如下所示：
<code>scheme:[//[user:password@]host[:port]]path[?query][#fragment]/<code>
[user:password@]由於安全原因，不建議使用URL語法的某些部分，因此很少使用。以下是您在互聯網上經常看到的URL的示例-
<code>https://www.google.com/search?q=hello+world#brs/<code>
對定義統一資源定位符（URL）語法的初始RFC進行了許多改進。當前定義通用URI語法的RFC是RFC 3986。這篇文章包含最新RFC文檔中的信息。
URL由屬於US-ASCII字符集的有限字符集組成。這些字符包括數字（0-9），字母（AZ，az），以及一些特殊字符（"-"，"."，"_"，"~"）。
ASCII控制字符（例如退格，垂直製表符，水平製表，換行等），不安全的字符像space，\\，，{，}等等，以及ASCII字符以外的任何字符被不允許直接的URL內放置。
此外，URL中有些字符具有特殊含義。這些字符稱為保留字符。的保留字符的一些例子是?，/，#，:等作為URL的一部分發送，無論是在查詢字符串或路徑段，必須不包含這些字符的任何數據。
那麼，當我們需要在URL中傳輸包含這些不允許的字符的任何數據時，我們該怎麼辦？好吧，我們對它們進行編碼！
URL編碼將URL中保留的，不安全的和非ASCII字符轉換為所有Web瀏覽器和服務器普遍接受並理解的格式。它首先將字符轉換為一個或多個字節。然後，每個字節由兩個十六進制數字表示，後跟一個百分號（%）-（例如%xy）。百分號用作轉義字符。
URL編碼也稱為百分比編碼，因為它使用百分號（%）作為轉義字符。
URL編碼示例
空格：您可能會遇到的最常見的URL編碼字符是space。space十進制字符的ASCII碼為32，轉換為十六進制時為20。現在，我們在十六進制表示形式之前加一個百分號（%），這使我們獲得了URL編碼值- %20。
+: 看到我一開始代碼裡的replace，那是因為：
w3c的規定是空格被替換為+，Java中的URLEncoder正是這種情況，會把空格轉成+
這就會導致在一些遵循RFC的應用上無法解碼或其他問題，所以我們取一個折中的方法，要在URLEncoder.encode()之後把+替換為%20
ASCII字符編碼參考
下表是ASCII字符對其相應的URL編碼形式的引用。
請注意，不需要編碼字母數字ASCII字符。例如，您不需要編碼字符'0'以%30如圖所示下表。可以原樣發送。但是根據RFC編碼仍然有效。表格中所有可以安全地在URL中傳輸的字符都顯示為綠色。
下表使用RFC 3986中定義的URL編碼規則。
表格粘不過來。。。頭條這個編輯器有毒吧。想了解的可以自行搜索下，也可以聯繫我哦！！！
閱讀更多 evilRat 的文章
