nodejs开发中的一个小故事,解决问题历时一周,是在下浅薄了,但也是目前为止遇到过最有价值的问题,涉及nodejs对开发造成的限制
nodejs默认是不支持gbk的,所以nodejs下很多库也是不支持gbk的,此为前提……
有需求,要用nodejs的服务器跟别人进行通讯,通讯报文编码使用gbk,报文通讯时需要加解密,于是问题就来了
加解密使用的是crypto-js库,该库不支持对gbk编码的中文加解密,解密出来的密文先转成别的编码再转回gbk倒还是可以,但加密时若是直接把gbk的中文传进去,是绝对无法复原的,因为解密后中文都会变成乱码
所以加密前需要先把gbk转成别的编码,比如hex,比如base64(这里假设编码使用的是base64),然后再传入加密函数
关键的地方来了
其实每一次编码转换,相当于一次加解密。
所谓的加密和解密,不过是通过一种手法能够把明文转化为密文,把密文转化为明文,并且让密文和明文唯一对应,换句话说,把中文转码成乱码也是一种加密手段,毕竟别人无法看懂乱码,只不过这种加密手法很容易被破解罢了
所以,加密过程等于先用编码加密了原来的明文,再用aes加密了一次,跟原来相比就是加密了两次
那么crypto-js的解密函数也是很有意思,返回的是一个字节数组,而且这个字节数组必须使用crypto-js提供的函数进行解码变回字符串,这个字节数组是无法直接对其进行解码的哦。
解密后,虽然aes的加密效果去掉了,但此时的字节数组还是处于编码加密后的;
然后再一次调用crypto-js库提供的解码函数,(这里假设解码函数使用的是hex),那么此时获得的字符串,是由原明文经过base64编码, hex编码得到的,所以,如果想要还原原来的明文,需要先进行一次hex编码解码,一次base64编码解码才可以获得原来的gbk编码明文