最近因為工作需要，要用到Base64來編碼解碼文件，參考了網(wǎng)上大牛們的代碼，做了個測試?yán)樱梢杂脕韺ψ址?，文件進行編碼解碼。本人只是集成者，很多都是網(wǎng)上有的資料了。各位高手請勿見笑。
大家可以下載去看看了，用的環(huán)境是VC2003.
Base64編碼解碼

附錄：Base64說明
什么是Base64？

按照RFC2045的定義，Base64被定義為：Base64內(nèi)容傳送編碼被設(shè)計用來把任意序列的8位字節(jié)描述為一種不易被人直接識別的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）

為什么要使用Base64？

在設(shè)計這個編碼的時候，我想設(shè)計人員最主要考慮了3個問題：
1.是否加密？
2.加密算法復(fù)雜程度和效率
3.如何處理傳輸？

    加密是肯定的，但是加密的目的不是讓用戶發(fā)送非常安全的Email。這種加密方式主要就是“防君子不防小人”。即達到一眼望去完全看不出內(nèi)容即可。
基于這個目的加密算法的復(fù)雜程度和效率也就不能太大和太低。和上一個理由類似，MIME協(xié)議等用于發(fā)送Email的協(xié)議解決的是如何收發(fā)Email，而并不是如何安全的收發(fā)Email。因此算法的復(fù)雜程度要小，效率要高，否則因為發(fā)送Email而大量占用資源，路就有點走歪了。

    但是，如果是基于以上兩點，那么我們使用最簡單的愷撒法即可，為什么Base64看起來要比愷撒法復(fù)雜呢？這是因為在Email的傳送過程中，由于歷史原因，Email只被允許傳送ASCII字符，即一個8位字節(jié)的低7位。因此，如果您發(fā)送了一封帶有非ASCII字符（即字節(jié)的最高位是1）的Email通過有“歷史問題”的網(wǎng)關(guān)時就可能會出現(xiàn)問題。網(wǎng)關(guān)可能會把最高位置為0！很明顯，問題就這樣產(chǎn)生了！因此，為了能夠正常的傳送Email，這個問題就必須考慮！所以，單單靠改變字母的位置的愷撒之類的方案也就不行了。關(guān)于這一點可以參考RFC2046。
基于以上的一些主要原因產(chǎn)生了Base64編碼。

算法詳解

    Base64編碼要求把3個8位字節(jié)（3*8=24）轉(zhuǎn)化為4個6位的字節(jié)（4*6=24），之后在6位的前面補兩個0，形成8位一個字節(jié)的形式。
具體轉(zhuǎn)化形式間下圖：
字符串“張3”
11010101 11000101 00110011

00110101 00011100 00010100 00110011
表1

可以這么考慮：把8位的字節(jié)連成一串110101011100010100110011
然后每次順序選6個出來之后再把這6二進制數(shù)前面再添加兩個0，就成了一個新的字節(jié)。之后再選出6個來，再添加0，依此類推，直到24個二進制數(shù)全部被選完。
讓我們來看看實際結(jié)果：

字符串“張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編碼方式并不是單純利用轉(zhuǎn)化完的內(nèi)容進行編碼。像’^\’字符是控制字符，并不能通過計算機顯示出來，在某些場合就不能使用了。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編碼的結(jié)果不是根據(jù)算法把編碼變?yōu)楦邇晌皇?而低6為代表數(shù)據(jù)，而是變?yōu)榱松媳淼男问?，?#8221;A”就有7位，而”a”就只有6位。表中，編碼的編號對應(yīng)的是得出的新字節(jié)的十進制值。因此，從表2可以得到對應(yīng)的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”經(jīng)過編碼后就成了字符串“1iUz”了。
Base64將3個字節(jié)轉(zhuǎn)變?yōu)?個字節(jié)，因此，編碼后的代碼量（以字節(jié)為單位，下同）約比編碼前的代碼量多了1/3。之所以說是“約”，是因為如果代碼量正好是3的整數(shù)倍，那么自然是多了1/3。但如果不是呢？
細心的人可能已經(jīng)注意到了，在The Base64 Alphabet中的最后一個有一個(pad) =字符。這個字符的目的就是用來處理這個問題的。
當(dāng)代碼量不是3的整數(shù)倍時，代碼量/3的余數(shù)自然就是2或者1。轉(zhuǎn)換的時候，結(jié)果不夠6位的用0來補上相應(yīng)的位置，之后再在6位的前面補兩個0。轉(zhuǎn)換完空出的結(jié)果就用就用“=”來補位。譬如結(jié)果若最后余下的為2個字節(jié)的“張”：

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

00110101 00011100 00010100
十進制53 十進制34 十進制20 pad
字符’1’ 字符’i’ 字符’U’ 字符’=’
表6

這樣，最后的2個字節(jié)被整理成了“1iU=”。
同理，若原代碼只剩下一個字節(jié)，那么將會添加兩個“=”。只有這兩種情況，所以，Base64的編碼最多會在編碼結(jié)尾有兩個“=”
至于將Base64的解碼，只是一個簡單的編碼的逆過程，讀者可以自己探討。