Base64和URL编码

URL为什么使用百分号编码(URL编码)

1、一些数据（二进制串）无法在URL中使用字符表示（以US-ASCII字符集举例，其中的一些 字符 并不能显示的表示出来，如响铃）
2、传输的字符是URL中保留的字符（如URL解析时使用 / 作为分隔符）
3、不安全的字符（这个是由于不同的文本处理程序对于文本可能会有不同的规则，如为了防止无用的空格输入，我们在写程序的时候可能会去掉文本的前后空格）

 1）rfc文档 : https://www.rfc-editor.org/rfc/rfc1738 

No corresponding graphic US-ASCII
        URLs are written only with the graphic printable characters of theUS-ASCII coded character set. The octets 80-FF hexadecimal are notused in US-ASCII, and the octets 00-1F and 7F hexadecimal representcontrol characters; these must be encoded.

Unsafe:
        Characters can be unsafe for a number of reasons.  The spacecharacter is unsafe because significant spaces may disappear andinsignificant spaces may be introduced when URLs are transcribed ortypeset or subjected to the treatment of word-processing programs.The characters "<" and ">" are unsafe because they are used as thedelimiters around URLs in free text; the quote mark (""") is used todelimit URLs in some systems.  The character "#" is unsafe and shouldalways be encoded because it is used in World Wide Web and in othersystems to delimit a URL from a fragment/anchor identifier that mightfollow it.  The character "%" is unsafe because it is used forencodings of other characters.  Other characters are unsafe becausegateways and other transport agents are known to sometimes modifysuch characters. These characters are "{", "}", "|", "\", "^", "~","[", "]", and "`".

All unsafe characters must always be encoded within a URL. Forexample, the character "#" must be encoded within URLs even insystems that do not normally deal with fragment or anchoridentifiers, so that if the URL is copied into another system thatdoes use them, it will not be necessary to change the URL encoding.

Reserved:
        Many URL schemes reserve certain characters for a special meaning:their appearance in the scheme-specific part of the URL has adesignated semantics. If the character corresponding to an octet isreserved in a scheme, the octet must be encoded.  The characters ";","/", "?", ":", "@", "=" and "&" are the characters which may bereserved for special meaning within a scheme. No other characters maybe reserved within a scheme.

  

没有相应的US-ASCII可打印字符：

URL仅使用美国ASCII编码字符集的图形可打印字符写入。八位字节80-FF十六进制不用于US-ASCII，八位字节00-1F和7F十六进制表示控制字符；这些必须被编码。

不安全的字符：

由于多种原因，字符可能不安全。空格字符是不安全的，因为当URL被转录或类型设置或接受字处理程序处理时，重要空格可能会消失，重要空格可能会被引入。字符“<”和“>”是不安全的，因为它们在自由文本中用作URL周围的分隔符；引号（“”）用于在某些系统中传递URL。字符“#”是不安全的，应始终对其进行编码，因为它在万维网和其他系统中用于从可能跟随它的片段/锚点标识符中分隔URL。字符“%”不安全，因为它用于其他字符的编码。其他字符是不安全的，因为通道和其他传输代理有时会修改这些字符。这些字符是“{”、“}”、“|”、“\”、“^”、“~”、“[”、“]”和“`”。

所有不安全字符必须始终在URL中编码。例如，字符“#”必须在URL中编码，即使在通常不处理片段或锚定标识符的系统中也是如此，因此，如果URL被复制到另一个使用它们的系统中，则无需更改URL编码。

保留字符：

许多URL方案保留某些字符以获得特殊含义：它们在URL方案特定部分的外观具有指定的语义。如果方案中保留了与八位字节对应的字符，则必须对八位字节进行编码。字符“；”、“/”、“？”、“：”、“@”、“=”和“&”是方案中可能具有特殊含义的字符。方案中不能保留其他字符。

 2）文章：
    https://www.cnblogs.com/nyw1983/p/11755792.html
    http://www.ruanyifeng.com/blog/2010/02/url_encoding.html（不太稳定）

Base64编码

    rfc文档 （原理）: https://www.rfc-editor.org/rfc/inline-errata/rfc4648.html（含Base64、Base32和Base16）
    
    百度百科：Base64是网络上最常见的用于传输8Bit字节码的编码方式之一，Base64就是一种基于64个可打印字符来表示二进制数据的方法。Base64编码是从二进制到字符的过程
    
    概括：Base64使8Bit字节码数据可以使用文本通道传输或存储到文本容器

    实例：

• 图片经过Base64转换成为文本数据可以存储到字符容器中

为什么不直接将二进制流存储到文本容器中？

文本存储到文本容器需要关联对应的字符集，如果直接使用二进制流存储，对应的字符集可能会使原信息发生变化。

为什么字符集会使信息发生变化?1 分钟带你认识从 "�" 到 "锟斤拷"__财经头条

• URL中的Base64--URL中的参数部分使用Base64

效果：参数部分不以明文的形式展示（采用Base64编码具有不可读性，需要解码后才能阅读。--百度百科）

不用在意，自说自话：

ISO-8859-1使用了单字节的全部位0x00-0xFF，使用这个字符集“绑定”到二进制流上是不是可以使8Bit字节码数据直接存储到字符容器中？

当参数中需要有URL地址时使用Base64

参数中传输位模式的标识信息也可以使用

URL中使用百分号编码时为什么不是将参数中所有的数据（字符串）进行百分号编码

 如：bs=%E7%BB%8F%E8%90%A5%E6 为什么不将 "bs=" 也进行百分号编码
    
    URL编码是为了 "兼容" 一些字符（上面提到的）所做的规定，将URL参数中的所有数据进行编码 可以使URL参数编码进行统一，但是会造成资源的浪费
    URL编码使用三个字符替换一个"字符"，使传输的字符扩大了三倍（相比需要编码的字符）。
    
    URL是局部编码!!!（URL中被替换的文本只是那些需要重新编码的部分） 

不用在意，自说自话：

URL编码为什么要用%做前缀？由于 URL是局部编码，解码时需要定位哪里进行了URL编码

为什么要用%做前缀，而不是使用其它字符？规定（%出现的可能性最低？字符概率问题？）

URL编码去掉%前缀，并且对所有的参数进行编码不就是Base32吗

百分号编码还是Base64（简单比较）

	Base64编码	URL编码
相比原字符大小	三分之四	三倍
参数编码范围	全部编码	部分编码