url傳值特殊字元編碼
為什麼需要Url編碼
通常如果一樣東西需要編碼，說明這樣東西並不適合傳輸。原因多種多樣，如Size過大，包含隱私資料，對於Url來說，之所以要進行編碼，是因為Url中有些字元會引起歧義。
Url編碼的原則就是使用安全的字元（沒有特殊用途或者特殊意義的可列印字元）去表示那些不安全的字元。
哪些字元需要編碼
RFC3986文件規定，Url中只允許包含英文字母（a-zA-Z）、數字（0-9）、-_.~4個特殊字元以及所有保留字元。
RFC3986文件對Url的編解碼問題做出了詳細的建議，指出了哪些字元需要被編碼才不會引起Url語義的轉變，以及對為什麼這些字元需要編碼做出了相應的解釋。
US-ASCII字符集中沒有對應的可列印字元
Url中只允許使用可列印字元。US-ASCII碼中的10-7F位元組全都表示控制字元，這些字元都不能直接出現在Url中。同時，對於80-FF位元組（ISO-8859-1），由於已經超出了US-ACII定義的位元組範圍，因此也不可以放在Url中。
保留字元
Url可以劃分成若干個元件，協議、主機、路徑等。有一些字元（:/?#[]@）是用作分隔不同元件的。例如:冒號用於分隔協議和主機，/用於分隔 主機和路徑，?用於分隔路徑和查詢引數，等等。還有一些字元（!$&'()*+,;=）用於在每個元件中起到分隔作用的，如=用於表示查詢引數中 的鍵值對，&符號用於分隔查詢多個鍵值對。當元件中的普通資料包含這些特殊字元時，需要對其進行編碼。
RFC3986中指定了以下字元為保留字元：
| ! | * | ' | ( | ) | ; | : | @ | & | = | + | $ | , | / | ? | # | [ | ] |
不安全字元
還有一些字元，當他們直接放在Url中的時候，可能會引起解析程式的歧義。這些字元被視為不安全字元，原因有很多。
| 空格 | Url在傳輸的過程，或者使用者在排版的過程，或者文字處理程式在處理Url的過程，都有可能引入無關緊要的空格，或者將那些有意義的空格給去掉 |
| 引號以及<> | 引號和尖括號通常用於在普通文字中起到分隔Url的作用 |
| # | 通常用於表示書籤或者錨點 |
| % | 百分號本身用作對不安全字元進行編碼時使用的特殊字元，因此本身需要編碼 |
| {}|\^[]`~ | 某一些閘道器或者傳輸代理會篡改這些字元 |
需要注意的是，對於Url中的合法字元，編碼和不編碼是等價的，但是對於上面提到的 這些字元，如果不經過編碼，那麼它們有可能會造成Url語義的不同。因此對於Url而言，只有普通英文字元和數字，特殊字元$-_.+!*'()還有保留 字元，才能出現在未經編碼的Url之中。其他字元均需要經過編碼之後才能出現在Url中。
但是由於歷史原因，目前尚存在一些不標準的編碼實現。例如對於~符號，雖然RFC3986文件規定，對於波浪符號~，不需要進行Url編碼，但是還是有很多老的閘道器或者傳輸代理會
如何對Url中的非法字元進行編碼
Url編碼通常也被稱為百分號編碼（Url Encoding，also known as percent-encoding），是因為它的編碼方式非常簡單，使用%百分號加上兩位的字元——0123456789ABCDEF——代表一個位元組的 十六進位制形式。Url編碼預設使用的字符集是US-ASCII。例如a在US-ASCII碼中對應的位元組是0x61，那麼Url編碼之後得到的就 是%61，我們在位址列上輸入http://g.cn/search?q=%61%62%63，實際上就等同於在google上搜索abc了。又如@符號 在ASCII字符集中對應的位元組為0x40，經過Url編碼之後得到的是%40。
常見字元的Url編碼列表：
| ! | * | " | ' | ( | ) | ; | : | @ | & |
%21 |
%2A |
%22 |
%27 |
%28 |
%29 |
%3B |
%3A |
%40 |
%26 |
| = | + | $ | , | / | ? | % | # | [ | ] |
%3D |
%2B |
%24 |
%2C |
%2F |
%3F |
%25 |
%23 |
%5B |
%5D |
對於非ASCII字元，需要使用ASCII字符集的超集進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。 對於Unicode字元，RFC文件建議使用utf-8對其進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。如“中文”使用UTF-8字符集得到 的位元組為0xE4 0xB8 0xAD 0xE6 0x96 0x87，經過Url編碼之後得到“%E4%B8%AD%E6%96%87”。
如果某個位元組對應著ASCII字符集中的某個非保留字元，則此位元組無需使用百分號表示。 例如“Url編碼”，使用UTF-8編碼得到的位元組是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81，由於前三個位元組對應著ASCII中的非保留字元“Url”，因此這三個位元組可以用非保留字元“Url”表示。最終的Url編碼可以簡化成 “Url%E7%BC%96%E7%A0%81” ，當然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。
由於歷史的原因，有一些Url編碼實現並不完全遵循這樣的原則，下面會提到。
Javascript中的escape,encodeURI和encodeURIComponent的區別
Javascript中提供了3對函式用來對Url編碼以得到合法的Url，它們分別是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由於解碼和編碼的過程是可逆的，因此這裡只解釋編碼的過程。
這三個編碼的函式——escape，encodeURI，encodeURIComponent——都是用於將不安全不合法的Url字元轉換為合法的Url字元表示，它們有以下幾個不同點。
安全字元不同
下面的表格列出了這三個函式的安全字元（即函式不會對這些字元進行編碼）
| 安全字元 | |
| escape（69個） | */@+-._0-9a-zA-Z |
| encodeURI（82個） | !#$&'()*+,/:;[email protected]_~0-9a-zA-Z |
| encodeURIComponent（71個） | !'()*-._~0-9a-zA-Z |
相容性不同
escape函式是從Javascript1.0的時候就存在了，其他兩個函式是在Javascript1.5才引入的。但是由於 Javascript1.5已經非常普及了，所以實際上使用encodeURI和encodeURIComponent並不會有什麼相容性問題。
對Unicode字元的編碼方式不同
這三個函式對於ASCII字元的編碼方式相同，均是使用百分號+兩位十六進位制字元來表示。但是對於Unicode字元，escape的編碼方式是%uxxxx，其中的xxxx是用來表示unicode字元的4位十六進位制字元。這種方式已經被W3C廢棄了。但是在ECMA-262標準中仍然保留著escape的這種編碼語法。encodeURI和encodeURIComponent則使用UTF-8對非ASCII字元進行編碼，然後再進行百分號編碼。這是RFC推薦的。因此建議儘可能的使用這兩個函式替代escape進行編碼。
適用場合不同
encodeURI被用作對一個完整的URI進行編碼，而encodeURIComponent被用作對URI的一個元件進行編碼。
從上面提到的安全字元範圍表格來看，我們會發現，encodeURIComponent編碼的字元範圍要比encodeURI的大。我們上面提到 過，保留字元一般是用來分隔URI元件（一個URI可以被切割成多個元件，參考預備知識一節）或者子元件（如URI中查詢引數的分隔符），如:號用於分隔 scheme和主機，?號用於分隔主機和路徑。由於encodeURI操縱的物件是一個完整的的URI，這些字元在URI中本來就有特殊用途，因此這些保 留字元不會被encodeURI編碼，否則意義就變了。
元件內部有自己的資料表示格式，但是這些資料內部不能包含有分隔元件的保留字元，否則就會導致整個URI中元件的分隔混亂。因此對於單個元件使用encodeURIComponent，需要編碼的字元就更多了。
表單提交
當Html的表單被提交時，每個表單域都會被Url編碼之後才在被髮送。由於歷史的原因，表單使用的Url編碼實現並不符合最新的標準。例如對於空 格使用的編碼並不是%20，而是+號，如果表單使用的是Post方法提交的，我們可以在HTTP頭中看到有一個Content-Type的header， 值為application/x-www-form-urlencoded。大部分應用程式均能處理這種非標準實現的Url編碼，但是在客戶端 Javascript中，並沒有一個函式能夠將+號解碼成空格，只能自己寫轉換函式。還有，對於非ASCII字元，使用的編碼字符集取決於當前文件使用的 字符集。例如我們在Html頭部加上
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
這樣瀏覽器就會使用gb2312去渲染此文件（注意，當HTML文件中沒有設定此meta標籤，則瀏覽器會根據當前使用者喜好去自動選擇字符集，使用者也可以強制當前網站使用某個指定的字符集）。當提交表單時，Url編碼使用的字符集就是gb2312。
文件字符集會影響encodeURI嗎？
之前在使用Aptana（為什麼專指aptana下面會提到）遇到一個很迷惑的問題，就是在使用encodeURI的時候，發現它編碼得到的結果和我想的很不一樣。下面是我的示例程式碼：
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=gb2312" /> </head> <body> <script type="text/javascript"> document.write(encodeURI("中文")); </script> </body> </html>
執行結果輸出%E6%B6%93%EE%85%9F%E6%9E%83。顯然這並不是使用UTF-8字符集進行Url編碼得到的結果（在Google上搜索“中文”，Url中顯示的是%E4%B8%AD%E6%96%87）。
所以我當時就很質疑，難道encodeURI還跟頁面編碼有關，但是我發現，正常情況下，如果你使用gb2312進行Url編碼也不會得到這個結果的才是。後來終於被我發現，原來是頁面檔案儲存使用的字符集和Meta標籤中指定的字符集不一致導致的問題。 Aptana的編輯器預設情況下使用UTF-8字符集。也就是說這個檔案實際儲存的時候使用的是UTF-8字符集。但是由於Meta標籤中指定了 gb2312，這個時候，瀏覽器就會按照gb2312去解析這個文件，那麼自然在“中文”這個字串這裡就會出錯，因為“中文”字串用UTF-8編碼過 後得到的位元組是0xE4 0xB8 0xAD 0xE6 0x96 0x87，這6個位元組又被瀏覽器拿gb2312去解碼，那麼就會得到另外三個漢字“涓枃”（GBK中一個漢字佔兩個位元組），這三個漢字在傳入 encodeURI函式之後得到的結果就是%E6%B6%93%EE%85%9F%E6%9E%83。因此，encodeURI使用的還是UTF-8，並 不會受到頁面字符集的影響。
其他和Url編碼相關的問題
對於包含中文的Url的處理問題，不同瀏覽器有不同的表現。例如對於IE，如果你勾選了高階設定“總是以UTF-8傳送Url”，那麼Url中的路 徑部分的中文會使用UTF-8進行Url編碼之後傳送給服務端，而查詢引數中的中文部分使用系統預設字符集進行Url編碼。為了保證最大互操作性，建議所 有放到Url中的元件全部顯式指定某個字符集進行Url編碼，而不依賴於瀏覽器的預設實現。
另外，很多HTTP監視工具或者瀏覽器位址列等在顯示Url的時候會自動將Url進行一次解碼（使用UTF-8字符集），這就是為什麼當你在 Firefox中訪問Google搜尋中文的時候，位址列顯示的Url包含中文的緣故。但實際上傳送給服務端的原始Url還是經過編碼的。你可以在位址列 上使用Javascript訪問location.href就可以看出來了。在研究Url編解碼的時候千萬別被這些假象給迷惑了。
相關推薦
url傳值特殊字元編碼
為什麼需要Url編碼 通常如果一樣東西需要編碼，說明這樣東西並不適合傳輸。原因多種多樣，如Size過大，包含隱私資料，對於Url來說，之所以要進行編碼，是因為Url中有些字元會引起歧義。 Url編碼的原則就是使用安全的字元（沒有特殊用途或者特殊意義的可列印字元）去表
URL傳參特殊字元處理
十六進位制值1. + URL 中+號表示空格 %2B2. 空格 URL中的空格可以用+號或者編碼 %203. / 分隔目錄和子目錄 %2F4. ? 分隔實際的 URL 和引數 %3F5. % 指定特殊字元 %256. # 表示書籤 %237. & URL 中指定的引數
url傳參特殊字元問題
function edit(zcname,xmname){ var empcode='${empcode}'; zcname=encodeURIComponent(zcname); location.href = "toEditZclx.do?zcn
postman URL中含特殊字元傳參
URL出現了有+，空格，/，?，%，#，&，=等特殊符號的時候，可能在伺服器端無法獲得正確的引數值，此時需要對字元進行轉譯。 字元 - URL編碼值 空格 - %20 " - %22 # - %23 % - %25 & - %
JS 和 Java 中URL特殊字元編碼方式
JavaScript 1. 編碼 escape(String) 其中某些字元被替換成了十六進位制的轉義序列。 解碼 unescape(String) 該函式的工作原理是這樣的：通過找到形式為 %xx 和 %uxxxx 的字元序列（x
java 頁面url傳值中文編碼&解碼
URL引數中有中文值，傳到服務端，在用request.getParameter()方法，得到的常常會是亂碼。 這將涉及到字元解碼操作，我們在應用中常常會用new String(fieldType.getBytes("iso-8859-1"), "UTF-8");等類似的方法
Tomcat中URL對於特殊字元編碼問題
URL中有特殊字元如大括號{}，^等tomcat會返回400錯誤 java.lang.IllegalArgumentException: Invalid character found in the
js url傳值中文亂碼完美解決(JAVA)
div AR urldecode 更改 pos decode post 中文 解決亂碼 首先在你的jsp頁面這樣更改： var url="你要傳入的Action的位置&ipid="+ipid+"&keyWord="+key; 這裏的key是中文，從inp
通過url傳值的取值方法
bstr www. new cap escape arc str sea regex 當前：url=www.baidu.com?id=2 id = GetQueryString(id)//2 function GetQueryString(name) { var reg =
url 傳遞引數(特殊字元) 解決方法
在做網頁的時候，偶爾會遇到url被截斷的情況，一般是出現在有引數的url中，比如www.baidu.com?a=1&b=2,有時候就會出現url只傳遞了www.baidu.com?a=1後邊的url被截斷了，出現這種情況一般最有效的解決方案是把&符號用%26替換,這樣ww
HTML常用特殊字元編碼對照表以及其對應英文
符號 說明 對應編碼(使用時去掉空格) 英文 & AND 符號 & amp; ampersand < 小於 & lt; li
Html中擷取url引數 實現HTML間的url傳值
大家好： 今天遇到一個問題，頁面全是html，url傳值，竟然獲取不到引數值： A.html //登入按鈕 jQuery(function($) { $("#login").click(function() { $
url中的特殊字元問題
在 使用url進行引數傳遞時，經常會傳遞一些中文名（或含有特殊字元）的引數或URL地址，在後臺處理時會發生轉換錯誤。在有些傳遞頁面使用GB2312， 而在接收頁面使用UTF8，這樣接收到的引數就可能會與原來發生不一致。使用伺服器端的urlEncode函式編碼的URL，與使用客
java處理url中的特殊字元%等
java處理url中的特殊字元（如&,%...） URL(Uniform Resoure Locator，統一資源定位器)是Internet中對資源進行統一定位和管理的標誌。一個完整的URL包括如下內容：1. &
小程式url傳值
https://www.jianshu.com/p/0135769db89c 注 : 如果轉化的字串中 有"?"，"&"或"="等這樣的符號，則只會傳遞符號以前的字串，符號後面資料會被丟失，這個問題我猜想可能是小程式內部的路由處理 對這些符號敏感吧。所以有時候這裡可以先用 encodeU
URL中的特殊字元意思
在URL中，我們會遇到很多的特殊字元，不懂的新手可能不懂得是什麼意思，為此寫在此，希望對不懂的人有所幫助！ 符號 意思
javascript處理url中有特殊字元的情況如“{、#、}...”
JavaScript中有三個可以對字串編碼的函式， 分別是： escape(),encodeURI(),encodeURIComponent()， 相應3個解碼函式： unescape(),decodeURI(),decodeURIComponent() 。 下面
JAVA如何處理URL中的特殊字元
方法1： String str="http://www.baidu.com/api/?action=s2s_install&a={appsunion}&b=3&c=30029
thinkPHP a標籤URL傳值方式
<volist name="msg" id="msg"> <tr> <td class="dindh" height="140"> <p><a href="{:U('Terrace
URL中的特殊字元問題escape,encodeURI,encodeURIComponent
在使用url進行引數傳遞時，經常會傳遞一些中文名（或含有特殊字元）的引數或URL地址，在後臺處理時會發生轉換錯誤。在有些傳遞頁面使用GB2312，而在接收頁面使用UTF8，這樣接收到的引數就可能會與原來發生不一致。使用伺服器端的urlEncode函式編碼的URL，與使用客戶端javascript的e