昨天用户提出了个bug,一直没空解决,今天便想抽空看看,服务器上log文件中的汉字一片乱码,平时log中汉字较少,也没多大用处,也没当回事,这次是ws报错,与别的系统交互,汉字较多,这可头疼了,正找不到错误原因呢,出现一堆乱码,第一感觉就是先搞定乱码再说(虽然事后证明这部分信息完全没用):
连接应用服务器用的是Secure CRT工具:
#echo $LANG 结果输出: en_US.UTF-8,编码的确也是UTF-8,没错,难道是en_US有问题,不应该啊,病急乱投医,管他呢,先改了再说
#LANG=“zh_CN.UTF-8”,但是文件依旧是乱码。好生郁闷。
最憋屈的是最后结果竟然是Secure CRT没有设置好,在工具的Appearance中设置一下字符集编码就好了
补充两点:
1:en_US.UTF-8和zh_CN.UTF-8的区别:
两个都表示,系统编码是UTF-8,但是en_US表示是美国人在美国地区使用,也就是说系统中的一些有地域性差别的点都要按老美的习惯来显示,比如时间、数值等
zh_CN.UTF-8表示是中国人在中国使用,同理,要按中国的习惯来说显示。
2:字符集和编码的关系
都知道Java采用unicode字符集,那么他与ascii,ansi,iso-8859,utf-8都有什么关系呢,查阅了一些资料,总结如下(个人理解,很可能有不对指出)
最初老美用一个字节(8个二进制位)来表示一个字符,老美的字母数字少,1个字节够还用不完就把所有字符表示完了(值用了7个),但是随着发展,其他地区的人也要用,于是各自把剩下的一个二进制位派上用场,也就是对ascii进行各式各样的扩展,其中出名的是iso-8859-1和gbk,这些编码机统称为ansi,后来为了统一,便有了unicode,利用两个字节来表示一个字母,这样以来世界各地的字符都可以统一表示了,但是unicode只是个字符集,并有着自己的不足,后来便用utf-8来对其进行编码,当然也有不常用的utf-16,32等。