记一个 Base64 有关的 Bug

本文原计划写两部分内容,第一是记录最近遇到的与 Base64 有关的 Bug,第二是 Base64 编码的原理详解。结果写了一半发现,诶?不复杂的一个事儿怎么也要讲这么长?不利于阅读和理解啊(其实是今天有点懒想去休闲娱乐会儿),所以 Base64 编码的原理详解的部分将在下一篇带来,敬请关注。

0x01 遇到的现象

A 向 B 提供了一个接口,约定接口参数 Base64 编码后传递。

但 A 对 B 传递的参数进行 Base64 解码时报错了:

Illegal base64 character a

0x02 原因分析

搜索后发现这是一个好多网友们都踩过的坑,简而言之就一句话:Base64 编/解码器有不同实现,有的不相互兼容。

比如我上面遇到的现象,可以使用下面这段代码完整模拟复现:

package org.mazhuang.base64test;

import org.springframework.boot.CommandLineRunner;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.util.Base64Utils;
import sun.misc.BASE64Encoder;

@SpringBootApplication
public class Base64testApplication implements CommandLineRunner {
    @Override
    public void run(String... args) throws Exception {
        byte[] content = "It takes a strong man to save himself, and a great man to save another.".getBytes();
        String encrypted = new BASE64Encoder().encode(content);
        byte[] decrypted = Base64Utils.decodeFromString(encrypted);
        System.out.println(new String(decrypted));
    }

    public static void main(String[] args) {
        SpringApplication.run(Base64testApplication.class, args);
    }

}

以上代码执行会报异常:

Caused by: java.lang.IllegalArgumentException: Illegal base64 character a
    at java.util.Base64$Decoder.decode0(Base64.java:714) ~[na:1.8.0_202-release]
    at java.util.Base64$Decoder.decode(Base64.java:526) ~[na:1.8.0_202-release]

注: 测试代码里的那个字符串如果很短,比如「Hello, World」这种,可以正常解码。

也就是说,用 sun.misc.BASE64Encoder 编码,用 org.springframework.util.Base64Utils 进行解码,是有问题的,我们可以用它俩分别对以上符串进行编码,然后输出看看差异。测试代码:

byte[] content = "It takes a strong man to save himself, and a great man to save another.".getBytes();

System.out.println(new BASE64Encoder().encode(content));
System.out.println("--- 华丽的分隔线 ---");
System.out.println(Base64Utils.encodeToString(content));

输出:

SXQgdGFrZXMgYSBzdHJvbmcgbWFuIHRvIHNhdmUgaGltc2VsZiwgYW5kIGEgZ3JlYXQgbWFuIHRv
IHNhdmUgYW5vdGhlci4=
--- 华丽的分隔线 ---
SXQgdGFrZXMgYSBzdHJvbmcgbWFuIHRvIHNhdmUgaGltc2VsZiwgYW5kIGEgZ3JlYXQgbWFuIHRvIHNhdmUgYW5vdGhlci4=

可以看到 sun.misc.BASE64Encoder 编码后的内容换行了,而换行符的 ASCII 编码正好是 0x0a,如此貌似解释得通了。让我们进一步跟踪一下,找一下出现这种差异的源头。

0x03 更进一步

在 IDEA 里按住 CTRL 或 COMMAND 键点击方法名,可以跳转到它们的实现。

3.1 sun.misc.BASE64Encoder.encode

这种写法主要涉及到两个类,sun.misc 包下的 BASE64Encoder 和 CharacterEncoder,其中后者是前者的父类。

它实际工作的 encode 方法是在 CharacterEncoder 文件里,带注释版如下:


public void encode(InputStream inStream, OutputStream outStream)
    throws IOException {
    int     j;
    int     numBytes;
    // bytesPerLine 在 BASE64Encoder 里实现,返回 57
    byte    tmpbuffer[] = new byte[bytesPerLine()];

    // 用 outStream 构造一个 PrintStream
    encodeBufferPrefix(outStream);

    while (true) {
        // 读取最多 57 个 bytes
        numBytes = readFully(inStream, tmpbuffer);
        if (numBytes == 0) {
            break;
        }
        // 啥也没干
        encodeLinePrefix(outStream, numBytes);
        // 每次处理 3 bytes,编码成 4 bytes,不足位的补 0 位和 '='
        for (j = 0; j < numBytes; j += bytesPerAtom()) {
            // ...
        }
        if (numBytes < bytesPerLine()) {
            break;
        } else {
            // 换行
            encodeLineSuffix(outStream);
        }
    }
    // 啥也没干
    encodeBufferSuffix(outStream);
}

然后在 CharacterEncoder 类的注释里我们可以看到编码后的格式:

[Buffer Prefix]
[Line Prefix][encoded data atoms][Line Suffix]
[Buffer Suffix]

而结合 BASE64Encoder 这个实现类来看,Buffer Prefix、Buffer Suffix 和 Line Prefix 都为空,Line Suffix 为 \n

至此,我们已经找到实现中换行的部分——这个编码器实现里,读取 57 个 byte 作为一行进行编码(编码完成后是 76 个 byte)。

3.2 org.springframework.util.Base64Utils.encodeToString

这种写法主要涉及到 org.springframework.util.Base64Utils 和 java.util.Base64 两个类,可以看到前者主要是后者的封装。

Base64Utils.encodeToString 这种写法最终用到的是 Base64.Encoder.RFC4648 这种编码器:

// isURL = false,newline = null,linemax = -1,doPadding = true
static final Encoder RFC4648 = new Encoder(false, null, -1, true);

留意 newline 和 linemax 的值。

然后看实际的编码实现所在的 Base64.encode0 方法:

private int encode0(byte[] src, int off, int end, byte[] dst) {
    // ...
    while (sp < sl) {
        // ...

        // 这个条件不会满足,不会加换行
        if (dlen == linemax && sp < end) {
            for (byte b : newline){
                dst[dp++] = b;
            }
        }
    }
    // ...
    return dp;
}

所以……这个实现里没有换行。

0x04 小结

经过以上的分析,真相已经大白了,就是两个编码器的实现不一样,我们在开发过程中注意使用匹配的编码解码器就 OK 了,就是用哪个 Java 包下面的编码器编码,就用相同包下的对应解码器解码。

至于为啥会出现不一样的实现,它们之间有过什么来龙去脉、恩怨情仇,Base64 的详细原理等等,就厚着老脸,邀请大家且听下回分解吧!:-P

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335