Base64 初探
什么是Base64? 
按照RFC2045的定義,Base64被定義為:Base64內容傳送編碼被設計用來把任意序列的8位字節描述為一種不易被人直接識別的形式。
?
為什么要使用Base64?
在設計這個編碼的時候,我想設計人員最主要考慮了3個問題: 
1.是否加密? 
2.加密算法復雜程度和效率 
3.如何處理傳輸? 
????加密是肯定的,但是加密的目的不是讓用戶發送非常安全的Email。這種加密方式主要就是“防君子不防小人”。即達到一眼望去完全看不出內容即可。 
基于這個目的加密算法的復雜程度和效率也就不能太大和太低。和上一個理由類似,MIME協議等用于發送Email的協議解決的是如何收發Email,而并不是如何安全的收發Email。因此算法的復雜程度要小,效率要高,否則因為發送Email而大量占用資源,路就有點走歪了。 
算法詳解 
????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 
字符’5’ 字符’^\’ 字符’^T’ 字符’3’ 
十進制53 十進制34 十進制20 十進制51 
表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 
字符’5’ 字符’^\’ 字符’^T’ 字符’3’ 
十進制53 十進制34 十進制20 十進制51 
字符’1’ 字符’i’ 字符’U’ 字符’z’ 
表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’ 字符’=’ 
表6 
這樣,最后的2個字節被整理成了“1iU=”。 
同理,若原代碼只剩下一個字節,那么將會添加兩個“=”。只有這兩種情況,所以,Base64的編碼最多會在編碼結尾有兩個“=” 
至于將Base64的解碼,只是一個簡單的編碼的逆過程,讀者可以自己探討。我將在文章的最后給出解碼算法。
?
算法實現 
其實在算法詳解的時候基本上已經說的很清楚了。用于程序上,除去約束判斷,大概可以分為如下幾步幾步: 
讀取數據3字節?用AND取前6位,放入新的變量中?右移兩位,高兩位清0?AND取第一個字節的后2位和第二個字節的前4位移位放入新變量中?右移兩位,清0……依此類推。 
解碼的類C語言實現的算法: 
?
根據這段算法,文章最開始給出的Email內容,可以解碼為: 
你好,SnaiX 
  這是一個Base64的測試郵件!
Java算法:
package javamail;import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader;import sun.misc.BASE64Encoder;public class Base64Util {public static void main(String[] args)throws IOException {BASE64Encoder encoder =new BASE64Encoder();System.out.println("please input username:");String username=new BufferedReader(new InputStreamReader(System.in)).readLine();System.out.println(encoder.encode(username.getBytes()));System.out.println("please input password:");String passwd=new BufferedReader(new InputStreamReader(System.in)).readLine();System.out.println(encoder.encode(passwd.getBytes()));} }?
轉載于:https://www.cnblogs.com/mingforyou/archive/2011/10/22/2220988.html
總結
 
                            
                        - 上一篇: Silverlight和WCF交互式的实
- 下一篇: u-boot分析——struct gd_
