URL編碼知識摘抄備忘

標籤：style   blog   http   io   ar   使用   sp   for   strong   

網頁工具 http://www.107000.com/T-UrlEncode/

參考：

維基百科http://zh.wikipedia.org/zh/%E7%99%BE%E5%88%86%E5%8F%B7%E7%BC%96%E7%A0%81

百度百科 http://baike.baidu.com/view/204662.htm

部落格園某篇部落格 http://kb.cnblogs.com/page/133765/

 

 概述

百分比符號編碼(Percent-encoding), 也稱作URL編碼(URL encoding), 是特定內容相關的統一資源定位器 (URL)的編碼機制. 實際上也適用於統一資源標誌符(URI)的編碼。也用於為"application/x-www-form-urlencoded" MIME準備資料, 因為它用於通過HTTP的請求操作(request)提交HTML表單資料。

 

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

URI所允許的字元分作保留與未保留。保留字元是那些具有特殊含義的字元. 例如, 斜線字元用於URL (或者更一般的, URI)不同部分的分界符. 未保留字元沒有這些特殊含義. 百分比符號編碼把保留字元表示為特殊字元序列。上述情形隨URI與URI的不同版本規格會有輕微的變化。

URI所允許的字元分作保留與未保留。保留字元是那些具有特殊含義的字元. 例如, 斜線字元用於URL (或者更一般的, URI)不同部分的分界符. 未保留字元沒有這些特殊含義. 百分比符號編碼把保留字元表示為特殊字元序列。上述情形隨URI與URI的不同版本規格會有輕微的變化。

RFC 3986 section 2.2 保留字元 (2005年1月)

!

*

‘

(

)

;

:

@

&

=

+

$

,

/

?

#

[

]

RFC 3986 section 2.3 未保留字元 (2005年1月)

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

U

V

W

X

Y

Z

a

b

c

d

e

f

g

h

i

j

k

l

m

n

o

p

q

r

s

t

u

v

w

x

y

z

0

1

2

3

4

5

6

7

8

9

-

_

.

~

URI中的其它字元必須用百分比符號編碼。URI中的其它字元必須用百分比符號編碼。

Url編碼的原則就是使用安全的字元（沒有特殊用途或者特殊意義的可列印字元）去表示那些不安全的字元。

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

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

 

參考

ASCII 維基百科 http://zh.wikipedia.org/zh-cn/ASCII

ASCII 百度百科 http://baike.baidu.com/view/15482.htm

Unicode 維基百科 http://zh.wikipedia.org/zh-cn/Unicode

Unicode 百度百科 http://baike.baidu.com/view/40801.htm

UTF-8 維基百科 http://zh.wikipedia.org/zh-cn/UTF-8

UTF-8 百度百科 http://baike.baidu.com/view/25412.htm

 

哪些字元需要編碼   

　　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。

　　對於非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編碼實現並不完全遵循這樣的原則。

參見 部落格園某篇部落格 http://kb.cnblogs.com/page/133765/

 

<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>> 

註：我在使用 http://www.107000.com/T-Utf8/ 工具時，發現一個漢字被轉換為兩位元組（4個十六進位數），而不是三位元組。經過記事本實際儲存，HxD工具驗證，實際上這些網頁轉換為了

例如，＂中文＂兩字：（加刪除線的是檔案資訊頭，參考 File Signatures Table http://www.garykessler.net/library/file_sigs.html ）

網頁工具：　&#x4E2D;&#x6587;

記事本UTF-8：EF BB BF E4 B8 AD E6 96 87

記事本Unicode： FF FE 2D 4E 87 65

記事本 Unicode Big Endian： FE FF 4E 2D 65 87

實際Url編碼：%E4%B8%AD%E6%96%87

可見網頁工具採用的是 Unicode Big Endian。實際的Url編碼採用UTF-8。

 

關於Little Endian和Big Endian，參考以前的部落格文：

儲存資料時，一個地址儲存一位元組。如果一個資料需要用多個位元組表示，就要跨地址，那麼儲存該資料的順序就分為兩種：高地址儲存高位元據，低地址儲存低位元據（小端方式，Little Endian，利於電腦處理）；高地址儲存低位元據，低地址儲存高位元據（大端方式，Big Endian，和人類一般思維類似）。BMP檔案採用小端方式，高地址儲存高位元據，低地址儲存低位元據。甩兩個連結：

http://blog.csdn.net/hackbuteer1/article/details/7722667

http://www.cnblogs.com/TsuiLei/archive/2008/10/29/1322504.html

<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>> 

 

 

附: 統一資源標誌符URI，與URL、URN

http://zh.wikipedia.org/wiki/%E7%BB%9F%E4%B8%80%E8%B5%84%E6%BA%90%E6%A0%87%E5%BF%97%E7%AC%A6

在電腦術語中，統一資源識別項（Uniform Resource Identifier，或URI)是一個用於標識某一互連網資源名稱的字串。 該種標識允許使用者對網路中（一般指全球資訊網）的資源通過特定的協議進行互動操作。URI由包括確定文法和相關協議的方案所定義。

與URL和URN的關係

右圖：URL方案分類圖

URL(定位器)和URN(名稱)方案屬於URI的子類，URI可以為URL或URN兩者之一或同時是URI和URN。技術上講，URL和URN屬於資源ID；但是，人們往往無法將某種方案歸類於兩者中的某一個：所有的URI都可被作為名稱看待，而某些方案同時體現了兩者中的不同部分。

URI可被視為定位器（URL），名稱（URN）或兩者兼備。統一資源名（URN）如同一個人的名稱，而統一資源定位器（URL）代表一個人的住址。換言之，URN定義某事物的身份，而URL提供尋找該事物的方法。

URL編碼知識摘抄備忘