url、base64 編碼規則

UrlEncode 相關：

　　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

-

_

.

~

保留字符：

　　若是一個保留字符在特定上下文中具備特殊含義(稱做"reserved purpose") , 且URI中必須使用該字符用於其它目的, 那麼該字符必須百分號編碼。百分號編碼一個保留字符，首先須要把該字符的ASCII的值表示爲兩個16進制的數字，而後在其前面放置轉義字符("%")，置入URI中的相應位置。(對於非ASCII字符, 須要轉換爲UTF-8字節序, 而後每一個字節按照上述方式表示。)

非保留字符：

　　未保留字符不須要百分號編碼。兩個URI的差異若是僅是未保留字符是用百分號編碼仍是用字符自身表示，那麼這兩個URI具備等價的語義。但URI處理器實際上並不老是把兩者視做等價。 例如, URI的消費者不該該把"A"與"A", "~"與"~"視做不一樣, 可是某些URI的消費者就是這麼作了。 爲了最大的互操做性, URI的製造者不該該把未保留字符百分號編碼。

當前標準：

　　2005年1月發佈的RFC 3986，強制全部新的URI必須對未保留字符不加以百分號編碼；其它字符要先轉換爲UTF-8字節序列, 而後對其字節值使用百分號編碼。此前的URI不受此標準的影響。

application/x-www-form-urlencoded類型：

　　當HTML表單中的數據被提交時，表單的域名與值被編碼並經過HTTP的GET或者POST方法甚至更古遠的email^[2]把請求發送給服務器。這裏的編碼方法採用了一個很是早期的通用的URI百分號編碼方法，而且有不少小的修改如新行規範化以及把空格符的編碼" "替換爲"+" 。 按這套方法編碼的數據的MIME類型是application/x-www-form-urlencoded, 當前仍用於（雖然很是過期了）HTML與XForms規範中. 此外，CGI規範包括了web服務器如何解碼這類數據、利用這類數據的內容。若是發送的是HTTP GET請求, application/x-www-form-urlencoded數據包含在所請求URI的查詢成分中. 若是發送的是HTTP POST請求或經過email, 數據被放置在消息體中，媒體類型的名字被包含在消息的Content-Type頭內部。

 

Base64 編碼：

轉碼範例：

　　3*8=4*6

　　內存1個字符佔8位

　　轉前： s 1 3

　　先轉成ascii：對應 115 49 51

　　2進制： 01110011 00110001 00110011

　　6個一組（4組） 011100110011000100110011

　　而後纔有後面的 011100 110011 000100 110011

　　而後計算機是8位8位的存數 6不夠，自動就補兩個高位0了

　　全部有了 高位補0

　　科學計算器輸入 00011100 00110011 00000100 00110011

　　獲得 28 51 4 51

　　查對下照表 c z E z

 

　　標準的Base64並不適合直接放在URL裏傳輸，由於URL編碼器會把標準Base64中的「/」和「+」字符變爲形如「%XX」的形式，而這些「%」號在存入數據庫時還須要再進行轉換，由於ANSI SQL中已將「%」號用做 通配符。

爲解決此問題，可採用一種用於URL的改進Base64編碼，它在末尾填充'='號，並將標準Base64中的「+」和「/」分別改爲了「-」和「_」，這樣就免去了在URL編解碼和數據庫存儲時所要做的轉換，避免了編碼信息長度在此過程當中的增長，並統一了數據庫、表單等處對象 標識符的格式。