Base64的由來
目前Base64已經成為網絡上常見的傳輸8Bit字節代碼的編碼方式之一。在做支付系統時,系統之間的報文交互都需要使用Base64對明文進行轉碼,然后再進行簽名或加密,之后再進行(或再次Base64)傳輸。那么,Base64到底起到什么作用呢?
在參數傳輸的過程中經常遇到的一種情況:使用全英文的沒問題,但一旦涉及到中文就會出現亂碼情況。與此類似,網絡上傳輸的字符并不全是可打印的字符,比如二進制文件、圖片等。Base64的出現就是為了解決此問題,它是基于64個可打印的字符來表示二進制的數據的一種方法。
電子郵件剛問世的時候,只能傳輸英文,但后來隨著用戶的增加,中文、日文等文字的用戶也有需求,但這些字符并不能被服務器或網關有效處理,因此Base64就登場了。隨之,Base64在URL、Cookie、網頁傳輸少量二進制文件中也有相應的使用。
Base64的編碼原理
Base64的原理比較簡單,每當我們使用Base64時都會先定義一個類似這樣的數組:
['A', 'B', 'C', ... 'a', 'b', 'c', ... '0', '1', ... '+', '/']
上面就是Base64的索引表,字符選用了”A-Z、a-z、0-9、+、/” 64個可打印字符,這是標準的Base64協議規定。在日常使用中我們還會看到“=”或“==”號出現在Base64的編碼結果中,“=”在此是作為填充字符出現,后面會講到。
具體轉換步驟
第一步,將待轉換的字符串每三個字節分為一組,每個字節占8bit,那么共有24個二進制位。
第二步,將上面的24個二進制位每6個一組,共分為4組。
第三步,在每組前面添加兩個0,每組由6個變為8個二進制位,總共32個二進制位,即四個字節。
第四步,根據Base64編碼對照表(見下圖)獲得對應的值。
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w
15 P 32 g 49 x
16 Q 33 h 50 y
從上面的步驟我們發現:
- Base64字符表中的字符原本用6個bit就可以表示,現在前面添加2個0,變為8個bit,會造成一定的浪費。因此,Base64編碼之后的文本,要比原文大約三分之一。
- 為什么使用3個字節一組呢?因為6和8的最小公倍數為24,三個字節正好24個二進制位,每6個bit位一組,恰好能夠分為4組。
示例說明
以下圖的表格為示例,我們具體分析一下整個過程。
- 第一步:“M”、“a”、”n”對應的ASCII碼值分別為77,97,110,對應的二進制值是01001101、01100001、01101110。如圖第二三行所示,由此組成一個24位的二進制字符串。
- 第二步:如圖紅色框,將24位每6位二進制位一組分成四組。
- 第三步:在上面每一組前面補兩個0,擴展成32個二進制位,此時變為四個字節:00010011、00010110、00000101、00101110。分別對應的值(Base64編碼索引)為:19、22、5、46。
- 第四步:用上面的值在Base64編碼表中進行查找,分別對應:T、W、F、u。因此“Man”Base64編碼之后就變為:TWFu。
位數不足情況
上面是按照三個字節來舉例說明的,如果字節數不足三個,那么該如何處理?
- 兩個字節:兩個字節共16個二進制位,依舊按照規則進行分組。此時總共16個二進制位,每6個一組,則第三組缺少2位,用0補齊,得到三個Base64編碼,第四組完全沒有數據則用“=”補上。因此,上圖中“BC”轉換之后為“QKM=”;
- 一個字節:一個字節共8個二進制位,依舊按照規則進行分組。此時共8個二進制位,每6個一組,則第二組缺少4位,用0補齊,得到兩個Base64編碼,而后面兩組沒有對應數據,都用“=”補上。因此,上圖中“A”轉換之后為“QQ==”;
注意事項
- 大多數編碼都是由字符串轉化成二進制的過程,而Base64的編碼則是從二進制轉換為字符串。與常規恰恰相反,
- Base64編碼主要用在傳輸、存儲、表示二進制領域,不能算得上加密,只是無法直接看到明文。也可以通過打亂Base64編碼來進行加密。
- 中文有多種編碼(比如:utf-8、gb2312、gbk等),不同編碼對應Base64編碼結果都不一樣。
轉自:https://blog.csdn.net/wo541075754/article/details/81734770