一个字符编码问题的定位过程.doc

一个字符编码问题的定位过程 吴战胜 080722问题描述对post方式发送出去的http消息，解码并使用LUCENE来建立索引，以便后续查询检索。这个过程已经实现出来，测试那边前些日子也反馈良好。只是这天，登录上去发现，原来能够正常显示的解码过后的post文件，有许多都变成的乱码了。解码过后的文件没有人去修改过，为什么之前是正常显示的，现在却是乱的？而且更为奇怪的是，并不是所有的解码文件都是乱的，有些竟然还是正常的，为什么呢？问题定位乱码问题很显然是编码所致。马上想到，一个文件要展示出来，首先要读取到内存中，文件的读取涉及到了编码。当时，尽管在代码注释里面，自己特意在存储文件的时候写上“使用系统默认的编码来存储会不会有问题”，但是后来思量，如果存储才时候自己代码里面使用默认的编码来写文件的话，读取时候也是默认编码来读的话，应该就不会出问题，于是就没有做更细致的分析。那现在再回过头来思考这问题的话，有些乱有些不乱，那在这个读写的环节中，问题到底和这个默认编码有没有关系呢？考究下“默认编码”这个词，在java中默认编码是指file.encoding属性。那么要是，在读写操作中jvm中获得的file.encoding发生变化，那么读写有可能出现不一致的编码了。那file.encoding什么时候发生变化呢？file.encoding的与系统的环境变量相关的，在程序运行的linux里面，LC.ALL标明了这个值，那如果这个值被人修改，那么默认编码就可能发生改变了。问题的结论，似乎呼之欲出：在java进程读写文件过程中，因为lc.all属性被人修改，导致默认编码发生改变，所以出现文件读写错乱的情况。为了验证，这个系统环境变量对java进程的影响，特意做了如下测试：编写如下程序： public class Test Public static void main(String args)throws Exception while(true) System.out.println(“file.encoding:”+System.getProperty(“file.encoding”); Thread.sleep(1000*5); 编译运行之。控制台每隔5秒打印出：file.encoding:GBK。使用export命令查看环境变量，看到lc.all的值中也是意料之中的GBK。这个时候，使用export命令修改掉lc.all为UTF-8，如果控制台打印出file.encoding:UTF-8的话，那么问题就得到圆满的确认了（也就是说在读取解码后的文件的过程中，被人export改掉lc.all导致问题的）。很遗憾，修改完之后，控制台依旧打印出的是file.encoding:GBK。那说明问题还没解决，但是我们可以确认另外一个结论：JVM在启动的时候，只会一次仅且一次地把系统相关的环境变量读取到System类中，之后对系统的环境变量更新在启动的java进程中就反馈不出来了（System类也不会重新加载这些数据）。以上面的结论为支点，很快就又可以联想到，那是不是既然启动后的java进程无法反馈这些数据，java进程是不是被杀死过。想想下面的事件序列：Java进程启动，并且使用当前的默认字符（如GBK）来读写文件 -java进程被杀死(或者意外地死掉)-系统的默认字符被export修改成另外一种字符集（如UTF-8）-另一个java进程使用当前UTF-8来读取之前的GBK保存的文件，那肯定就出现乱码了。问题解决 那么看来使用，使用默认的字符集来存储或者读写文件是存