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;
    }

}