Java base64到十六进制不一致的结果

Java base64到十六进制不一致的结果,java,hex,base64,Java,Hex,Base64,昨天,我用java编写了一个单元测试。我正在测试的例程需要将base64转换为十六进制并返回 在我的测试中,我对base64使用了字符串myEvent=。在十六进制中,它变成了9B212F7A7B,但是当我将十六进制转换回base64时,我得到了myEvens= 为什么会这样?我尝试了不同的库和工具,它总是给我这个结果 import java.util.*; import java.lang.*; import javax.xml.bind.DatatypeConverter; class

昨天,我用java编写了一个单元测试。我正在测试的例程需要将base64转换为十六进制并返回

在我的测试中,我对base64使用了字符串
myEvent=
。在十六进制中,它变成了
9B212F7A7B
,但是当我将十六进制转换回base64时,我得到了
myEvens=

为什么会这样?我尝试了不同的库和工具,它总是给我这个结果

import java.util.*;
import java.lang.*;

import javax.xml.bind.DatatypeConverter;

class Rextester
{  
    public static void main(String args[])
    {
        String data1 = "myEvent=";
        String hex1 = convertBase64StringToBase16(data1); // 9B212F7A7B
        String data2 = convertBase16StringtoBase64(hex1); // myEvens=
        String hex2 = convertBase64StringToBase16(data2); // 9B212F7A7B 
        System.out.println("data1=" + data1);
        System.out.println("data2=" + data2);
        System.out.println("hex1=" + hex1);
        System.out.println("hex2=" + hex2);
    }

    private static String convertBase16StringtoBase64(String base16) {
        return Base64.getUrlEncoder().encodeToString(DatatypeConverter.parseHexBinary(base16));
    }

    public static String convertBase64StringToBase16(String base64) {
        return DatatypeConverter.printHexBinary(Base64.getUrlDecoder().decode(base64));
    }
}
现场演示:

上面说:

当要编码的字节数不能被三整除时(即,如果最后24位块只有一个或两个字节的输入),则执行以下操作:

添加值为零的额外字节,这样就有三个字节,并执行到base64的转换。如果只有一个有效输入字节,则只拾取前两个base64数字(12位),如果有两个有效输入字节,则拾取前三个base64数字(18位)。'='可以添加字符以使最后一个块包含四个base64字符

因此,由于上一个块(
ent=
)包含一个
=
,这意味着原始字节数组以2字节或16位的块结束

  • 前6位是数字30,指向字符
    e
  • 接下来的6位是数字39,指向字符
    n
  • 由于填充,剩下4个有效位,后面跟着两个0位,因此应该是偶数。然而,您的第三个字符是
    t
    ,它表示数字45。45是奇数。这意味着
    ent=
    不是有效的base64块。正确的base64编码器永远不会将任何字节序列编码到
    ent=
数字45是二进制的
101101
。但是,由于只有前4位是有效的,正确的编码器应该取下它们并用两个0位填充它们,导致
101100
,这是数字44,导致字母
s


因此,总而言之,如果您正在解码的base64值是正确的base64值,您将永远不会有这样的“bug”。

为什么
base64。Decoder.decode(…)
不会抛出
IllegalArgumentException
,因为“src不在有效的base64方案中”?我猜他们选择了宽容和快速,而不是通过添加通常不会触发的验证来放慢速度。或者规范明确地说解码器应该是宽容的(我还没有读过规范)。