Base64 的那些事儿

一、Base64是什么？

Base64是一种编码的格式。是将信息流(字节流)按照一定的规范，重新组合，显示出完全不相关内容的编码格式。

ps.定义是我自己总结的，我觉得对于知识的定义，只要简洁，不错误，表述清楚，不要拘泥于一个字一个词，重要的是真正理解它的原理即可。(其实是因为自己根本不知道标准的定义是什么...)

二、Base64的由来？

对计算机信息存储稍有了解的人，都清楚，在计算机内部是以二进制来存储一切信息的。而直接以二进制为单元进行处理，显然是不方便处理的，如果数量级过大，我们往往采用增加计数单位的形式。（有兴趣的同学可以参考《从1到无穷大》这本书），所以在计算机世(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )界中就出现了字节这个东西。以每8个bit位组成一个字节。这样任何信息都可以划分为占用多少多少个字节来说。如下表所示：

根据大家的认知，大小写一共52个字母、外加数字加特殊符号等，一个字节是完全可以表述完整的单个字符的（这里使用的就是ASCII对照表）。

但是对于非英语国家来说就比较头疼了。发送信息之前翻译成英语，收到之后再翻译为本国语言，显然是成本非常高的。怎么解决呢？就是使用多个字节来表示一个字符。这样UTF-8、GBK、UNICODE等编码就应运而生了（有兴趣的同学可以查下它们的区别）。这些编码基本解决了世界上已知语言在计算中有效存储流动的问题。

但是问题又来了，有时候我们使用的设备，根本就不支持这些复杂的国际化编码。

举个例子，我在家给领导发了封邮件，说最近身体不适，打算请天假去看看外面的世界。

我的表情是这样的：

领导打开邮件之后，发现是一屏幕的乱码，而且发现我今天没来。

领导的表情是这样的：

当我心情愉悦的假后来上班时，领导面带微笑的问我这两天去哪里时。

我的表情是这样的：

当领导和我说：电话打不通，邮件是乱码，人也失踪的时候。

我的表情是这样的：

当我解释事情是这样的：巴拉巴拉。

我的表情是这样的：“这件事情是这样的，说起来你可能不信但真的是垃圾桶先动的手”

在听了我的解释以后。

领导的表情是这样的：

好了言归正传，为什么会出现上游（我）发送的消息，到了下游（领导）就出现无法理解的情况呢？

这是由于历史原因，早前Email只被允许传送ASCII字符（不知道现在是否改善），即一个字节的低7位，也就是128种表示。于是当我用各种国际字符发送消息时，势必就会出现字节的最高位居然是1的问题(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )。考虑到健壮性和容错性，有些网络设备就会把首bit位置换成0。而原本整套的非ASCII码的字符，就被硬生生的转成一套ASCII码。于是当收件者打开邮件进行阅读时，邮件系统将收到数据硬生生的再转成非ASCC码时，一切都晚了。（记得早前，大学老师去欧洲德国留学，给老师写email只能用拼音）。

其实除去网关，其他路由等硬件设备都会出现这样那样的不支持问题。（对于128~255这些不可见字符，不同路由设备在接收后的处理是不一样的，这也就是为什么发送信息经常使用转码，而不是采用直接传输单个字节这一套方法（此处可看http://www.zhihu.com/question/36306744/answer/71626823 郭无心的叙述）。而除去邮件系统，其他很多系统也会因为不支持某些特殊字符，造成发送方和接收方，双方的信息的不一致。

这里简单举个例子，我们通过互联网聊天时，数据都是先发送给服务端。服务端发现信息中包含了某个特殊字符，而服务端本身又不支持这个特殊字符。于是就从字库里，找到默认字符补填。这样接收方收到消息时，这个特殊字符就显示不出来了。取而代之的是一些缺省字符，如‘◇’，‘□’。（ps，印象中QQ游戏是不支持‘.’这个特殊字符的）。

为了解决此类的种种问题，于是Base64就应运而生了。

三、Base64是如何处理字符串编码的？

这里先直入正题，阐述关于Base64编码的情况。

首先明确这样一个前提，所有信息肯定都是以字节的形式存在的。那么他的长度对于3这个数字有三种分类：

(1)长度除以3余0：len%3=0；

(2)长度除以3余1：len%3=1；

(3)长度除以3余2：len%3=2；

第(1)情况：

我们把每3个字(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )节划分成一份，然后再把它平均拆分成4份。那么每份就有6个bit位。

3*8bit=24bit=4*6bit