乱码(四): 撬动地球的支点

       写下这个标题,我自己先笑了下, 口气有些大了. 不过,这么大的一个标题,倒是反映了我当时心情, 也就是我解决乱码问题过程中一个关键的转折点. 这里围绕这个关键转折点把当时的情况记录一下来.

      前面在"乱码(三): 问题的出发点 "中,  根据分析得出解决问题的用力点应该是"/etc/sysconfig/i18n"这个文件. 但折腾了些时间后(围绕这个i18n改动时的问题记录详见"乱码(二): Linux下/etc/sysconfig/i18n究竟是干什么用的? "). TMD怎么还不行呢? 但问题还是要解决的,得另找突破口. 

      .............

      一段搜索后, 对编码问题也有了个相对深刻的认识, 也跌跌撞撞地想到了Java中的Charset类, 于是习惯性地看源码,发现两个让眼前一亮的方法: defaultCharset和availableCharsets.
      写代码试它一试.
      availableCharsets方法没什么新奇的,顾名思义,用它可以得到当前Java所支持的字符集.
      写体验defaultCharset方法代码时,从它输出结果上联想到一个跟当前乱码问题相关的一点: 这个方法返回当前JVM默认的字符集(通常是操作系统的字符集),  那不是通过这个方法就可以看出乱码问题"元凶"Linux所有字符集了?!! 因为从"乱码(二): Linux下/etc/sysconfig/i18n究竟是干什么用的? "里结果发现单独改i18n文件好像是起作用. 而乱码问题的最终落脚点是把字符串按操作系统使用的字符集来组装, 这样操作系统才能显示出人能读懂的文字来.

      基于这样的思考,赶紧把实验defaultCharset方法的Java例子传到Linux上. 于是有了"乱码(二): Linux下/etc/sysconfig/i18n究竟是干什么用的? "里的图片对比信息!!!
      又"鬼使神差"地想到: 既然改i18n文件不行, 那何不在Linux上Tomcat启动时利用"export LC_ALL=zh_CN.GBK"命令对字符集做下修改呢? 再在文件上传的的相应代码里加上'new String(uploadDir.getBytes(),"GBK");',这样不就两头凑地解决了问题??

      赶快行动, 成功了! 上传的文件名不再乱码了!

      再回过头看整个过程, 虽然最终代码中没有体现出defaultCharset方法, 但它却恰恰成了"撬到地球的支点", 没有它的牵线搭桥就不会很快想出两头凑的解决方案来.