首页 > 代码库 > url、base64 编码规则

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

  

url、base64 编码规则