今天丹偉兄讓我嘗試一下RC4算法加密解密。之前AES解密出來各種「錕斤拷」我已接近崩潰。

　　這個RC4相比AES就輕量多了，不用導入各種類，連keygen的步驟也沒有，只經過一系列可見的數學運算，而且加密解密用一套算法。輕車熟路地把代碼弄過來，又出現了直接在內存中讀取加密數據并且解密能夠成功，但是先「落地」寫到文件里再讀取解密就不行的情況。

　　丹偉兄建議我用把內存中的東西弄出來跟讀取的東西對比一下。

　　但是剛才遇到一個需要注意的地方：

		    String line = null ; 
//		    String content = null ;
		    String content = "";
		    while(true)
		    {
		    	line = br.readLine();
		    	if(line == null ) break;
		    	content = content + line ;
		    }

　　這里用BufferedReader的Readline方法，但是要注意content這里不能定義成null，不然會讀完之后content的內容會變成nullxxxxx...最前面有個「null」。

　　

　　用OutStreamWriter輸出，指定字符編碼，如果指定成UTF-8，像這樣：

OutputStreamWriter osw = new OutputStreamWriter(os,Charset.forName("UTF-8"));

　　就會出現這種情況：

「準備寫入的」和「讀取的」已經不一樣了。。。這樣就別解密了。　

用Unicode輸出，是這種情況：

ASCII:

GBK:

正常了。另外，GB2312也不正常。

可以看出，在OutputStreamWriter中不管用什么編碼輸出，「加密后的，準備寫入文件的」是相同的（廢話，這里還沒有涉及到編碼呢）。但是一旦用不同的編碼寫進文件，再讀出來，立刻打印出來，就不一樣了。

為什么只有GBK是正常的？想起昨天「師妹」提到的Eclipse的默認編碼，是不是因為他的默認編碼是GBK呢？

試著改成UTF-8之后Android自動更新各種R.java...我擔心它變不回來了（結果是可以變回來的）。

改成UTF-8之后連沒加密的內容都是亂碼了，好吧，改回GBK。這時候已經晚了，當前頁面的類中已經出現了各種「錕斤拷」。還好其他文件沒有。

明天繼續，一定把這東西搞清楚。

------------------Mar.30,2014-------------------

過了很多天。今天解決了。換了算法。我只想說，加密后一定要把密文換成16進制儲存，這樣可以避免各種因為編碼出現的問題。

另外，樹挪死，人挪活，別盯著同一個算法實現方式，有時候換一個就迎刃而解了。

總結

以上是生活随笔為你收集整理的RC4加密解密的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。