魔鬼在细节中:Base64 你可能不知道的几个细节

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) =

这两个字典表的区别主要是 6263 使用的字符不同(我们将这两个字符称为特殊字符)。因此,对于同一数据最多可能有 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使用了不一样的 6263 特殊字符以实现 url/filename safe. 但这可能无法满足所有应用场景。因此根据 RFC, 你是可以自定义这两个特殊字符建立自己的字典表的。有一点需要注意,如果你使用了自定义字典表,那么请确保自己编码和解码使用的字典表是一致的。

Base64 编码结果中的等号(=)可以省略吗?是多余的设计吗?

可以省略,但不是多余的设计。

我们先看为何可以省略:

对于数据 A, 如果我们省略padding的等号,解码的时候我们从QQ是可以推断出来,原始数据长度必然是1 byte, 因此可以可以正确解码。数据 BC 同理。

既然 padding 的等号完全不影响解码,是否可以取消这个设计呢?答案是否定的。对于一些将多个Base64编码拼接在一起的场景,padding的等号可以标记一个 Base64 编码单元的边界,使得拼接后的 Base64 编码整体是可以无歧义正确解码的。如果省略等号,则无法保证无歧义性。我们看一个例子:

  • I Base64编码为 SQ (SQ== with padding)
  • AM Base64编码为 QU0 (QU0= with padding)
  • Daniel Base64编码为 RGFuaWVs (RGFuaWVs with padding)

如果使用省略等号的方式,拼接后的Base64编码是 SQQU0RGFuaWVs, 因为我们无法区分边界,我们只能对整个字符串进行解码,显然解码结果是不正确的。如果我们不省略等号,则拼接后的编码 SQ==QU0=RGFuaWVs 可以根据等号区分边界,然后分块正确解码。

扩展阅读

你应该记住的一个UTF-8字符「EF BF BD」

utf-8是一种变长(1 byte ~ 6 bytes)的unicode字符集编码方案。所谓编码方案即讲字符集到码点(code point)的映射方式。

在众多的utf-8码点值中,除了ascii,你还应该记住「EF BF BD」,因为它是很多编程语言以及库中的备胎,即无效的码点值在编码的时候会默认用这个码点值进行替换,即utf-8中的超级「备胎」(REPLACEMENT CHARACTER)。

为什么会有无效的码点值?

UTF-8 Code Point

从上图可以知道,utf-8编码 并非连续的 。很多人会忽略这个细节。

什么时候会遇到无效的utf-8码点?

当你试图把一个无效的码点值作为utf-8码点处理时,就会产生无效的码点。此时,无效的码点会被替换为「EF BF BD」,然后进行后续处理,以避免无效码点可能引起的异常。很多语言对这种处理是 自动进行 的,比如golang:

为什么要记住这个码点

在「字符集敏感」的环境中,如果你的数据中出现了「EF BF BD」就应该警惕了,因为你传输的数据中途很可能经过了自动替换,收到的数据未必是原始的数据。这对于你排查一些奇怪的数据交换不一致问题是很有用的,很多时候,可能是你的最后一颗救命稻草。

例如,使用utf-8编码的xml文档进行数据交换,如果看见了「�」,毫无疑问数据源有非法码点值。网页中出现了「�」,那么肯定是html文档的编码不是合规的utf-8编码文档。文本编辑器中出现了「�」,那一定是你打开这个文档的姿势不对——又选错编码了。总之,当你看见超级备胎「�」的时候,不要觉得大事不妙,不要像遇到一般乱码那样惊慌失措,你应该轻轻弹一下鼠标上的灰尘,将之打回原形。


因为aws的账单,才意识到自己的vps已经很久没有折腾了,博客也已经长草,应该说已经长成灌木丛了。

这才意识到自己已经回成都快9个月了。

有人说,时间是把杀猪刀。这很公平。但是,即使哪天挨上了这杀猪刀,也希望自己是头优雅的猪。

而此时,2015已经过去1/4.