今天丹伟兄让我尝试一下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进制储存，这样可以避免各种因为编码出现的问题。
另外，树挪死，人挪活，别盯着同一个算法实现方式，有时候换一个就迎刃而解了。