今天丹偉兄讓我嘗試一下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進制儲存，這樣可以避免各種因為編碼出現的問題。
另外，樹挪死，人挪活，別盯着同一個算法實現方式，有時候換一個就迎刃而解了。