专家讲述J2EE中的多字节字符的处理 （9）

难题之一：UTF-16

有了前面的知识，现在我们来分析一个真正的难题，这是我负责的一个ISV（独立软件开发商）在项目中遇到的：J2EE中的UTF-16。

现行的中文字符标准（GB18030）定义并支持27,484个中文字符。尽管这个数字看起来很大，实际上对中国人来说还不够。目前中文拥有60,000多个字符，每年还在快速增长，这个状况对中国政府在信息化方面的工作会产生严重影响。例如我姐姐的名在标准字符集中就没有，因此银行或邮电系统的计算机就打不出她的名。

我的ISV希望能建立一套完整的、能让所有人满意的中文字符系统。它定义了自己的字码表，有两个现成的字符字码表可供选择：采用GB18030标准，可扩充到1600万个字符；或采用Unicode 3.1标准，可支持1,112,064个字符。GB18030标准定义了编码规则，也叫做GB18030，它用起来很简便，目前已被JDK支持。然而如果采用Unicode 3.1标准，我们就可以从三种编码方式中进行选择：UTF-8、UTF-16或UTF-32。

我的ISV希望用UTF-16编码来处理它对中文字符的Unicode扩展。UTF-16编码最主要的特点就是所有的ASCII字符都被编码为16位的单元，这会在各个阶段引发问题。在几个服务器上做过测试后，ISV发现J2EE应用根本不支持UTF-16编码。果真如此吗？我们一起来分析开发的各个阶段以找出问题所在。

编辑阶段

如果在Java、JSP或HTML源文件中有多字节文字字符串，就需要用支持它们的IDE。我用的是NetBeans，只要将文本编码属性设置为UTF-16就能轻松支持UTF-16编码。图12所示的是一个用UTF-16编码的JSP页面，它里面只有一个静态文字字符串“hello world!”。该页面在Tomcat上运行，在Mozilla中显示。

编译阶段

由于在Java或JSP源文件中带有用UTF-16编码的字符，因此需要编译器的支持。可以用javac -encoding UTF-16命令来编译Java源文件，而在NetBeans里则可通过GUI方便地设置编译器的属性。通过一些简单的代码测试可以发现：如果servlet文件中的字符是用UTF-16编码的，那么运行时就不会有问题。

运行时动态编译的JSP文件值得我们注意。幸运的是，大多数服务器可以对JSP页面的编码方式进行配置；而不幸的是，在Tomcat和Sun ONE应用服务器上做测试时，我发现用来将JSP文件转换为servlet Java源文件的Jasper不能识别被UTF-16编码过的JSP标签（比如<%page..%>），所有这些标签都被当作文字字符串处理了！我认为问题的根源可能在于Jasper（大多数应用服务器都用它做JSP编译器），因为它以字节为单位来识别JSP的特定记号和标签。