Base64 是我们常用的编码方式，广泛用于邮件编码、数据签名/数据校验编码以及HTML/XML复杂数据编码。这本来是一个花两分钟了解一下就无需关注的技术，但是最近线上遇到一个相关问题。于是重新梳理了一下 Base64, 发现了一些以前未曾注意到的细节，记录如下，希望对你也有帮助。
Base64 是什么？
Base64 是一种将二进制数据表示为可打印字符的编码方法。基本操作是将3个字节编码为4个 Base64 单元：3 * 8 bit = 4 * 6 bit. 这种编码方法常用于处理文本数据的场合，例如在 HTML/XML 中表示、传输、存储一些二进制数据（如数据签名、数据校验等）。Base64 编码后数据增长为原来的 4/3 ≈ 1.33 倍。相较于将二进制数据按照十六进制输出数据增长为原来2倍，Base64 更加节省空间。Base64 的标准是 RFC 4648，如果你不想直接阅读这个拗口啰嗦的RFC，可以继续往下看。
Base64 不是什么？
Base64 不是一种加密方式，因此它不提供任何安全特性。我们在论坛、个人博客中发现很多人使用 Base64 编码显示自己邮箱主要是避免被搜索引擎及其他批量化工具发现和索引。
Base64 编码结果是唯一的吗？
不是的。Base64 根据编码字典表不同以及是否 padding (使用=作为 padding 字符)，对同一数据的编码结果可能不同。使用最多的字典表有两个：
Table 1: The Base 64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
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 (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Table 2: The "URL and Filename safe" Base 64 Alphabet
Value Encoding Value Encoding Value Encoding Value Encoding
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 - (minus)
12 M 29 d 46 u 63 _
13 N 30 e 47 v (underline)
14 O 31 f 48 w
15 P 32 g 49 x
16 Q 33 h 50 y (pad) =
这两个字典表的区别主要是 62 和 63 使用的字符不同（我们将这两个字符称为特殊字符）。因此，对于同一数据最多可能有 2 * 2 = 4 种编码结果。以 0x0F0xF1(2 bytes)为例，有以下4种编码结果：
- 字典表1 + padding:
D/E= - 字典表1 + nopadding:
D/E - 字典表2 + padding:
D_E= - 字典表2 + nopadding:
D_E
这种一个数据有多个编码结果的情况，往往会给我们解码带来困扰。因此，在使用 Base64 的场景中，务必在文档中注明你是使用的哪一个字典表以及是否需要 padding. 当然，国内环境对文档普遍不够重视，在这么小的技术点上写如此细致是不敢奢望的，有一条有用的经验是：在没有特殊说明的情况下，技术文档中的 Base64 一般是指 字典表1 + padding.
Base64 是 url/filename safe 的吗？
如上所诉，我们默认的 Base64 编码使用的是字典表1，而这个字典表中的字符 + 和 / 无论是在url还是文件系统中都是特殊字符。因此，基于字典表1的Base64编码不是 url/filename safe 的，不能将该 Base64 编码直接与url拼接或用来命名文件。基于字典表2的 Base64 编码是 url/filename safe 的。但它不是我们大部分编程语言的默认字典，因此，你如果选择这个字典进行 Base64 编码，在解码时也选择该字典。否则你有很大概率会遇到部分数据能解码，部分数据不能解码的问题。
Base64 可以自定义特殊字符吗？
字典表2使用了不一样的 62 和 63 特殊字符以实现 url/filename safe. 但这可能无法满足所有应用场景。因此根据 RFC, 你是可以自定义这两个特殊字符建立自己的字典表的。有一点需要注意，如果你使用了自定义字典表，那么请确保自己编码和解码使用的字典表是一致的。
Base64 编码结果中的等号（=）可以省略吗？是多余的设计吗？
可以省略，但不是多余的设计。
我们先看为何可以省略：
对于数据 A, 如果我们省略padding的等号，解码的时候我们从QQ是可以推断出来，原始数据长度必然是1 byte, 因此可以可以正确解码。数据 BC 同理。
既然 padding 的等号完全不影响解码，是否可以取消这个设计呢？答案是否定的。对于一些将多个Base64编码拼接在一起的场景，padding的等号可以标记一个 Base64 编码单元的边界，使得拼接后的 Base64 编码整体是可以无歧义正确解码的。如果省略等号，则无法保证无歧义性。我们看一个例子：
IBase64编码为SQ(SQ==with padding)AMBase64编码为QU0(QU0=with padding)DanielBase64编码为RGFuaWVs(RGFuaWVswith padding)
如果使用省略等号的方式，拼接后的Base64编码是 SQQU0RGFuaWVs, 因为我们无法区分边界，我们只能对整个字符串进行解码，显然解码结果是不正确的。如果我们不省略等号，则拼接后的编码 SQ==QU0=RGFuaWVs 可以根据等号区分边界，然后分块正确解码。
扩展阅读
- The Base16, Base32, and Base64 Data Encodings
- Why does Base64 encoding require padding if the input length is not divisible by 3?
- UTF8 characters in HTTP headers
–EOF–
转载请注明出处，本文原始链接