MIME
在MIME格式的電子郵件中，base64可以用來將binary的位元組序列數據編碼成ASCII字元序列構成的文本。使用時，在傳輸編碼方式中指定base64。使用的字元包括大小寫字母各26個，加上10個數字，和加號“+”，斜槓“/”，一共64個字元，等號“=”用來作為後綴用途。
完整的base64定義可見（http://tools.ietf.org/html/rfc1421）和RFC 2045。編碼後的數據比原始數據略長，為原來的。在電子郵件中，根據RFC 822規定，每76個字元，還需要加上一個回車換行。可以估算編碼後數據長度大約為原長的135.1%。
轉換的時候，將三個byte的數據，先後放入一個24bit的緩衝區中，先來的byte占高位。數據不足3byte的話，於緩衝區中剩下的bit用0補足。然後，每次取出6（因為）個bit，按照其值選擇ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/中的字元作為編碼後的輸出。不斷進行，直到全部輸入數據轉換完成。
當原數據長度不是3的整數倍時, 如果最後剩下兩個輸入數據，在編碼結果後加1個“=”；如果最後剩下一個輸入數據，編碼結果後加2個“=”；如果沒有剩下任何數據，就什麼都不要加，這樣才可以保證資料還原的正確性。
例子
舉例來說，一段引用自托馬斯·霍布斯的利維坦的文句：
Man is distinguished, not only by his reason, but by this singular passion from other animals, which is a lust of the mind, that by a perseverance of delight in the continued and indefatigable generation of knowledge, exceeds the short vehemence of any carnal pleasure.
經過base64編碼之後變成：
TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=
•編碼“Man”
| 文本 | M | a | n | |||||||||||||||||||||
| ASCII編碼 | 77 | 97 | 110 | |||||||||||||||||||||
| 二進制位 | 0 | 1 | 0 | 0 | 1 | 1 | 0 | 1 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 | 1 | 1 | 1 | 0 |
| 索引 | 19 | 22 | 5 | 46 | ||||||||||||||||||||
| Base64編碼 | T | W | F | u | ||||||||||||||||||||
在此例中，Base64算法將三個字元編碼為4個字元
Base64索引表：
| Value | Char | Value | Char | Value | Char | Value | Char | |||
| 0 | A | 16 | Q | 32 | g | 48 | w | |||
| 1 | B | 17 | R | 33 | h | 49 | x | |||
| 2 | C | 18 | S | 34 | i | 50 | y | |||
| 3 | D | 19 | T | 35 | j | 51 | z | |||
| 4 | E | 20 | U | 36 | k | 52 | 0 | |||
| 5 | F | 21 | V | 37 | l | 53 | 1 | |||
| 6 | G | 22 | W | 38 | m | 54 | 2 | |||
| 7 | H | 23 | X | 39 | n | 55 | 3 | |||
| 8 | I | 24 | Y | 40 | o | 56 | 4 | |||
| 9 | J | 25 | Z | 41 | p | 57 | 5 | |||
| 10 | K | 26 | a | 42 | q | 58 | 6 | |||
| 11 | L | 27 | b | 43 | r | 59 | 7 | |||
| 12 | M | 28 | c | 44 | s | 60 | 8 | |||
| 13 | N | 29 | d | 45 | t | 61 | 9 | |||
| 14 | O | 30 | e | 46 | u | 62 | + | |||
| 15 | P | 31 | f | 47 | v | 63 | / | |||
如果要編碼的位元組數不能被3整除，最後會多出1個或2個位元組，那么可以使用下面的方法進行處理：先使用0位元組值在末尾補足，使其能夠被3整除，然後再進行base64的編碼。在編碼後的base64文本後加上一個或兩個'="號，代表補足的位元組數。也就是說，當最後剩餘一個八位位元組（一個byte）時，最後一個6位的base64位元組塊有四位是0值，最後附加上兩個等號；如果最後剩餘兩個八位位元組（2個byte）時，最後一個6位的base位元組塊有兩位是0值，最後附加一個等號。 參考下表：
| 二進制位 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | ||||||||||||||||
| 二進制位（補0） | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | ||||||||||||
| Base64編碼 | Q | Q | ||||||||||||||||||||||
| 文本（2 Byte） | B | C | ||||||||||||||||||||||
| 二進制位 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | x | x | x | x | x | x | ||
| 二進制位（補0） | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | x | x | x | x | x | x |
| Base64編碼 | Q | k | M | |||||||||||||||||||||
UTF-7
UTF-7是一個修改的Base64（ Modified Base64）。主要是將UTF-16的數據，用Base64的方法編碼為可列印的ASCII字元序列。目的是傳輸Unicode數據。主要的區別在於不用等號"="補余，因為該字元通常需要大量的轉譯。
標準可見RFC 2152，《A Mail-Safe Transformation Format of Unicode》。
IRCu
在IRCu等軟體所使用的P10 IRC伺服器間協定中，對客戶與伺服器的訊息類型號（client/server numerics）和二進制IP位址採用了base64編碼。訊息類型號的長度固定為3位元組，故可直接編碼為4個位元組而不需要加填充。對IP位址進行編碼時，則需要在地址前添加一些0比特，使之可以編碼為整數個位元組。這裡所用的符號集與前述MIME的也有所不同，將+/改成了[]。
在URL中的套用
Base64編碼可用於在HTTP環境下傳遞較長的標識信息。例如，在Java持久化系統Hibernate中，就採用了Base64來將一個較長的標識符（一般為128-bit的UUID）編碼為一個字元串，用作HTTP表單和HTTP GET URL中的參數。在其他應用程式中，也常常需要把二進制數據編碼為適合放在URL（包括隱藏表單域）中的形式。此時，採用Base64編碼不僅比較簡短，同時也具有不可讀性，即所編碼的數據不會被人用肉眼所直接看到。
然而，標準的Base64並不適合直接放在URL里傳輸，因為URL編碼器會把標準Base64中的“/”和“+”字元變為形如“%XX”的形式，而這些“%”號在存入資料庫時還需要再進行轉換，因為ANSI SQL中已將“%”號用作通配符。
為解決此問題，可採用一種 用於URL的改進Base64編碼，它不在末尾填充"="號，並將標準Base64中的“+”和“/”分別改成了“-”和“_”，這樣就免去了在URL編解碼和資料庫存儲時所要作的轉換，避免了編碼信息長度在此過程中的增加，並統一了資料庫、表單等處對象標識符的格式。
另有一種 用於正則表達式的改進Base64變種，它將“+”和“/”改成了“!”和“-”，因為“+”，“*”以及前面在IRCu中用到的“[”和“]”在正則表達式中都可能具有特殊含義。
此外還有一些變種，它們將“+/”改為“_-”或“._”（用作程式語言中的標識符名稱）或“.-”（用於XML中的 Nmtoken）甚至“_:”（用於XML中的 Name）。
其他套用
•Mozilla Thunderbird和Evolution用Base64來保密電子郵件密碼
•Base64也會經常用作一個簡單的“加密”來保護某些數據，而真正的加密通常都比較繁瑣。
•垃圾訊息傳播者用Base64來避過反垃圾郵件工具，因為那些工具通常都不會翻譯Base64的訊息。
•在LDIF檔案，Base64用作編碼字串。
64進制有關
64進制，所用的字元是“0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ+/”。
一直以來使用16進制從來沒有注意過a~f到底是大寫還是小寫，這次要使用64進制，著實需要看清楚了。參考了apache的codec里關於2進制轉換16進制的方法，2進制轉換64進制也是同樣道理。將byte數組中的一個位元組分為兩個位元組組成char數組，一個byte位元組對應0xC0 & data[i] >>>6和0x3F & data[i]，這樣構成的char數組即為64進制的char數組，再將其轉為String即可使用。
對於進制轉換關鍵是要把位、位元組、字元、字元串的概念弄清楚。
一個帶符號的位元組能表示的數值範圍是-127~128，因此我們無論轉換進制為2進制、8進制、16進制等等，甚至是128進制都可以考慮按位操作進行進制轉換，Apache的commons-codec項目中針對16進制轉換的方法代碼如下：
public static char[] encodeHex(byte[] data) {
int l = data.length;
char[] out = new char[l << 1];
// two characters form the hex value.
for (int i = 0, j = 0; i < l; i++) {
out[j++] = DIGITS[(0xF0 & data[i]) >>> 4 ];
out[j++] = DIGITS[ 0x0F & data[i] ];
}
return out;
}
代碼中將一個位元組分為兩個位元組進行存儲，這樣一個位元組轉換為一個字元來表示，這樣可以方便的轉換任何數據不用考慮符號丟失。至於一個位元組轉換為兩個位元組的原則，根據需要轉換的不同進制設定兩個位元組的分界點，如16進制的轉換，在一個位元組中表示16為00001111，那么低四位即為一個位元組，高四位為另一個位元組；同理，對於64進制，在一個位元組中表示64為00111111，那么低六位為一個位元組，高兩位為另一個位元組。
對於一個byte數組按照高低位元組的分配，獲取對應數值，通過此數值獲取對應進制相關位置的字元，如16進制中第十個字元為a，那么如果低位元組為10則對應16進制的字元為a，同理，高位元組也對應轉換，最終取得16進制的char數組，此數組轉為String即為我們常見的16進制的字元串。
我的64進制的實現代碼如下：
byte數組轉換為64進制char數組
public static char[] encode64Digit(byte[] bytes) {
char[] out = new char[bytes.length << 1];
for (int i = 0, j = 0; i < bytes.length; i++) {
out[j++] = digits64[(0xC0 & bytes[i]) >>> 6];
out[j++] = digits64[0x3F & bytes[i]];
}
return out;
}
64進制char數組轉換為byte數組
public static byte[] decode64Digit(char[] chars) {
if ((0x01 & chars.length) != 0) {
return null;
}
byte[] out = new byte[chars.length >> 1];
for (int i = 0, j = 0; j < chars.length; i++) {
int a = (getSize(chars[j]) << 6);
j++;
int b = getSize(chars[j]) & 0xFF;
a = (a | getSize(chars[j]));
j++;
out[i] = (byte) (a & 0xFF);
}
return out;
}
