Base64

Base64（基底64）是一種基於64個可列印字元來表示二進制資料的表示方法。由於 $\log _{2}64=6$ ，所以每6個位元為一個單元，對應某個可列印字元。3個位元組相當於24個位元，對應於4個Base64單元，即3個位元組可由4個可列印字元來表示。在Base64中的可列印字元包括字母A-Z、a-z、數字0-9，這樣共有62個字元，此外兩個可列印符號在不同的系統中而不同。一些如uuencode的其他編碼方法，和之後BinHex（英語：BinHex）的版本使用不同的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編碼之後變成：

TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vdCBvbmx5IGJ5IGhpcyByZWFzb24sIGJ1dCBieSB0aGlzIHNpbmd1bGFyIHBhc3Npb24gZnJvbSBvdGhlciBhbmltYWxzLCB3aGljaCBpcyBhIGx1c3Qgb2YgdGhlIG1pbmQsIHRoYXQgYnkgYSBwZXJzZXZlcmFuY2Ugb2YgZGVsaWdodCBpbiB0aGUgY29udGludWVkIGFuZCBpbmRlZmF0aWdhYmxlIGdlbmVyYXRpb24gb2Yga25vd2xlZGdlLCBleGNlZWRzIHRoZSBzaG9ydCB2ZWhlbWVuY2Ugb2YgYW55IGNhcm5hbCBwbGVhc3VyZS4=

編碼「Man」的結果為TWFu，詳細原理如下：

文字	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演算法將3個位元組編碼為4個字元。

如果要編碼的位元組數不能被3整除，最後會多出1個或2個位元組，那麼可以使用下面的方法進行處理：先使用0位元組值在末尾補足，使其能夠被3整除，然後再進行Base64的編碼。在編碼後的Base64文字後加上一個或兩個=號，代表補足的位元組數。也就是說，當最後剩餘兩個八位(待補足)位元組（2個byte）時，最後一個6位的Base64位元組塊有四位是0值，最後附加上兩個等號；如果最後剩餘一個八位(待補足)位元組（1個byte）時，最後一個6位的base位元組塊有兩位是0值，最後附加一個等號。參考下表：

文字（1 Byte）	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						=						=
文字（2 Byte）	B								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						k						M						=

應用

變種

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

編碼	編碼字元			換行的處理			是否解碼非編碼字元
編碼	第62位	第63位	填充	分隔符	行字元數	校驗和	是否解碼非編碼字元
RFC 1421：用於隱私增強電子郵件的Base64（已棄用）	`+`	`/`	`=` 強制	CR+LF	64，末尾行可少於64	否	否
RFC 2045：用於MIME的Base64	`+`	`/`	`=` 強制	CR+LF	上限 76	否	棄用
RFC 2152: 用於UTF-7的Base64	`+`	`/`	否	否			否
RFC 3501：用於IMAP協定電子信箱命名的Base64	`+`	`,`	否	否			否
RFC 4648 §4：標準base64	`+`	`/`	`=` 可選	否			否
RFC 4648 §5：base64url（URL和檔名安全標準）	`-`	`_`	`=` 可選	否			否
RFC 4880：用於OpenPGP的Radix-64	`+`	`/`	`=` 強制	CR+LF	上限 76	Radix-64編碼24位元CRC	否

MIME

在MIME格式的電子郵件中，Base64可以用來將binary的位元組序列資料編碼成ASCII字元序列構成的文字。使用時，在傳輸編碼方式中指定Base64。使用的字元包括大小寫拉丁字母各26個、數字10個、加號+和斜槓/，共64個字元，等號=用來作為填充用途。

完整的Base64定義可見RFC 1421和RFC 2045。編碼後的資料比原始資料略長，為原來的 ${\frac {4}{3}}$ 。在電子郵件中，根據RFC 822規定，每76個字元，還需要加上一個Enter換行。可以估算編碼後資料長度大約為原長的135.1%。

轉換的時候，將3位元組的資料，先後放入一個24位元的緩衝區中，先來的位元組占高位。資料不足3位元組的話，於緩衝區中剩下的位元用0補足。每次取出6位元（因為 $2^{6}=64$ ），按照其值選擇ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/中的字元作為編碼後的輸出，直到全部輸入資料轉換完成。

若原資料長度不是3的倍數時且剩下1個輸入數據，則在編碼結果後加2個=；若剩下2個輸入數據，則在編碼結果後加1個=。

IRCu

在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（英語：LDIF）檔案，Base64用作編碼字串。

參見

Base58
Radix-64（英語：Radix-64）
Ascii85（英語：Ascii85）
Quoted-printable
uuencode
yEnc（英語：yEnc）
8BITMIME（英語：8BITMIME）
URL

參考資料

^ 存档副本. [2018-03-07]. （原始內容存檔於2018-07-23）.
^ 存档副本. [2018-03-07]. （原始內容存檔於2018-03-08）.

外部連結

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編碼

[1] 存档副本. [2018-03-07]. （原始內容存檔於2018-07-23）.

[2] 存档副本. [2018-03-07]. （原始內容存檔於2018-03-08）.

[1]

[2]