Loading AI tools
一種編碼方式 来自维基百科,自由的百科全书
Base64(基底64)是一種基於64個可列印字元來表示二進位資料的表示方法。由於,所以每6個位元為一個單元,對應某個可列印字元。3個位元組相當於24個位元,對應於4個Base64單元,即3個位元組可由4個可列印字元來表示。在Base64中的可列印字元包括字母A-Z
、a-z
、數字0-9
,這樣共有62個字元,此外兩個可列印符號在不同的系統中而不同。一些如uuencode的其他編碼方法,和之後BinHex的版本使用不同的64字元集來代表6個二進位數字,但是不被稱為Base64。
Base64常用於在通常處理文字資料的場合,表示、傳輸、儲存一些二進位資料,包括MIME的電子郵件及XML的一些複雜資料。
十進位 | 二進位 | 字元 | 十進位 | 二進位 | 字元 | 十進位 | 二進位 | 字元 | 十進位 | 二進位 | 字元 | |||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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格式的電子郵件中,Base64可以用來將binary的位元組序列資料編碼成ASCII字元序列構成的文字。使用時,在傳輸編碼方式中指定Base64。使用的字元包括大小寫拉丁字母各26個、數字10個、加號+
和斜槓/
,共64個字元,等號=
用來作為填充用途。
完整的Base64定義可見RFC 1421和RFC 2045。編碼後的資料比原始資料略長,為原來的。在電子郵件中,根據RFC 822規定,每76個字元,還需要加上一個Enter換行。可以估算編碼後資料長度大約為原長的135.1%。
轉換的時候,將3位元組的資料,先後放入一個24位元的緩衝區中,先來的位元組占高位。資料不足3位元組的話,於緩衝區中剩下的位元用0補足。每次取出6位元(因為),按照其值選擇ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
中的字元作為編碼後的輸出,直到全部輸入資料轉換完成。
若原資料長度不是3的倍數時且剩下1個輸入數據,則在編碼結果後加2個=
;若剩下2個輸入數據,則在編碼結果後加1個=
。
在IRCu等軟體所使用的P10 IRC伺服器間協定中,對客戶與伺服器的訊息類型號(client/server numerics)和二進位IP位址採用了Base64編碼。訊息類型號的長度固定為3位元組,故可直接編碼為4個位元組而不需要加填充。對IP位址進行編碼時,則需要在位址前添加一些0位元,使之可以編碼為整數個位元組。這裡所用的符號集與前述MIME的也有所不同,將+/
改成了[]
。
UTF-7是一個修改版Base64(Modified Base64)。主要是將UTF-16的資料,用Base64的方法編碼為可列印的ASCII字元序列。目的是傳輸Unicode資料。主要的區別在於不用等號=
補餘,因為該字元通常需要大量的轉譯。
標準可見 RFC 2152,《A Mail-Safe Transformation Format of Unicode》。
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)。