關於Base64的一些理解

reggie發表於2021-08-09

事件起因

最近對接了一個客戶的平臺，中間有接受非同步通知驗證簽名的一個環節，結果拿到對方的簽名後 怎麼都校驗不通過，無奈請求對方協助。最終發現是對方發來的 簽名有問題 正常簽名都會進行 base64 轉碼後再傳送出去，但是對方將標準Base64中的 + 和 / 分別改成了 - 和 _文件上也沒有明確宣告處理過了這些東西，而我拿到簽名後也沒有注意過簽名的格式是否正確 直接進行了 base64_decode 所以導致最終怎麼驗證簽名都不正確。

Base64 編碼

Base64編碼是一種可以將任意二進位制資料轉到文字字串的編碼方法

由於 2^{6}=64}，所以每6個位元為一個單元，對應某個可列印字元。

3個位元組有24個位元，對應於4個Base64單元，即3個位元組可由4個可列印字元來表示。

常用在傳輸少量的二進位制資料 比如 郵件, URL, Cookie, 網頁 中

在Base64中可列印的字元 包括 A-Z, a-z, 0-9, 這樣共有62個字元

此外還剩下的兩個可列印符號在不同的系統中而不同

在MIME格式的電子郵件中，Base64可以用來將binary的位元組序列資料編碼成ASCII字元序列構成的文字。

使用時，在傳輸編碼方式中指定Base64, 使用的字元包括大小寫拉丁字母各26個、數字10個、加號 + 和斜槓 / ,共64個字元, 等號 = 用來作為字尾用途

這種也是我們現在常用的了

另外 Base64 轉碼後的長度會比原文增加 33% 左右 不太適合太長資料的傳輸

Base64 索引表

數值 字元 數值 字元 數值 字元 數值 字元
0 A 16 Q 32 g 48 w
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /

下面來看一個示例

base64--Man解析

第一步，”M”、”a”、”n”的ASCII值分別是77、97、110，對應的二進位制值是01001101、01100001、01101110，將它們連成一個24位的二進位制字串010011010110000101101110。

第二步，將這個24位的二進位制字串分成4組，每組6個二進位制位：010011、010110、000101、101110。

第三步，在每組前面加兩個00，擴充套件成32個二進位制位，即四個位元組：00010011、00010110、00000101、00101110。它們的十進位制值分別是19、22、5、46。

第四步，根據上表，得到每個值對應Base64編碼，即T、W、F、u。

因此，Man的Base64編碼就是TWFu。

Base64 - URL

有時候我們可能需要在 URL 傳遞資訊 如果使用 Base64 轉碼的話

其中的 + 和 / 會被轉換成 %2b 和 %2f 類似這種(被轉成什麼 這個和當前的檔案編碼有關係的)

這些會給儲存資料庫 解碼等造成歧義

所以有些處理就是把 + 和 / 分別改成了 - 和 _ 來傳輸

我遇到的就是這種情況 希望大家以後可以注意下這個格式！

本作品採用《CC 協議》，轉載必須註明作者和本文連結
鐵甲依然在

相關文章