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编解码和数据库存储时所要做的转换，避免了编码信息长度在此过程当中的增长，并统一了数据库、表单等处对象 标识符的格式。