RC4加密解密

　　今天丹偉兄讓我嘗試一下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進制儲存，這樣能夠避免各類由於編碼出現的問題。

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