URI所容許的字符分做保留與未保留。保留字符是那些具備特殊含義的字符. 例如, 斜線字符用於URL (或者更通常的, URI)不一樣部分的分界符. 未保留字符沒有這些特殊含義. 百分號編碼把保留字符表示爲特殊字符序列。上述情形隨URI與URI的不一樣版本規格會有輕微的變化。php
! |
* |
' |
( |
) |
; |
: |
@ |
& |
= |
+ |
$ |
, |
/ |
? |
# |
[ |
] |
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中的其它字符必須用百分號編碼。html
若是一個保留字符在特定上下文中具備特殊含義(稱做"reserved purpose") , 且URI中必須使用該字符用於其它目的, 那麼該字符必須百分號編碼. 百分號編碼一個保留字符,首先須要把該字符的ASCII的值表示爲兩個16進制的數字,而後在其前面放置轉義字符("%
"),置入URI中的相應位置。(對於非ASCII字符, 須要轉換爲UTF-8字節序, 而後每一個字節按照上述方式表示.)web
例如,"/
", 若是用做URI的路徑成份的分界符, 則是具備特殊含義的保留字符. 若是該字符須要出如今URI一個路徑成分的內部, 則三字符序列"%2F
"或"%2f
"就用於代替本來的"/
"出如今該URI路徑成分的內部.服務器
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
] |
%21 |
%23 |
%24 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D |
在特定上下文中沒有特殊含義的保留字符也能夠被百分號編碼,在語義上與不百分號編碼的該字符沒有差異.app
在URI的"查詢"成分(?字符後的部分)中, 例如"/
"仍然是保留字符可是沒有特殊含義,除非一個特定的URI有其它規定. 該/
字符在沒有特殊含義時不須要百分號編碼.ide
若是保留字符具備特殊含義,那麼該保留字符用百分號編碼的URI與該保留字符僅用其自身表示的URI具備不一樣的語義。函數
未保留字符不須要百分號編碼.post
兩個URI的差異若是僅是未保留字符是用百分號編碼仍是用字符自身表示,那麼這兩個URI具備等價的語義. 但URI處理器實際上並不老是把兩者視做等價. 例如, URI的消費者不該該把"%41
"與"A
", "%7E
"與"~
"視做不一樣, 可是某些URI的消費者就是這麼作了. 爲了最大的互操做性, URI的製造者不該該把未保留字符百分號編碼。編碼
因爲百分號字符("%")表示百分號編碼字節流的存在, 所以百分號字符應該被編碼爲3個字節的序列:"%25",用於URI內部。url
大多數URI涉及表示任意數據, 例如IP地址或文件系統路徑做爲URI的成分。
1994年發佈的RFC 1738規定[1], URI中的二進制數據應該表示爲8位元組的序列,而後對每一個8位元組按照上述方式百分號編碼. 例如,字節值0F (十六進制)應表示爲"%0F
", 字節值41(十六進制)應表示爲"A
"或"%41
". 優先使用未保留字符來表示這些字節值,由於這使得URL更短.
二進數據的百分號編碼過程已經被外推到字符數據,甚至到不適合或未被徹底規範的地步. 在WWW初創階段,僅僅處理ASCII字符是否編碼問題,尚未什麼問題。但隨後發展到對非ASCII字符如何在URI中編碼,缺乏標準規範的狀況下致使了歧義性的解釋URI的錯誤。
例如, 基於RFC 1738與2396的協議規定,字符數據先要根據某種字符編碼轉換爲字節流,而後再表示爲URI。若是URI不提供是何種字符編碼的提示信息,那麼這個URI難以可靠的解析。
2005年1月發佈的RFC 3986,強制全部新的URI必須對未保留字符不加以百分號編碼;其它字符要先轉換爲UTF-8字節序列, 而後對其字節值使用百分號編碼。此前的URI不受此標準的影響。
T有一些不符合標準的把Unicode字符在URI中表示爲: %uxxxx
, 其中xxxx是用4個十六進制數字表示的Unicode的碼位值。任何RFC都沒有這樣的字符表示方法,而且已經被W3C拒絕。第三版的ECMA-262仍然包含函數escape(string)
使用這種語法, 但也有函數encodeURI(uri)
轉換字符到UTF-8字節序列並用百分號編碼每一個字節。
當HTML表單中的數據被提交時,表單的域名與值被編碼並經過HTTP的GET或者POST方法甚至更古遠的email[2]把請求發送給服務器。這裏的編碼方法採用了一個很是早期的通用的URI百分號編碼方法,而且有不少小的修改如新行規範化以及把空格符的編碼"%20
"替換爲"+
" . 按這套方法編碼的數據的MIME類型是application/x-www-form-urlencoded
, 當前仍用於(雖然很是過期了)HTML與XForms規範中. 此外,CGI規範包括了web服務器如何解碼這類數據、利用這類數據的內容。
若是發送的是HTTP GET請求, application/x-www-form-urlencoded數據包含在所請求URI的查詢成分中. 若是發送的是HTTP POST請求或經過email, 數據被放置在消息體中,媒體類型的名字被包含在消息的Content-Type頭內部。