您的位置:首页 > 编程语言 > Java开发

加密算法中使用getBytes()方法时,最好强制编码方式为UTF-8

2017-03-01 18:11 441 查看
最近在项目中发现一个奇怪的问题:

windows + MyEclipse + tomcat8 环境下,在ssm项目(采用UTF-8编码)中,controller中的方法在跟第三方平台(C#)进行交互(采用json字符串进行数据传输)时,总是报签名错误。最奇怪的地方是:同样的字符串,我在加密工具类中使用main方法加密得到的签名跟调用controller中的方法得到的签名是不一样的。

经过排查,发现是因为参数中包含中文时,就会报这个错,如果不包含中文,那么就不会报错。很明显了,就是编码方式的问题。

首先,我保证我的项目中的每个文件都是UTF-8编码的。

然后,根据编码方式这个线索,我在网上找了很多资料,但都解决不了问题。我甚至一度以为是JSONObject的toString()方法,采用的编码方式跟我本地的项目的编码方式不一致才导致这个问题发生。(见笑了)

最后,经过网友的热心提示,我只好采用笨办法来一点一点调试,那就是:getBytes("UTF-8")

将字符串在每个加密环节先getBytes("UTF-8")成为byte数组,然后一一打印出来。经过比对,发现两种方法打印出来的byte数组还是完全一样的。然后继续在每个可能涉及到编码的地方使用这样的方法排查。功夫不负有心人,问题终于找到了:原来在某个环节,要先将字符串MD5加密,然后再进行SHA1加密,在进行MD5加密时,传入同样的字符串,两种方式加密得到的结果不同。问题可能就在这里了。

进入MD5加密的算法,发现也有对字符串进行getBytes()的操作,但是采用的是默认参数(采用System.getProperty("file.encoding")可以查看系统的默认编码方式),也就是说getBytes采用的是系统默认的编码方式。那么问题来了:在不同的平台下,OS的默认编码方式是不一致的。例如:在windows平台,默认的编码方式是GBK,也就是说在调用无参getBytes()方法的时候,对中文字符串是采用GBK方式编码的;在linux平台,默认的编码方式是UTF-8,也就是说在调用无参getBytes()方法的时候,对中文字符串是采用UTF-8方式编码的。

所以,问题就在这里,因为我是在windows平台下,而且MD5加密方法也是采用的无参getBytes()方法,加密得到的值自然是采用GBK的编码方式进行编码的,最终的结果当然不一样。

解决办法:在所有涉及到对字符串进行编码转换的地方,建议不要使用无参的getBytes()方法,而是使用有参数的getBytes("UTF-8")方法。这样在涉及到跨平台的交互时,就不会因为编码方式不同而产生乱码之类的各种问题。

以上为个人拙见,欢迎大家来讨论交流。

PS:

经过测试,使用System.getProperty("file.encoding")这个方法查看默认编码时,会受到这行语句所在的类的编码方式的影响,也就是说:如果新建Test类,而且Test类的编码方式是UTF-8,那么上面的语句执行的结果就是UTF-8;如果将Test类的编码方式改成GBK,那么得到的结果就是GBK。问题又来了,我的项目都是采用UTF-8编码方式的,那么MD5加密算法中的无参getBytes()方法得到的值应该也是UTF-8编码的,怎么会是GBK编码的呢?这不是与上面的说法矛盾吗?

其实真正影响System.getProperty("file.encoding")这个方法查看默认编码的结果的东西,是这个方法执行的入口的默认编码方式。听起来似乎很绕口,简单来说,就是System.getProperty("file.encoding")执行的main方法所在的地方的默认编码方式是什么,getProperty得到的结果就是什么。项目运行在windows平台,getByte()得到的采用的默认编码方式就是windows平台的编码方式:GBK,于是导致了上述问题的发生。

我曾经怀疑是tomcat8的默认编码方式不是UTF-8,于是尝试将tomcat 8的默认编码方式显式指明为UTF-8,然后采用无参的getBytes()方法进行MD5加密,发现解决不了问题。有兴趣的朋友,可以自己试试,以确定无参的getBytes()到底是获得的tomcat8的编码方式,还是OS的编码方式。

个人原创,转载请指明出处。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  java 加密
相关文章推荐