什麼是Base64？
轉自： http://baike.baidu.com/view/469071.htm
Base64要求把每三個8Bit的字節轉換爲四個6Bit的字節（3*8 = 4*6 = 24），然後把6Bit再添兩位高位0，組成四個8Bit的字節，也就是說，轉換後的字符串理論上將要比原來的長1/3。
關於這個編碼的規則：
①.把3個字符變成4個字符..
②每76個字符加一個換行符..
③.最後的結束符也要處理..
這樣說會不會太抽象了？不怕，我們來看一個例子：
轉換前 aaaaaabb ccccdddd eeffffff
轉換後 00aaaaaa 00bbcccc 00ddddee 00ffffff
應該很清楚了吧？上面的三個字節是原文，下面的四個字節是轉換後的Base64編碼，其前兩位均爲0。
轉換後，我們用一個碼錶來得到我們想要的字符串（也就是最終的Base64編碼），這個表是這樣的：（摘自RFC2045）
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
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
個人體會 ：
1，上面的例子裏“aaaaaabb ccccdddd eeffffff ” 這樣的編碼是不存在的，筆者理解不對，應該是 字節裏應該是 “0” “1” 這樣的2進制編碼。下面的例子比較正確。
2，按照上面這個算法來看，是按照每6位來劃分的，所以字符的表現值最多爲 2 的6 次方等於64。 然後通過查詢定義表來對應1-64各代表什麼字母，符號或數字，所以這樣的編碼叫做BASE64。 就是用最基本的64個字母，符號或數字來表達所以的文字。
什麼是Base64編碼？
打開一封Email，查看其原始信息（您可以通過收取、導出該郵件用文本編輯器查看）。你會看到類似這樣的一個效果：
Date: Thu, 25 Dec 2003 06:33:07 +0800
From: "eSX?!" <[email protected]'>[email protected]'>[email protected]'>[email protected]>
Reply-To: [email protected]'>[email protected]'>[email protected]'>[email protected]
To: "snaix" <[email protected]'>[email protected]>
Subject:
X-mailer: Foxmail 5.0 beta2 [cn]
Mime-Version: 1.0
Content-Type: text/plain;
charset="gb2312"
Content-Transfer-Encoding: base64
xOO6w6OsU25haVgNCg0KoaGhodXiysfSu7j2QmFzZTY0tcSy4srU08q8/qOhDQoNCkJlc3QgV2lz
aGVzIQ0KIAkJCQkNCqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaEgICAgICAgICAgICAgICBl
U1g/IQ0KoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoSAgICAgICAgICAgICAgIHNuYWl4QHll
YWgubmV0DQqhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhICAgICAgICAgMjAwMy0x
Mi0yNQ0K
是否看到了“base64”標記？是否看到了標記下面的一行亂碼？也許你會恍然大悟，對！這就是Base64編碼。
什麼是Base64？
按照RFC2045的定義，Base64被定義爲：Base64內容傳送編碼被設計用來把任意序列的8位字節描述爲一種不易被人直接識別的形式。（The Base64 Content-Transfer-Encoding is designed to represent arbitrary sequences of octets in a form that need not be humanly readable.）
爲什麼要使用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
字符’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語言實現的算法：
BYTE LMoveBit(int base, int MoveNum)
{
BYTE result=base;
if(MoveNum==0)return 1;
if(MoveNum==1)return MoveNum;
result=base<<(MoveNum-1);
return result;
}
char base64_alphabet[]=
{'A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P',
'Q','R','S','T','U','V','W','X','Y','Z','a','b','c','d','e','f',
'g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v',
'w','x','y','z','0','1','2','3','4','5','6','7','8','9','+','/','='};
BYTE Base64Decode(char *base64code, DWORD base64length)
{
char buf[4];
int i,j;
int k;
int l=0;
BYTE temp1[4],temp2;
BYTE *Buffer=new BYTE[base64length*3/4];
DWORD base64a=(base64length/4)-1;
DWORD base64b=0;
for(;base64b<base64a+1;base64b++)
{
for(i=0;i<4;i++)
{
buf[i]=*(base64code+(base64b*4)+i);
for(j=0;j<65;j++)
{
if(buf[i]==base64_alphabet[j])
{
temp1[i]=j;
break;
}
}
}
i--;
for(k=1;k<4;k++)
{
if(temp1[i-(k-1)]==64){m_padnum++; continue;}
temp1[i-(k-1)]=temp1[i-(k-1)]/LMoveBit(2,(k-1)*2);
temp2=temp1[i-k];
temp2=temp2&(LMoveBit(2,k*2)-1);
temp2*=LMoveBit(2,8-(2*k));//move 4
temp1[i-(k-1)]=temp1[i-(k-1)]+temp2;
Buffer[base64b*3+(3-k)]=temp1[i-(k-1)];
}
}
return Buffer;
}
根據這段算法，文章最開始給出的Email內容，可以解碼爲：
你好，SnaiX
這是一個Base64的測試郵件！
Best Wishes!
