Base64（基底 64）是一種基於 64 個可列印字元來表示二進位制資料的表示方法。由於，所以每 6 個位元為一個單元，對應某個可列印字元。3 個位元組相當於 24 個位元，對應於 4 個 Base64 單元，即 3 個位元組可由 4 個可列印字元來表示。在 Base64 中的可列印字元包括字母 AZ、az、數字 09，這樣共有 62 個字元，此外兩個可列印符號在不同的系統中而不同。一些如 uuencode 的其他編碼方法，和之後的版本使用不同的 64 字元集來代表 6 個二進位制數字，但是不被稱為 Base64。 Base64 常用於在通常處理文字資料的場合，表示、傳輸、儲存一些二進位制資料，包括 MIME 的電子郵件及 XML 的一些複雜資料。 RFC 4648 標準的 Base64 索引表 十進位制 二進位制 字元 十進位制 二進位制 字元 十進位制 二進位制 字元 十進位制 二進位制 字元 0 000000 A 16 010000 Q 32 100000 g 48 110000 w 1 000001 B 17 010001 R 33 100001 h 49 110001 x 2 000010 C 18 010010 S 34 100010 i 50 110010 y 3 000011 D 19 010011 T 35 100011 j 51 110011 z 4 000100 E 20 010100 U 36 100100 k 52 110100 0 5 000101 F 21 010101 V 37 100101 l 53 110101 1 6 000110 G 22 010110 W 38 100110 m 54 110110 2 7 000111 H 23 010111 X 39 100111 n 55 110111 3 8 001000 I 24 011000 Y 40 101000 o 56 111000 4 9 001001 J 25 011001 Z 41 101001 p 57 111001 5 10 001010 K 26 011010 a 42 101010 q 58 111010 6 11 001011 L 27 011011 b 43 101011 r 59 111011 7 12 001100 M 28 011100 c 44 101100 s 60 111100 8 13 001101 N 29 011101 d 45 101101 t 61 111101 9 14 001110 O 30 011110 e 46 101110 u 62 111110 15 001111 P 31 011111 f 47 101111 v 63 111111 填充 填充 示例 舉例來說，一段引用自托馬斯霍布斯《利維坦》的文句： 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」的結果為，詳細原理如下： 文字 M M M M M M M M a a a a a a a a n n n n n n n n ASCII 編碼 77 77 77 77 77 77 77 77 97 97 97 97 97 97 97 97 110 110 110 110 110 110 110 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 19 19 19 19 19 22 22 22 22 22 22 5 5 5 5 5 5 46 46 46 46 46 46 Base64 編碼 T T T T T T W W W W W W F F F F F F u u u u u u 在此例中，Base64 演算法將 3 個位元組編碼為 4 個字元。 如果要編碼的位元組數不能被 3 整除，最後會多出 1 個或 2 個位元組，那麼可以使用下面的方法進行處理：先使用 0 位元組值在末尾補足，使其能夠被 3 整除，然後再進行 Base64 的編碼。在編碼後的 Base64 文字後加上一個或兩個 號，代表補足的位元組數。也就是說，當最後剩餘兩個八位 待補足 位元組（2 個 byte）時，最後一個 6 位的 Base64 位元組塊有四位是 0 值，最後附加上兩個等號；如果最後剩餘一個八位 待補足 位元組（1 個 byte）時，最後一個 6 位的 base 位元組塊有兩位是 0 值，最後附加一個等號。 參考下表： 文字（1 Byte） A A A A A A A A 二進位制位 0 1 0 0 0 0 0 1 0 0 0 0 二進位制位（補 0） 0 1 0 0 0 0 0 1 0 0 0 0 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 Base64 編碼 Q Q Q Q Q Q Q Q Q Q Q Q 文字（2 Byte） B B B B B B B B C C C C C C C C 二進位制位 0 1 0 0 0 0 1 0 0 1 0 0 0 0 1 1 0 0 二進位制位（補 0） 0 1 0 0 0 0 1 0 0 1 0 0 0 0 1 1 0 0 留空填充 留空填充 留空填充 留空填充 留空填充 留空填充 Base64 編碼 Q Q Q Q Q Q k k k k k k M M M M M M 應用 變種 base64 編碼對應的 64 個可列印字元在一些特定的程式或協議中可能不適合使用，特別是字元表第 62 位、63 位和填充字元，因此存在一些如下的變種： 編碼 編碼字元 編碼字元 編碼字元 換行的處理 換行的處理 換行的處理 是否解碼非編碼字元 編碼 第 62 位 第 63 位 填充 分隔符 行字元數 校驗和 是否解碼非編碼字元 ：用於隱私增強電郵的 Base64（已棄用） ：用於 MIME 的 Base64 用於 UTF7 的 Base64 colspan3 ：用於 IMAP 協議郵箱命名的 Base64 colspan3 ：標準 base64 colspan3 ：base64url（URL 和檔名安全標準） _ colspan3 ：用於 OpenPGP 的 Radix64 MIME 在 MIME 格式的電子郵件中，Base64 可以用來將 binary 的位元組序列資料編碼成 ASCII 字元序列構成的文字。使用時，在傳輸編碼方式中指定 Base64。使用的字元包括大小寫拉丁字母各 26 個、數字 10 個、加號 和斜槓 ，共 64 個字元，等號 用來作為填充用途。 完整的 Base64 定義可見 RFC 1421 和 RFC 2045。編碼後的資料比原始資料略長，為原來的 frac 43。在電子郵件中，根據 RFC 822 規定，每 76 個字元，還需要加上一個回車換行。可以估算編碼後資料長度大約為原長的 1351。 轉換的時候，將 3 位元組的資料，先後放入一個 24 位元的緩衝區中，先來的位元組佔高位。資料不足 3 位元組的話，於緩衝區中剩下的位元用 0 補足。每次取出 6 位元（因為 2 6 64），按照其值選擇 ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789 中的字元作為編碼後的輸出，直到全部輸入資料轉換完成。 若原資料長度不是 3 的倍數時且剩下 1 個輸入資料，則在編碼結果後加 2 個 ；若剩下 2 個輸入資料，則在編碼結果後加 1 個 。 IRCu 在等軟體所使用的 P10 IRC 伺服器間協議中，對客戶與伺服器的訊息型別號（clientserver numerics）和二進位制 IP 地址採用了 Base64 編碼。訊息型別號的長度固定為 3 位元組，故可直接編碼為 4 個位元組而不需要加填充。對 IP 地址進行編碼時，則需要在地址前新增一些 0 位元，使之可以編碼為整數個位元組。這裡所用的符號集與前述 MIME 的也有所不同，將 改成了 。 UTF7 UTF7 是一個修改版 Base64（Modified Base64）。主要是將 UTF16 的資料，用 Base64 的方法編碼為可列印的 ASCII 字元序列。目的是傳輸 Unicode 資料。主要的區別在於不用等號 補餘，因為該字元通常需要大量的轉譯。 標準可見 RFC 2152，《A MailSafe Transformation Format of Unicode》。 URL Base64 編碼可用於在 HTTP 環境下傳遞較長的標識資訊。例如，在 Java 持久化系統 Hibernate 中，就採用了 Base64 來將一個較長的唯一識別符號（一般為 128bit 的 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 的訊息。 在檔案，Base64 用作編碼字串。 相關事件 2018 年 2 月電子郵件程式 發現重大漏洞，編號為 CVE20186789 的緩衝區溢位漏洞允許攻擊者在伺服器上遠端執行惡意程式碼。漏洞位於 base64 解碼函式中，影響 Exim v4901 之前的所有版本，多達 40 萬伺服器受到影響。 參見 Base58 Quotedprintable uuencode 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 Online Base64 Decoding 線上 Base64 編碼 線上 Base64 解碼 線上 Base64 編碼 Category 標準 Category 檔案格式 Category 資料序列化格式