URL編碼與二次encodeURI的區別和用法
阿新 • • 發佈：2019-02-04
這意味著，如果URL中有漢字，就必須編碼後使用。但是麻煩的是，RFC 1738沒有規定具體的編碼方法，而是交給應用程式（瀏覽器）自己決定。這導致"URL編碼"成為了一個混亂的領域。
下面就讓我們看看，"URL編碼"到底有多混亂。我會依次分析四種不同的情況，在每一種情況中，瀏覽器的URL編碼方法都不一樣。把它們的差異解釋清楚之後，我再說如何用Javascript找到一個統一的編碼方法
二、情況1：網址路徑中包含漢字
開啟IE（我用的是8.0版），輸入網址"http://zh.wikipedia.org/wiki/春節"。注意，"春節"這兩個字此時是網址路徑的一部分。
檢視HTTP請求的頭資訊，會發現IE實際查詢的網址是"http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82"。也就是說，IE自動將"春節"編碼成了"%E6%98%A5%E8%8A%82"。我們知道，"春"和"節"的utf-8編碼分別是"E6 98 A5"和"E8 8A 82"，因此，"%E6%98%A5%E8%8A%82"就是按照順序，在每個位元組前加上%而得到的。在Firefox中測試，也得到了同樣的結果。
所以，結論1就是網址路徑的編碼，用的是utf-8編碼。
三、情況2：查詢字串包含漢字
在IE中輸入網址"http://www.baidu.com/s?wd=春節"。注意，"春節"這兩個字此時屬於查詢字串，不屬於網址路徑，不要與情況1混淆。
檢視HTTP請求的頭資訊，會發現IE將"春節"轉化成了一個亂碼。
切換到十六進位制方式，才能清楚地看到，"春節"被轉成了"B4 BA BD DA"。我們知道，"春"和"節"的GB2312編碼（我的作業系統"Windows XP"中文版的預設編碼）分別是"B4 BA"和"BD DA"。因此，IE實際上就是將查詢字串，以GB2312編碼的格式傳送出去。
Firefox的處理方法，略有不同。它傳送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是說，同樣採用GB2312編碼，但是在每個位元組前加上了%。
所以，結論2就是，查詢字串的編碼，用的是作業系統的預設編碼。
四、情況3：Get方法生成的URL包含漢字
前面說的是直接輸入網址的情況，但是更常見的情況是，在已開啟的網頁上，直接用Get或Post方法發出HTTP請求。
根據臺灣中興大學呂瑞麟老師的試驗，這時的編碼方法由網頁的編碼決定，也就是由HTML原始碼中字符集的設定決定。
<meta http-equiv="Content-Type" content="text/html;charset=xxxx">
如果上面這一行最後的charset是UTF-8，則URL就以UTF-8編碼；如果是GB2312，URL就以GB2312編碼。
舉例來說，百度是GB2312編碼，Google是UTF-8編碼。因此，從它們的搜尋框中搜索同一個詞"春節"，生成的查詢字串是不一樣的。
百度生成的是%B4%BA%BD%DA，這是GB2312編碼。
Google生成的是%E6%98%A5%E8%8A%82，這是UTF-8編碼。
結論3就是，GET和POST方法的編碼，用的是網頁的編碼
五、情況4：Ajax呼叫的URL包含漢字
前面三種情況都是由瀏覽器發出HTTP請求，最後一種情況則是由Javascript生成HTTP請求，也就是Ajax呼叫。還是根據呂瑞麟老師的文章，在這種情況下，IE和Firefox的處理方式完全不一樣。
舉例來說，有這樣兩行程式碼：
url = url + "?q=" +document.myform.elements[0].value; // 假定使用者在表單中提交的值是"春節"這兩個字
http_request.open('GET', url, true);
那麼，無論網頁使用什麼字符集，IE傳送給伺服器的總是"q=%B4%BA%BD%DA"，而Firefox傳送給伺服器的總是"q=%E6%98%A5%E8%8A%82"。也就是說，在Ajax呼叫中，IE總是採用GB2312編碼（作業系統的預設編碼），而Firefox總是採用utf-8編碼。這就是我們的結論4。
六、Javascript函式：escape()
好了，到此為止，四種情況都說完了。
假定前面你都看懂了，那麼此時你應該會感到很頭痛。因為，實在太混亂了。不同的作業系統、不同的瀏覽器、不同的網頁字符集，將導致完全不同的編碼結果。如果程式設計師要把每一種結果都考慮進去，是不是太恐怖了？有沒有辦法，能夠保證客戶端只用一種編碼方法向伺服器發出請求？
回答是有的，就是使用Javascript先對URL編碼，然後再向伺服器提交，不要給瀏覽器插手的機會。因為Javascript的輸出總是一致的，所以就保證了伺服器得到的資料是格式統一的。
Javascript語言用於編碼的函式，一共有三個，最古老的一個就是escape()。雖然這個函式現在已經不提倡使用了，但是由於歷史原因，很多地方還在使用它，所以有必要先從它講起。
實際上，escape()不能直接用於URL編碼，它的真正作用是返回一個字元的Unicode編碼值。比如"春節"的返回結果是%u6625%u8282，也就是說在Unicode字符集中，"春"是第6625個（十六進位制）字元，"節"是第8282個（十六進位制）字元。
它的具體規則是，除了ASCII字母、數字、標點符號"@ * _ + - . /"以外，對其他所有字元進行編碼。在\u0000到\u00ff之間的符號被轉成%xx的形式，其餘符號被轉成%uxxxx的形式。對應的解碼函式是unescape()。
所以，"Hello World"的escape()編碼就是"Hello%20World"。因為空格的Unicode值是20（十六進位制）。
還有兩個地方需要注意。
首先，無論網頁的原始編碼是什麼，一旦被Javascript編碼，就都變為unicode字元。也就是說，Javascipt函式的輸入和輸出，預設都是Unicode字元。
其次，escape()不對"+"編碼。但是我們知道，網頁在提交表單的時候，如果有空格，則會被轉化為+字元。伺服器處理資料的時候，會把+號處理成空格。所以，使用的時候要小心。
七、Javascript函式：encodeURI()
encodeURI()是Javascript中真正用來對URL編碼的函式。
它著眼於對整個URL進行編碼，因此除了常見的符號以外，對其他一些在網址中有特殊含義的符號"; / ? : @ & = + $ , #"，也不進行編碼。編碼後，它輸出符號的utf-8形式，並且在每個位元組前加上%。
它對應的解碼函式是decodeURI()。
需要注意的是，它不對單引號'編碼。
八、Javascript函式：encodeURIComponent()
最後一個Javascript編碼函式是encodeURIComponent()。與encodeURI()的區別是，它用於對URL的組成部分進行個別編碼，而不用於對整個URL進行編碼。
因此，"; / ? : @ & = + $ , #"，這些在encodeURI()中不被編碼的符號，在encodeURIComponent()中統統會被編碼。至於具體的編碼方法，兩者是一樣。
它對應的解碼函式是decodeURIComponent()。
encodeURI為什麼要用兩次
一般情況下, 傳送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
接收時, 直接 String paramValue = request.getParameter(paramName); // 容器自動解碼.
我們知道 encodeURIComponent 使用的是 UTF-8 編碼規則來編的.
如果 request.getParameter(paramName) 時,容器也按 UTF-8 解的話,是正確的. 根本無須在客戶端進行二次的 encodeURIComponent(...)
如果 request.getParameter(paramName),容器沒有按 UTF-8 解的話, 結果只有一個,就是亂碼!
容器按什麼編碼來解碼,決定於 request.setCharacterEncoding(***) 或者 伺服器程式配置.
如果你在 jsp 程式中,能夠 request.setCharacterEncoding("UTF-8"), 並且 修改伺服器配置,讓容器在解 GET 提交的引數時,使用 UTF-8.
客戶端提交前不用二次編碼, 接收時,也只要直接 request.getParameter(paramName) 即可
為什麼網上會有人提出在客戶端對字串重複編碼兩次呢.
如果因為專案需要,不能指定容器使用何種編碼規則來解碼提交的引數, 比如:需要接收來自不同頁面，不地編碼的引數內容時。 (又或者是開發人員被這有點複雜的東東搞得暈頭轉向，不懂得如何正確的去做好這接收引數的工作)
這個時候，在客戶端對引數進行二次編碼，可以有效的避開"提交多位元組字元"的這個棘手問題。
因為第一次編碼，你的引數內容便不帶有多位元組字元了，成了純粹的 Ascii 字串。(這裡把編第一次的結果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多位元組字元的)
再編一次後，提交，接收時容器自動解一次（容器自動解的這一次，不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好，都能夠正確的得到 [STR_ENC1]）
然後，再在程式中實現一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的引數的原值。
下面就讓我們看看，"URL編碼"到底有多混亂。我會依次分析四種不同的情況，在每一種情況中，瀏覽器的URL編碼方法都不一樣。把它們的差異解釋清楚之後，我再說如何用Javascript找到一個統一的編碼方法
二、情況1：網址路徑中包含漢字
開啟IE（我用的是8.0版），輸入網址"http://zh.wikipedia.org/wiki/春節"。注意，"春節"這兩個字此時是網址路徑的一部分。
檢視HTTP請求的頭資訊，會發現IE實際查詢的網址是"http://zh.wikipedia.org/wiki/%E6%98%A5%E8%8A%82"。也就是說，IE自動將"春節"編碼成了"%E6%98%A5%E8%8A%82"。我們知道，"春"和"節"的utf-8編碼分別是"E6 98 A5"和"E8 8A 82"，因此，"%E6%98%A5%E8%8A%82"就是按照順序，在每個位元組前加上%而得到的。在Firefox中測試，也得到了同樣的結果。
所以，結論1就是網址路徑的編碼，用的是utf-8編碼。
三、情況2：查詢字串包含漢字
在IE中輸入網址"http://www.baidu.com/s?wd=春節"。注意，"春節"這兩個字此時屬於查詢字串，不屬於網址路徑，不要與情況1混淆。
檢視HTTP請求的頭資訊，會發現IE將"春節"轉化成了一個亂碼。
切換到十六進位制方式，才能清楚地看到，"春節"被轉成了"B4 BA BD DA"。我們知道，"春"和"節"的GB2312編碼（我的作業系統"Windows XP"中文版的預設編碼）分別是"B4 BA"和"BD DA"。因此，IE實際上就是將查詢字串，以GB2312編碼的格式傳送出去。
Firefox的處理方法，略有不同。它傳送的HTTP Head是"wd=%B4%BA%BD%DA"。也就是說，同樣採用GB2312編碼，但是在每個位元組前加上了%。
所以，結論2就是，查詢字串的編碼，用的是作業系統的預設編碼。
四、情況3：Get方法生成的URL包含漢字
前面說的是直接輸入網址的情況，但是更常見的情況是，在已開啟的網頁上，直接用Get或Post方法發出HTTP請求。
根據臺灣中興大學呂瑞麟老師的試驗，這時的編碼方法由網頁的編碼決定，也就是由HTML原始碼中字符集的設定決定。
<meta http-equiv="Content-Type" content="text/html;charset=xxxx">
如果上面這一行最後的charset是UTF-8，則URL就以UTF-8編碼；如果是GB2312，URL就以GB2312編碼。
舉例來說，百度是GB2312編碼，Google是UTF-8編碼。因此，從它們的搜尋框中搜索同一個詞"春節"，生成的查詢字串是不一樣的。
百度生成的是%B4%BA%BD%DA，這是GB2312編碼。
Google生成的是%E6%98%A5%E8%8A%82，這是UTF-8編碼。
結論3就是，GET和POST方法的編碼，用的是網頁的編碼
五、情況4：Ajax呼叫的URL包含漢字
前面三種情況都是由瀏覽器發出HTTP請求，最後一種情況則是由Javascript生成HTTP請求，也就是Ajax呼叫。還是根據呂瑞麟老師的文章，在這種情況下，IE和Firefox的處理方式完全不一樣。
舉例來說，有這樣兩行程式碼：
url = url + "?q=" +document.myform.elements[0].value; // 假定使用者在表單中提交的值是"春節"這兩個字
http_request.open('GET', url, true);
那麼，無論網頁使用什麼字符集，IE傳送給伺服器的總是"q=%B4%BA%BD%DA"，而Firefox傳送給伺服器的總是"q=%E6%98%A5%E8%8A%82"。也就是說，在Ajax呼叫中，IE總是採用GB2312編碼（作業系統的預設編碼），而Firefox總是採用utf-8編碼。這就是我們的結論4。
六、Javascript函式：escape()
好了，到此為止，四種情況都說完了。
假定前面你都看懂了，那麼此時你應該會感到很頭痛。因為，實在太混亂了。不同的作業系統、不同的瀏覽器、不同的網頁字符集，將導致完全不同的編碼結果。如果程式設計師要把每一種結果都考慮進去，是不是太恐怖了？有沒有辦法，能夠保證客戶端只用一種編碼方法向伺服器發出請求？
回答是有的，就是使用Javascript先對URL編碼，然後再向伺服器提交，不要給瀏覽器插手的機會。因為Javascript的輸出總是一致的，所以就保證了伺服器得到的資料是格式統一的。
Javascript語言用於編碼的函式，一共有三個，最古老的一個就是escape()。雖然這個函式現在已經不提倡使用了，但是由於歷史原因，很多地方還在使用它，所以有必要先從它講起。
實際上，escape()不能直接用於URL編碼，它的真正作用是返回一個字元的Unicode編碼值。比如"春節"的返回結果是%u6625%u8282，也就是說在Unicode字符集中，"春"是第6625個（十六進位制）字元，"節"是第8282個（十六進位制）字元。
它的具體規則是，除了ASCII字母、數字、標點符號"@ * _ + - . /"以外，對其他所有字元進行編碼。在\u0000到\u00ff之間的符號被轉成%xx的形式，其餘符號被轉成%uxxxx的形式。對應的解碼函式是unescape()。
所以，"Hello World"的escape()編碼就是"Hello%20World"。因為空格的Unicode值是20（十六進位制）。
還有兩個地方需要注意。
首先，無論網頁的原始編碼是什麼，一旦被Javascript編碼，就都變為unicode字元。也就是說，Javascipt函式的輸入和輸出，預設都是Unicode字元。
其次，escape()不對"+"編碼。但是我們知道，網頁在提交表單的時候，如果有空格，則會被轉化為+字元。伺服器處理資料的時候，會把+號處理成空格。所以，使用的時候要小心。
七、Javascript函式：encodeURI()
encodeURI()是Javascript中真正用來對URL編碼的函式。
它著眼於對整個URL進行編碼，因此除了常見的符號以外，對其他一些在網址中有特殊含義的符號"; / ? : @ & = + $ , #"，也不進行編碼。編碼後，它輸出符號的utf-8形式，並且在每個位元組前加上%。
它對應的解碼函式是decodeURI()。
需要注意的是，它不對單引號'編碼。
八、Javascript函式：encodeURIComponent()
最後一個Javascript編碼函式是encodeURIComponent()。與encodeURI()的區別是，它用於對URL的組成部分進行個別編碼，而不用於對整個URL進行編碼。
因此，"; / ? : @ & = + $ , #"，這些在encodeURI()中不被編碼的符號，在encodeURIComponent()中統統會被編碼。至於具體的編碼方法，兩者是一樣。
它對應的解碼函式是decodeURIComponent()。
encodeURI為什麼要用兩次
一般情況下, 傳送 encodeURIComponent(parmeName)+"="+encodeURIComponent(parmeValue);
接收時, 直接 String paramValue = request.getParameter(paramName); // 容器自動解碼.
我們知道 encodeURIComponent 使用的是 UTF-8 編碼規則來編的.
如果 request.getParameter(paramName) 時,容器也按 UTF-8 解的話,是正確的. 根本無須在客戶端進行二次的 encodeURIComponent(...)
如果 request.getParameter(paramName),容器沒有按 UTF-8 解的話, 結果只有一個,就是亂碼!
容器按什麼編碼來解碼,決定於 request.setCharacterEncoding(***) 或者 伺服器程式配置.
如果你在 jsp 程式中,能夠 request.setCharacterEncoding("UTF-8"), 並且 修改伺服器配置,讓容器在解 GET 提交的引數時,使用 UTF-8.
客戶端提交前不用二次編碼, 接收時,也只要直接 request.getParameter(paramName) 即可
為什麼網上會有人提出在客戶端對字串重複編碼兩次呢.
如果因為專案需要,不能指定容器使用何種編碼規則來解碼提交的引數, 比如:需要接收來自不同頁面，不地編碼的引數內容時。 (又或者是開發人員被這有點複雜的東東搞得暈頭轉向，不懂得如何正確的去做好這接收引數的工作)
這個時候，在客戶端對引數進行二次編碼，可以有效的避開"提交多位元組字元"的這個棘手問題。
因為第一次編碼，你的引數內容便不帶有多位元組字元了，成了純粹的 Ascii 字串。(這裡把編第一次的結果叫成 [STR_ENC1] 好了。[STR_ENC1] 是不帶有多位元組字元的)
再編一次後，提交，接收時容器自動解一次（容器自動解的這一次，不管是按 GBK 還是 UTF-8 還是 ISO-8859-1 都好，都能夠正確的得到 [STR_ENC1]）
然後，再在程式中實現一次 decodeURIComponent (Java中通常使用 java.net.URLDecoder(***, "UTF-8")) 就可以得到想提交的引數的原值。