詳解Javascript中的Url編碼/解碼

來源:互聯網
上載者:User
文章目錄
  • US-ASCII字元集中沒有對應的可列印字元
  • 保留字元
  • Unsafe 字元
  • 安全字元不同
  • 相容性不同
  • 對Unicode字元的編碼方式不同
  • 適用場合不同
摘要

本文主要針對URI編解碼的相關問題做了介紹,對Url編碼中哪些字元需要編碼、為什麼需要編碼做了詳細的說明,並對比分析了Javascript中和編解碼相關的幾對函數escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。

預備知識

   foo://example.com:8042/over/there?name=ferret#nose 
   \_/  \______________/ \________/\_________/ \__/
     |                 |                        |                    |             |
scheme     authority               path             query      fragment

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

為什麼需要Url編碼

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

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

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

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中指定了以下字元為保留字元:

! * ' ( ) ; : @ & = + $ , / ? # [ ]
Unsafe 字元

還有一些字元,當他們直接放在Url中的時候,可能會引起解析程式的歧義。這些字元被視為Unsafe 字元,原因有很多。

空格 Url在傳輸的過程,或者使用者在排版的過程,或者文本處理常式在處理Url的過程,都有可能引入無關緊要的空格,或者將那些有意義的空格給去掉
引號以及<> 引號和角括弧通常用於在普通文本中起到分隔Url的作用
# 通常用於表示書籤或者錨點
% 百分比符號本身用作對Unsafe 字元進行編碼時使用的特殊字元,因此本身需要編碼
{}|\^[]`~ 某一些網關或者傳輸代理會篡改這些字元

 

需要注意的是,對於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編碼列表:

保留字元的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個) !#$&'()*+,/:;=?@-._~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編解碼的時候千萬別被這些假象給迷惑了。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.