Java的Base64加密原理

出自：   http://www.cnblogs.com/winner-0715/p/5920269.html

　　　　http://www.cnblogs.com/koliop090/p/5203553.html

为什么要使用Base64？

在设计这个编码的时候，我想设计人员最主要考虑了3个问题： 
1.是否加密？ 
2.加密算法复杂程度和效率 
3.如何处理传输？

加密是肯定的，但是加密的目的不是让用户发送非常安全的Email。这种加密方式主要就是“防君子不防小人”。即达到一眼望去完全看不出内容即可。 
基 于这个目的加密算法的复杂程度和效率也就不能太大和太低。和上一个理由类似，MIME协议等用于发送Email的协议解决的是如何收发Email，而并不 是如何安全的收发Email。因此算法的复杂程度要小，效率要高，否则因为发送Email而大量占用资源，路就有点走歪了。

但 是，如果是基于以上两点，那么我们使用最简单的恺撒法即可，为什么Base64看起来要比恺撒法复杂呢？这是因为在Email的传送过程中，由于历史原 因，Email只被允许传送ASCII字符，即一个8位字节的低7位。因此，如果您发送了一封带有非ASCII字符（即字节的最高位是1）的Email通 过有“历史问题”的网关时就可能会出现问题。网关可能会把最高位置为0！很明显，问题就这样产生了！因此，为了能够正常的传送Email，这个问题就必须 考虑！所以，单单靠改变字母的位置的恺撒之类的方案也就不行了。关于这一点可以参考RFC2046。 
基于以上的一些主要原因产生了Base64编码。

算法详解

Base64编码要求把3个8位字节（3*8=24）转化为4个6位的字节（4*6=24），之后在6位的前面补两个0，形成8位一个字节的形式。 
具体转化形式间下图： 
字符串“张3” 
11010101 11000101 00110011

00110101 00011100 00010100 00110011 
表1

可以这么考虑：把8位的字节连成一串110101011100010100110011 
然后每次顺序选6个出来之后再把这6二进制数前面再添加两个0，就成了一个新的字节。之后再选出6个来，再添加0，依此类推，直到24个二进制数全部被选完。 
让我们来看看实际结果：

字符串“张3” 
11010101 HEX:D5 11000101 HEX:C5 00110011 HEX:33

00110101 00011100 00010100 00110011

十进制53 十进制34 十进制20 十进制51 
字符’5’ 字符’^\’ 字符’^T’ 字符’3’ （ASCII表对应的值）

表2

这样“张3 ”这个字符串就被Base64表示为”5^\^T3”了么？。错！ 
Base64编码方式并不是单纯利用转化完的内容进行编码。像’^\’字符是控制字符，并不能通过计算机显示出来，在某些场合就不能使用了。Base64有其自身的编码表：

Table 1: The Base64 Alphabet 
Value Encoding Value Encoding Value Encoding Value Encoding 
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 (pad) = 
14 O 31 f 48 w 
15 P 32 g 49 x 
16 Q 33 h 50 y 
表3

这 也是Base64名称的由来，而Base64编码的结果不是根据算法把编码变为高两位是0而低6为代表数据，而是变为了上表的形式，如”A”就有7位， 而”a”就只有6位。表中，编码的编号对应的是得出的新字节的十进制值。因此，从表2可以得到对应的Base64编码：

字符串“张3” 
11010101 HEX:D5 11000101 HEX:C5 00110011 HEX:33

00110101 00011100 00010100 00110011

十进制53 十进制34 十进制20 十进制51 
字符’5’ 字符’^\’ 字符’^T’ 字符’3’ （ASCII表对应的值）
字符’1’ 字符’i’ 字符’U’ 字符’z’ （Base64编码表对应的值）
表4

这样，字符串“张3”经过编码后就成了字符串“1iUz”了。 
Base64将3个字节转变为4个字节，因此，编码后的代码量（以字节为单位，下同）约比编码前的代码量多了1/3。之所以说是“约”，是因为如果代码量正好是3的整数倍，那么自然是多了1/3。但如果不是呢？ 
细心的人可能已经注意到了，在The Base64 Alphabet中的最后一个有一个(pad) =字符。这个字符的目的就是用来处理这个问题的。 
当代码量不是3的整数倍时，代码量/3的余数自然就是2或者1。转换的时候，结果不够6位的用0来补上相应的位置，之后再在6位的前面补两个0。转换完空出的结果就用就用“=”来补位。譬如结果若最后余下的为2个字节的“张”：

字符串“张” 
11010101 HEX:D5 11000101 HEX:C5

00110101 00011100 00010100 
十进制53 十进制34 十进制20 pad 
字符’1’ 字符’i’ 字符’U’ 字符’=’ （Base64编码表对应的值）
表6

这样，最后的2个字节被整理成了“1iU=”。 
同理，若原代码只剩下一个字节，那么将会添加两个“=”。只有这两种情况，所以，Base64的编码最多会在编码结尾有两个“=” 
至于将Base64的解码，只是一个简单的编码的逆过程，读者可以自己探讨。

使用Apache commons codec 类Base64

maven依赖

<dependency>
    <groupId>commons-codec</groupId>
    <artifactId>commons-codec</artifactId>
    <version>1.6</version>
</dependency>

Java代码实现

import org.apache.commons.codec.binary.Base64;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.UnsupportedEncodingException;

/**
 * 将String进行base64编码解码，使用utf-8
 */
public class Base64Util {

    private static final Logger logger = LoggerFactory.getLogger(Base64Util.class);

    /**
     * 对给定的字符串进行base64解码操作
     */
    public static String decodeData(String inputData) {
        try {
            if (null == inputData) {
                return null;
            }
            return new String(Base64.decodeBase64(inputData.getBytes("utf-8")), "utf-8");
        } catch (UnsupportedEncodingException e) {
            logger.error(inputData, e);
        }

        return null;
    }

    /**
     * 对给定的字符串进行base64加密操作
     */
    public static String encodeData(String inputData) {
        try {
            if (null == inputData) {
                return null;
            }
            return new String(Base64.encodeBase64(inputData.getBytes("utf-8")), "utf-8");
        } catch (UnsupportedEncodingException e) {
            logger.error(inputData, e);
        }

        return null;
    }

}