android base64 + %2b,关于Base64的一些理解

博客讲述了在对接客户接口时遇到的Base64编码问题,客户将标准Base64的+和/替换为-和_,导致签名验证失败。文章强调了检查Base64编码格式的重要性,并介绍了Base64编码的基本原理,以及在URL中使用Base64-URL编码的原因。
摘要由CSDN通过智能技术生成

昨天对接一个客户的接口, 踩了一些坑, 和 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

/

下面来看一个示例

95ca6754b8263f9ca3161440ea48a4d6.png

第一步,”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 类似这种(被转成什么 这个和当前的文件编码有关系的)

这些会给存储数据库 解码等造成歧义

所以有些处理就是把 + 和 / 分别改成了 - 和 _ 来传输

我遇到的就是这种情况 希望大家以后可以注意下这个格式!

致谢

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值