序

昨天在做一個 Demo 的時候，由於是呼叫第三方的介面，採用的是 HTTP 的通訊協議，按照文件上的說明，需要把引數進行加密後加入到 URL 中，但是，就是這個看似普普通通的操作，卻讓我著實費了很大的勁。

背景

關於 BASE64，我不想說太多，因為這是很基本的一種編碼方式，或者說是加密方式。不瞭解的可以到我前面的部落格中去看看，關於加密，前邊有一個系列的文章。下面說說出現這個問題的情景。 昨天拿到一個任務，寫一個 Demo，目的是查詢一系列的資訊，當然，需要呼叫一個第三方的介面，根據介面文件中的說明，該介面採用的是 HTTP 協議，Post 的資料需要進行 BASE64 加密，由於我之前自己封裝了一系列的加密演算法，因此，就直接拿過來用了。這裡先說明一下，在我封裝的加密演算法中，用到的是 sun 的 BASE64Encoder，也就是說，我引入的是這個類： import sun.misc.BASE64Encoder; 這裡看不出有什麼問題，請接著看下邊。

出現的問題

就這樣，每當測試的時候，程式總是會報同一個錯誤 —— （java.net.MalformedURLException:Illegal character in URL），剛開始的時候，我還以為是自己寫的 模擬 Post 提交的程式碼有問題呢，於是網上查了又查，最後發現沒有什麼問題。於是，排除了這一塊，就開始找別的原因。什麼百度、Google 都查遍了，問題也沒有解決，當初也沒有想到是 BASE64 加密的問題。因為之前一直在用，也沒有出現什麼錯誤。 這個問題從中午一直持續到了下班之前，記得還是下午 5 點多的時候，終於從網上發現一篇文章，好像也是遇到了同樣的問題，從他的文章中找到了原因。

解決方案

之所以出現這樣的問題，是由於在 BASE64 加密的過程中，引錯了 jar 包，不應該使用 Sun 提供的內部包，也就是 sun.misc，後來瞭解到 sun.misc 包是 Sun 公司提供給內部使用的專用 API，在 java API 文件中我們看不到任何有關 BASE64 影子，不建議使用。 經過測試，我發現，除了使用 sun.misc 包的 BASE64 報錯外，其他兩個都可以正常執行，這兩個包括：

• com.sun.org.apache.xerces.internal.impl.dv.util.Base64;
• org.apache.commons.codec.binary.Base64;

這兩個提供的實現都可以正常執行。至於這兩個的加密方法嘛，百度一下下吧。。。

結束語

通過這個問題，我發現，很多時候，我們往往忽略一些看似很沒用的東西，而正是這些沒用的東西，時不時的會在我們的路途中橫上一槓子，我想說的是，儘管會出現這樣那樣的問題，還是要耐著性子去解決，不要把問題留給以後。 而且，當我們在學習某一類知識的時候，如果有時間，可以多想想，涉及一下與其相關的知識，或許你會有意想不到的收穫。