记一个 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

假如你对我的文章感兴趣,可以关注我的微信公众号『闷骚的程序员』随时阅读更多内容。

原文地址:https://www.cnblogs.com/mazhuang/p/12391119.html

时间: 2024-10-12 07:40:33

记一个 Base64 有关的 Bug的相关文章

记一个很隐蔽的bug

今天,遇到了这样一个问题.这个问题成功的经历了第一轮测试.第二轮测试并成功发布带到线上. 背景 这次测试的内容是一个活动页面,需求的情景是从app内访问链接并进入到这个活动页面,伴随着自动登陆(不需要用户输入用户名和密码,对app的用户登录状态进行获取并进行自动登录). 问题 只有第一次访问活动页面时会返回50x,之后再进入活动页面都不会再返回50x,一切正常. 没能发现问题的原因 因为每天的测试工作要大量的切换hosts,所以很容易出现由于浏览器或app缓存所导致的问题.一般通过刷新.清理缓存

表与表的关系把RD搞乱了,记一个Procedure中的bug

就是6张表的关联查询,写了一个存储过程,使用4层for来处理 bug:最后一个for中,两张表的关联条件少了一个,结果数据多查了. 排查办法:使用dbms_output.printline('');每一个for中加一个 dbms_output.put_line('-3.'||x.name);//把与下层for关联的关键信息打印出来dbms_output.put_line('-2.'||x.name);//把与下层for关联的关键信息打印出来dbms_output.put_line('-1.'||

记一个界面刷新相关的Bug

今天遇到一个比较有意思的bug, 这里简单记录下. Bug的症状是通过拖拉边框把我们客户端主窗口拖小之后,再最大化,会发现窗口显示有问题, 看起来像是刷新问题, 有些地方显示的不对了. 这里要说明的是我这里的主窗口是非常复杂的窗口, 里面集成了很多组件(cpmponent),有很多层的子窗口. 这个问题只有在特定条件下才会发生, 正常情况下都是好的. 遇到这种问题,我们怎么处理? 首先当然是观察症状, 究竟是刷新问题, 还是Layout出错了. 我们可以通过Spy++查看窗口层次是不是正确, 窗

记一个python+sqlalchemy+tornado的一个高并发下,产生重复记录的bug

场景:在用户通过支付通道支付完成返回时,发现我收到的处理数据记录中有两条同样的数据记录, 也就是同一笔钱,我数据库中记为了两条一样的记录. tornado端代码 from tornado import gen from tornado.concurrent import run_on_executor class processNetPay(BaseHandler): '''处理指定订单,指定支付请求,返回处理结果 ' 返回包含订单信息与用户信息体 ''' @tornado.web.asynch

记一个html5 drawImage的问题NS_ERROR_NOT_AVAILABLE:

本地html文件,在firefox下打开,调用到drawImage报错:NS_ERROR_NOT_AVAILABLE. 不能放到桌面,换个目录就好了,路径问题. 记一个html5 drawImage的问题NS_ERROR_NOT_AVAILABLE:,布布扣,bubuko.com

记一个使用Client Object Model上传文件的小例子

1. 新建一个C#的Console project. 2. 给project 添加reference: Microsoft.SharePoint.Client Microsoft.SharePoint.Runtime 3. 修改project的属性: Platform target – x64 Target framework – .NET Framework 4 4. 修改代码如下: using System; using System.IO; using System.Net; using

调bug心得及一个很二的bug

有时候运行结果错误,但是vs没抛异常,这时可以用trycatch来帮我们捕捉异常. 例如:bug的情况是treeview只显示一个根节点和一个子节点,还不报错,我擦~ private void f_script_Load(object sender, EventArgs e) { List<t_scripts> parents = new t_scriptsBLL().getByParentId(0) as List<t_scripts>; try { foreach (t_scr

记一个社交APP的开发过程——基础架构选型(转自一位大哥)

记一个社交APP的开发过程——基础架构选型 目录[-] 基本产品形态 技术选型 最近两周在忙于开发一个社交App,因为之前做过一点儿社交方面的东西,就被拉去做API后端了,一个人头一次完整的去搭这么一套东西,上面也没有PM和各种催促,过程还是很轻松愉快充满乐趣的,现在后端已经基本完成,下周会进入联调测试的阶段,有些东西想写一写记录一下,先从技术选型开始. 基本产品形态 产品的基础功能无非是所有社交App都具备的那些东西,新鲜事.好友关系(同微博一样,单向follow).地理位置(当前的位置.你附

记一个网络传输功能的实现过程

写在前面的话:功能是基于C/S模型的网络传输实现,要求是服务器端可以在局域网中任何机子上运行,客户端启动后自动寻找服务器端进行连接,之后,服务器端向已经连接的客户端发送命令,客户端根据命令执行相应的操作(即发送某个约定文件夹下的所有文件),并且客户端不需要用户操作. 1.思路 首先,对于这个功能的实现思路如下,因为服务器不确定在哪个机子上,所以为了寻找到服务器端,客户端需要发送广播消息,并且为了维护客户端在线,广播消息需要实现成心跳包(即定时发送广播消息).服务器监听心跳包,如果是新加入的客户端