本文原計劃寫兩部份內容,第一是記錄最近遇到的與 Base64 有關的 Bug,第二是 Base64 編碼的原理詳解。結果寫了一半發現,誒?不復雜的一個事兒怎麼也要講這麼長?不利於閱讀和理解啊(實際上是今天有點懶想去休閒娛樂會兒),因此 Base64 編碼的原理詳解的部分將在下一篇帶來,敬請關注。java
A 向 B 提供了一個接口,約定接口參數 Base64 編碼後傳遞。程序員
但 A 對 B 傳遞的參數進行 Base64 解碼時報錯了:spring
Illegal base64 character a
搜索後發現這是一個好多網友們都踩過的坑,簡而言之就一句話:Base64 編/解碼器有不一樣實現,有的不相互兼容。segmentfault
好比我上面遇到的現象,可使用下面這段代碼完整模擬復現:微信
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); } }
以上代碼執行會報異常:ide
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));
輸出:atom
SXQgdGFrZXMgYSBzdHJvbmcgbWFuIHRvIHNhdmUgaGltc2VsZiwgYW5kIGEgZ3JlYXQgbWFuIHRv IHNhdmUgYW5vdGhlci4= --- 華麗的分隔線 --- SXQgdGFrZXMgYSBzdHJvbmcgbWFuIHRvIHNhdmUgaGltc2VsZiwgYW5kIGEgZ3JlYXQgbWFuIHRvIHNhdmUgYW5vdGhlci4=
能夠看到 sun.misc.BASE64Encoder 編碼後的內容換行了,而換行符的 ASCII 編碼正好是 0x0a,如此貌似解釋得通了。讓咱們進一步跟蹤一下,找一下出現這種差別的源頭。spa
在 IDEA 裏按住 CTRL 或 COMMAND 鍵點擊方法名,能夠跳轉到它們的實現。
這種寫法主要涉及到兩個類,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)。
這種寫法主要涉及到 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; }
因此……這個實現裏沒有換行。
通過以上的分析,真相已經大白了,就是兩個編碼器的實現不同,咱們在開發過程當中注意使用匹配的編碼解碼器就 OK 了,就是用哪一個 Java 包下面的編碼器編碼,就用相同包下的對應解碼器解碼。
至於爲啥會出現不同的實現,它們之間有過什麼前因後果、恩怨情仇,Base64 的詳細原理等等,就厚着老臉,邀請你們且聽下回分解吧!:-P
假如你對個人文章感興趣,能夠關注個人微信公衆號『悶騷的程序員』隨時閱讀更多內容。