今天丹伟兄让我尝试一下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进制储存，这样可以避免各种因为编码出现的问题。

另外，树挪死，人挪活，别盯着同一个算法实现方式，有时候换一个就迎刃而解了。