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进制储存,这样可以避免各种因为编码出现的问题。

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

posted @ 2014-03-27 21:58  LarryLawrence  阅读(5526)  评论(0编辑  收藏  举报