事件起因
最近對接了一個客戶的平臺,中間有接受非同步通知驗證簽名的一個環節,結果拿到對方的簽名後 怎麼都校驗不透過,無奈請求對方協助。最終發現是對方發來的 簽名有問題 正常簽名都會進行 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 | / |
下面來看一個示例
第一步,”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 協議》,轉載必須註明作者和本文連結