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