BASE64编码通俗介绍
byte[]数组不利于文本方式传递，一般会进行文本化处理。常见的方式有转换为十六进制数列表和使用Base64编码两种。
十六进制数会将4bit转换为一个字符，而Base64能将6bit转换为一个字符。有时为了有效控制转换后文本的长度，在实际工作中会选用Base64编码。
传统的邮件只支持可见字符的传输，像ASCII码的控制字符就不能通过邮件传输。另外，图片二进制流的每个字节不可能全部都是可见字符，所以无法使用文本传输。
那么，如何解决该问题呢？
注：ASCII码包含了128个字符。其中，前32个为031，即0x000x1F，都是不可见字符。这些字符就是控制字符。
最好的方法就是在不改变传统协议的情况下，实现一种扩展方案。该方案将无法用文本表示的二进制编码转换为可见文本进行传输，从而解决相关问题，而Base64编码就是一种落地方案。
Base64是一种编码方式，这个术语是在“MIME内容传输编码规范”中提到的。Base64不是一种加密算法，实际上是一种“二进制转换到文本”的编码方式，将任意二进制数据转换为ASCII字符串的形式，以便在只支持文本的环境中也能顺利传输二进制数据。
Base64编码首先建立了如表1所示的Base64编码表，将数字0~63分别映射到64个不同的字符中。
| 索引 | 对应字符 | 索引 | 对应字符 | 索引 | 对应字符 | 索引 | 对应字符 |
|---|---|---|---|---|---|---|---|
| 0 | A | 17 | R | 34 | i | 51 | z |
| 1 | B | 18 | S | 35 | j | 52 | 0 |
| 2 | C | 19 | T | 36 | k | 53 | 1 |
| 3 | D | 20 | U | 37 | l | 54 | 2 |
| 4 | E | 21 | V | 38 | m | 55 | 3 |
| 5 | F | 22 | W | 39 | n | 56 | 4 |
| 6 | G | 23 | X | 40 | o | 57 | 5 |
| 7 | H | 24 | Y | 41 | p | 58 | 6 |
| 8 | I | 25 | Z | 42 | q | 59 | 7 |
| 9 | J | 26 | a | 43 | r | 60 | 8 |
| 10 | K | 27 | b | 44 | s | 61 | 9 |
| 11 | L | 28 | c | 45 | t | 62 | + |
| 12 | M | 29 | d | 46 | u | 63 | / |
| 13 | N | 30 | e | 47 | v | ||
| 14 | O | 31 | f | 48 | w | ||
| 15 | P | 32 | g | 49 | x | ||
| 16 | Q | 33 | h | 50 | y |
表1
由于 64个不同的字符，最多对应于64种不同的二进制编码，而6bit恰好有64种不同的二进制编码，因此Base64编码的每个字符表示一个6bit长度的二进制数。
在实际工作中，所有的二进制数都以Byte(8bit)为单位，所以要编码的二进制数的bit长度都是8的倍数；而Base64编码以6bit为单位，所以Base64能编码的二进制数的bit长度都要求为6的倍数。这就涉及补齐操作，即把8的倍数补齐到6的倍数。
在如表2所示的Base64编码示例中展示了一种完美情况。这时输入有3Byte，正好转换为4个Base64编码字符。
| 二进制位 | 010011 | 010110 | 000101 | 101110 |
|---|---|---|---|---|
| 索引 | 19 | 22 | 5 | 46 |
| Base64编码 | T | W | F | u |
表2
在其它不完美的情况下，需要将8的倍数的bit后面补0，一直补到bit的长度是6的倍数为止。综上所述，从8的倍数的bit补0到6的倍数的bit，只存在补“00”和“0000”两种情况。表3和表4所示为Base64补位示例，分别展示了补“00“和补”0000“的最简情况。
| 二进制位 | 010000 | 100100 | 0011 | |
|---|---|---|---|---|
| 二进制位（补0） | 010000 | 100100 | 001100 | |
| Base64编码 | Q | k | M | = |
表3
| 二进制位 | 010000 | 01 | ||
|---|---|---|---|---|
| 二进制位（补0） | 010000 | 010000 | ||
| Base64编码 | Q | Q | = | = |
表4
通过补”00”或“0000”最终都能符合Base64的编码要求，在标准的Base64编码中又约定编码字符长度为4的倍数（契合表2中的完美模式）。因此，在补“00”时，添加 一个“=”补齐（见表3）；在补“0000”时，添加两个“=”补齐（见表4）。
但是，“=”在实际的解码过程中是没有任何作用的，之所以用“=”，可能是考虑到多段编码后的Base64字符串拼起来也不会引用混淆。
以上便是标准的Base64编码过程（解决过程就是逆过程，此处省略），但是在实际应用中，由于Base64编码可能会出现在URL中，为了解决这种情况下导致的乱码问题，一般会使用URL安全（URL Safe)的Base64编码。
在标准的Base64编码过程中会出现字符“+”、“/”，“=”，其中“+”和“/”作为编码字符出现在编码表中，“=”作为填充字符。而这3个字符是URL不安全的，即出现在URL中时需要进行转义。所以URL安全的Base64编码直接用“-”代替“+”，用“_“代替”/“，并且不进行”=“补齐。这样得到的Base64编码就可以安全地出现在URL上。
注：
摘录自糜鹏程写的《OAuth2实战宝典》。
个人觉得是对Base64最易懂的中文版介绍，所以摘录了下来。