昨天对接一个客户的接口, 踩了一些坑, 和 base64 有关, 顺便补了下 有关 Base64 的一些知识
事件起因
最近对接了一个客户的平台
中间有接受异步通知验证签名的一个环节
结果拿到对方的签名后 怎么都校验不通过
无奈请求对方协助
最终发现是对方发来的 签名有问题 正常签名都会进行 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 类似这种(被转成什么 这个和当前的文件编码有关系的)
这些会给存储数据库 解码等造成歧义
所以有些处理就是把 + 和 / 分别改成了 - 和 _ 来传输
我遇到的就是这种情况 希望大家以后可以注意下这个格式!
致谢