base64用法和使用场景
base64编码的产生背景
base64最开始是邮件的协议出现的。
邮件的源文件
打开某个邮件的源文件，可以看到邮件的正文部分，使用了base64编码。
Content-Transfer-Encoding：base64
这样的初衷，是为了满足电子邮件中不能直接使用非ASCII码字符的规定
比如图片文件，附件是二进制文件。电子邮件的协议不能支持到，使用base64进行编码，传输，在客户端再去解码得到原始文件。
传统电子邮件协议，即RFC822。导致的问题：
- 非英语字符都不能在电子邮件中使用
- 电子邮件中不能插入二进制文件（如图片）
- 电子邮件不能有附件
电子邮件协议使用MIME（传统电子邮件一系列拓展协议）去拓展的这些功能。
这个编码带来的意义：
所有的二进制文件，都可以因此转化为可打印的文本编码，使用文本软件进行编辑。
使用场景：
1.前边提到的邮件算是一个
2.如果纯文本数据包含不可见字符，就需要使用base64，比如xml文件某节点数据包含可见字符，显示的话就是乱码，不能够编辑操作。使用base64编码后显示，需要还原的地方再解码。（二进制文件图片应用类似）
3.简单加密（所以看到字符串中包含大小写和等号，很可能就是base64编码）
选择base64的好处，编码后比原字符多出1/3的空间。
而16进制的编码会多出一倍的空间。
字符集的历史：
https://www.zhihu.com/question/23374078
文章写的很形象易懂
所有使用不同字符集编码，base64的结果是不同的。
unicode 是字符集，不是编码
utf-8是在unicode的基础上的编码
交换机的原理：
URL编码
- 我们都知道，http请求，在解析参数时是根据?和=号去解析的。
那么当key value中包含=号时，参数解析就会错误。 - 还有当url出现汉字时，会自动编码。
网络标准[RFC 1738]做了硬性规定：
...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL.
只有字母和数字[0-9a-zA-Z]、一些特殊符号"$-_.+!*'(),"[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。"
所以如果http传输URL中有汉字，就必须编码后使用。但是麻烦的是 标准的国际组织并没有规定具体的编码方法，而是交给应用程序（浏览器）自己决定。 这导致"URL编码"成为了一个混乱的领域。
不同的操作系统、不同的浏览器、不同的网页字符集，将导致完全不同的编码结果
比如Chrome和火狐，再不经过人为的编码，浏览器的编码结果是不一样的。
所以上述两点是url编码的原因。
把要编码的字符转成16进制字符，前加%。所以看到很多%，就可以判断是url编码
参考：
http://www.ruanyifeng.com/blog/2010/02/url_encoding.html
https://www.zhihu.com/question/23374078
http://www.ruanyifeng.com/blog/2008/06/base64.html
http://www.ruanyifeng.com/blog/2008/06/mime.html
