Apache commons base64 decode和Sun base64 decode答案

【问题标题】：Apache commons base64 decode and Sun base64 decodeApache commons base64 decode和Sun base64 decode
【发布时间】：2013-08-06 16:59:53
【问题描述】：

byte[] commonsDecode = Base64.decodeBase64(data);
debug("The data is " + commonsDecode.length + " bytes long for the apache commons base64 decoder.");
BASE64Decoder decoder = new BASE64Decoder();
byte[] sunDecode = decoder.decodeBuffer(data);
Log.debug("The data is " + sunDecode.length + " bytes long for the SUN base64 decoder.");

请向我解释为什么这两个方法调用会为生成的字节数组产生不同的长度。我最初认为这可能与字符编码有关，但如果是这样，我就无法正确理解所有问题。上面的代码是在同一个系统和同一个应用程序中执行的，按照上面显示的顺序。因此，该系统上的默认字符编码将是相同的。

输入（测试）数据： 下面是 Java 字符串的 System.out.println。

qFkIQgDq jk3ScHpqx8BPVS97YE4pP/nBl5Qw7mBnpSGqNqSdGIkLPVod0pBl Uz7NgpizHDicGzNCaauefAdwGklpPr0YdwCu4wRkwyAuvtDmL0BYASOn2tDw72LMz5FChtSa0CoCBQ2ARsFG2GdflnIWsUuBQapX73ZBMiqqm  ZCOnMRv9Ol8zT1TECddlKZMYAvmjANgq0sBPyUMF7co XY9BYAjV3L/cA8CGQpXGdrsAgjPKMhzk4hh1GAoQ1soX2Dva8p3erPJ4sy2Vcb6lS1Hap9FR0AZFawbJ10FFSTg10wxc24539kYA6xxq/TFqkhaEoSyTqjXjvo1SA==

Apache commons 解码器说它是 252 长度字节数组。 Java Sun 解码器显示 256。

【问题讨论】：

请注意，您使用的 Sun base64 解码器很可能不是已发布的类/官方 API，因此不鼓励使用它。 Java SE 8 中将添加官方 base 64 解码器：download.java.net/jdk8/docs/api/java/util/Base64.html
不要使用 sun.misc 或 com.sun 类。它们没有记录，并且可以从 Java 版本更改为 Java 版本。由于没有文档，你怎么知道它应该做什么？
你能把字节数组转换成你在这两种情况下需要的数据格式吗？
@Codo 这没有回答问题。我将其用作测试用例而不是生产代码。理想情况下，两个解码器都应输出相同长度的字节数组，但事实并非如此。为什么不呢？
@Puce a byte[] 是我需要的格式。我对传输的值进行了base64编码，仅此而已。

标签： java base64

【解决方案1】：

解码后的数据不是有效的 Base64 数据。

有效的 Base64 数据可以包含空格。通常，它每 72 个字符有一个换行符。但是，您的数据在随机位置包含空格。如果它们被删除（就像每个 Base64 解码器都应该做的那样），则剩下 339 个字符。然而，有效的 Base64 数据必须是 4 个字符的倍数。

有趣的是，您的数据不包含加号。我怀疑它曾经包含过它们，但它们可能已被传输中的某个地方替换为空格。如果将所有空格替换为加号，则 Base64 数据有效，解码后的数据长度为 256 字节：344 个字符 / 4 * 3 - 2 个填充字符。

我进一步怀疑在没有正确 URL 编码的 URL 中使用了 Base64 数据。这是缺少加号的可能原因。请注意，Base64 编码数据不是 URL 安全的。加号和等号都需要转义。

【讨论】：

非常感谢。是的，我认为缺少 URL 编码是原因。我再次回顾了我的代码，并将内容类型设置为 x-www-form-urlencoded，但我忘了显式地对数据进行 url 编码。
我确认这是问题所在。我想 SUN/Apache 解码器最终会以不同的方式处理格式不正确的数据。无论如何，您的回答帮助我解决了问题的根源。非常感谢。