Base64

Base64（基底64）是一種基於64個可打印字符來表示二進制數據的表示方法。由於log(2,64)，所以每6個位元為一個單元，對應某個可打印字符。3個字節相當於24個位元，對應於4個Base64單元，即3個字節可由4個可打印字符來表示。在Base64中的可打印字符包括字母A-Z、a-z、數字0-9，這樣共有62個字符，此外兩個可打印符號在不同的系統中而不同。一些如uuencode的其他編碼方法，和之後BinHex的版本使用不同的64字符集來代表6個二進制數字，但是不被稱為Base64。
Base64常用於在通常處理文本數據的場合，表示、傳輸、存儲一些二進制數據，包括MIME的電子郵件及XML的一些複雜數據。

**RFC 4648 標準的 Base64 索引表**

**示例**
舉例來說，一段引用自托馬斯·霍布斯《利維坦》的文句：
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編碼之後變成：
編碼「Man」的結果為Man，詳細原理如下：
在此例中，Base64算法將3個字節編碼為4個字符。
如果要編碼的字節數不能被3整除，最後會多出1個或2個字節，那麼可以使用下面的方法進行處理：先使用0字節值在末尾補足，使其能夠被3整除，然後再進行Base64的編碼。在編碼後的Base64文本後加上一個或兩個=號，代表補足的字節數。也就是說，當最後剩餘兩個八位(待補足)字節（2個byte）時，最後一個6位的Base64字節塊有四位是0值，最後附加上兩個等號；如果最後剩餘一個八位(待補足)字節（1個byte）時，最後一個6位的base字節塊有兩位是0值，最後附加一個等號。
參考下表：

**應用**

**變種**
base64編碼對應的64個可打印字符在一些特定的程序或協議中可能不適合使用，特別是字符表第62位（+）、63位（/）和填充字符（=），因此存在一些如下的變種：

**MIME**
在MIME格式的電子郵件中，Base64可以用來將binary的字節序列數據編碼成ASCII字符序列構成的文本。使用時，在傳輸編碼方式中指定Base64。使用的字符包括大小寫拉丁字母各26個、數字10個、加號+和斜槓/，共64個字符，等號=用來作為填充用途。
完整的Base64定義可見RFC 1421和RFC 2045。編碼後的數據比原始數據略長，為原來的。在電子郵件中，根據RFC 822規定，每76個字符，還需要加上一個回車換行。可以估算編碼後數據長度大約為原長的135.1%。
轉換的時候，將3字節的數據，先後放入一個24位元的緩衝區中，先來的字節佔高位。數據不足3字節的話，於緩衝區中剩下的位元用0補足。每次取出6位元（因為），按照其值選擇ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/中的字符作為編碼後的輸出，直到全部輸入數據轉換完成。
若原數據長度不是3的倍數時且剩下1個輸入數據，則在編碼結果後加2個=；若剩下2個輸入數據，則在編碼結果後加1個=。

**IRCu**
在IRCu等軟件所使用的P10 IRC服務器間協議中，對客戶與服務器的消息類型號（client/server numerics）和二進制IP地址採用了Base64編碼。消息類型號的長度固定為3字節，故可直接編碼為4個字節而不需要加填充。對IP地址進行編碼時，則需要在地址前添加一些0比特，使之可以編碼為整數個字節。這裡所用的符號集與前述MIME的也有所不同，將+/改成了。

**UTF-7**
UTF-7是一個修改版Base64（Modified Base64）。主要是將UTF-16的數據，用Base64的方法編碼為可打印的ASCII字符序列。目的是傳輸Unicode數據。主要的區別在於不用等號=補餘，因為該字符通常需要大量的轉譯。
標準可見 RFC 2152，《A Mail-Safe Transformation Format of Unicode》。

**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）。

**其他**
 垃圾訊息傳播者用Base64來避過反垃圾郵件工具，因為那些工具通常都不會翻譯Base64的訊息。- 在LDIF檔案，Base64用作編碼字串。

**相關事件**
2018年2月電子郵件程序  發現重大漏洞，編號為  CVE-2018-6789 date=20180312033820  的緩衝區溢位漏洞允許攻擊者在服務器上遠程執行惡意代碼。漏洞位於 base64 解碼函數中，影響 Exim v4.90.1 之前的所有版本，多達 40 萬服務器受到影響。

**參見**
  Base58- Radix-64- Ascii85- Quoted-printable- uuencode- yEnc- 8BITMIME- URL

**參考資料**

**外部鏈接**
RFC 1421（Privacy Enhancement for Electronic Internet Mail）
*RFC 2045（MIME）
*RFC 3548（The Base16, Base32, and Base64 Data Encodings）在 RFC 4648 中被替代-  Online Base64 Encoding date=20240220055520 -  Online Base64 Decoding date=20240220055519 -  在線Base64編碼 date=20240220055520 -  在線Base64解碼 date=20240220055519 
在線Base64編碼