首頁»JavaScript»URL編碼與解碼

                    URL編碼與解碼

                    來源:Web開發者 發布時間:2012-05-27 閱讀次數:

                    通常如果一樣東西需要編碼,說明這樣東西并不適合傳輸。原因多種多樣,如Size過大,包含隱私數據,對于Url來說,之所以要進行編碼,是因為Url中有些字符會引起歧義。

                      例如,Url參數字符串中使用key=value鍵值對這樣的形式來傳參,鍵值對之間以&符號分隔,如/s?q=abc&ie=utf-8。如果你的value字符串中包含了=或者&,那么勢必會造成接收Url的服務器解析錯誤,因此必須將引起歧義的&和=符號進行轉義,也就是對其進行編碼。

                      又如,Url的編碼格式采用的是ASCII碼,而不是Unicode,這也就是說你不能在Url中包含任何非ASCII字符,例如中文。否則如果客戶端瀏覽器和服務端瀏覽器支持的字符集不同的情況下,中文可能會造成問題。

                    Url編碼的原則就是使用安全的字符(沒有特殊用途或者特殊意義的可打印字符)去表示那些不安全的字符。

                      預備知識:URI是統一資源標識的意思,通常我們所說的URL只是URI的一種。典型URL的格式如下所示。下面提到的URL編碼,實際上應該指的是URI編碼。

                    foo://example.com:8042/over/there?name=ferret#nose

                       \_/ \______________/ \________/\_________/ \__/

                        |         |              |         |        |

                      scheme     authority                path      query   fragment

                      哪些字符需要編碼

                      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。

                      對于非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函數是從Javascript 1.0的時候就存在了,其他兩個函數是在Javascript 1.5才引入的。但是由于Javascript 1.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。

                      之前在使用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的處理問題,不同瀏覽器有不同的表現。例如對于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編碼方法比較

                    QQ群:WEB開發者官方群(515171538),驗證消息:10000
                    微信群:加小編微信 849023636 邀請您加入,驗證消息:10000
                    提示:更多精彩內容關注微信公眾號:全棧開發者中心(fsder-com)
                    網友評論(共0條評論) 正在載入評論......
                    理智評論文明上網,拒絕惡意謾罵 發表評論 / 共0條評論
                    登錄會員中心
                    福彩试机号今天 e时代娱乐平台 快乐双彩如何中奖 澳洲幸运10开奖软件app 26选5中奖几个 大乐透大星走势图 快乐双彩玩法说明 山西快乐十分开奖结果查询 山东群英会综合走势图 七乐彩2019061 体彩p5走势图带连线 香港721元朗事件 幸运农场遗漏 百人牛牛 无广告印刷六合图库 一肖中特公开验证