欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

学艺要精,思考要慎.--转UTF-8编码的启发 JSPJVMGoogleXML虚拟机 

程序员文章站 2024-01-23 20:34:34
...

本次对UUZone Refactor中一个大动作就是采用UTF-8编码,由于种种的历史原因,uuzone一直采用GBK编码,现在要把这个编码转成为UTF-8的。

本文不打算讨论技术, 所以简单地说明这个工作进展的一个过程:

* 最早的时候,n年前,我们一个项目需要国际化支持,毫无疑问utf-8是最佳的编码选择,这时候项目组就遇到了问题: 本地编写的文件中的中文都是GBK编码的, 仅仅设置页面的contentType="text/html; charset=UTF-8", 出来的全是乱码...当然拿GBK的东西直接要求对方用UTF-8看,一定是乱码. 

   当时如何解决的过程已经无法了解, 但最终采用的方案是:  用GBK写文件, 然后采用JDK中的native2ascii工具转换. 问题解决了, 但结果就是多了转码的过程, 转码后的jsp文件人不可读.

* 做uuzone了,  项目组建议采用GBK编码, 因为那个转码工作太繁琐了,而且导致文件不可读, 调试非常麻烦. 于是uuzone就成了GBK的.

   由于采用GBK, 遇到了很多相关的问题... 中途至少有2次我"建议"改用UTF-8, 都被评估认为有太多问题而没有被采纳(郁闷的boss啊...)...

* 发现原来不需要转码!  终于处于某些原因, 我需要自己动手来研究一些技术细节, 发现native2ascii转码的工作其实并不需要进行. jsp文件可以直接保存为UTF-8编码, 输出的结果就是UTF-8的...而现在的elips,editplus, ultraedit, 甚至notepad都能保存和识别utf-8的文件.

* 终于下定决心转为UTF-8. 既然如此, 就没有理由拒绝了. 因此本次refactor项目目标之一就是改用UTF-8.  既然文件打算用utf-8保存, 那么就需要批量转换工具...几下search, 好的工具也找到了.

* 转!   有工具, 不到20秒, 6000多个文件就从GBK转成了UTF-8文件格式...

* 问题来了! 项目中的XML, properties文件是否转码呢? 本来计划转...但很快发现,这些文件转掉后, XML,properties文件的读取都出了不同程度的问题...总之项目将根本无法运行... 原因何在?原来这些UTF-8的文件有一个所谓BOM头,也就是告诉你这个文件的编码是什么...不幸的是Java的xml parser, properties文件parser都不认识这个BOM头!已经有人把这个作为Bug提交给了SUN并被接受, 可是这个bug一直拖了4年,才在去年在Mustang项目(Java 6.0)中解决! 我们显然不能用了.

* 幸运的是... 我们可以规避这些问题, 我们并不需要把XML, properties文件转换成UTF-8的, 只要把jsp转了即可. 虽然一个项目中的文件两种保存格式,非常不优雅, 但毕竟这能解决问题啊... 转换完jsp文件,运行项目, 成功! 打开browser...页面也出来了!

* 几乎成功了! 是的, 几乎成功了...然而在计算机的世界里几乎成功就是不成功. 因为页面上的样式神秘地出了轻微的混乱. 经过n十分钟仔细研究讨论, 终于发现产生的html页面内出现了几个神秘的不可见字符... 就是这些可怕的不可见字符, 破坏了页面的结构.

* 神秘的隐身字符  和计算机打交道和比人打交道强的一个地方就是在于 -- 如果计算机错了,一定是你错了, 因为计算机一定忠实执行你的指令. 神秘的不可见字符一定有其来历. 经过二进制分析, 找到了这些神秘字符出现的地方 ---jsp include! 每次include就会出现神秘字符, 而这些神秘字符的值也是老朋友了 -- 就是BOM header ! 

* 难道不能include了?  原来java显然和xml文件一样对待了这些BOM头, 这些FF FE之类的东西成了输出的一部分. google 去查, 看到一个人显然遇到完全相同的问题, 可惜是个俄罗斯的程序员, 也看不懂其文章... :(

    怎么办?  有同学说: 既然你要UTF-8 (心想: 谁让你是boss呢? 愚蠢的boss啊...:-) ) , 我们还是用native2ascii吧...  不行! 

* 遇到困难要思考. 思考...

    首先, 为什么java文件不需要转码(java 文件中的中文无论如何都能正确)? 为什么jsp要? jsp不是被预编译成java的吗? 

    从那个sun承认的bug, 显然可以得出一个结论, java虚拟机中的file input stream没有能自动很具BOM识别文件编码. 

    也许javac是比较native的代码, 能通过操作系统获得native编码类型, 而java内部是unicode的, 所以输出也同样没问题.  而jsp是动态编译的, 预编译器是JVM...其待遇显然和xml等是一样的...

   难道sun公司的人会愚蠢到这种地步? 不可能, 一定是我们愚蠢.继续google 学习...

    不幸的是大部分google上关于这类编码问题的讨论都是不完整的. 但一个神秘的pageEncoding跳进了眼帘, 已经指定了contentType的encoding, 为什么还要指定pageEncoding?  查一下jsp的资料, 显然这正是问题所在!  pageEncoding就是告诉JVM 这个jsp本身采用的encoding, 默认采用iso-8859. 我们明明用GBK的native编码, 让JVM拿iso8859读取,当然不对了!!

* 根本没有需要转码, 问题解决了! 是的, 明白了原因所在, 把所有jsp文件头修改为: <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="GBK" %> 不需要任何转码,最终输出的就是UTF-8, 没有任何问题. 而且这些文件采用native格式保存, 编辑最方便!