大多数的J2EE服务器都能很好地支持多字节语言(如中文和日文)，但这些J2EE服务器和浏览器在支持的方式上是有区别的。当开发者将一些中文(或日文)本地化应用从一种服务器迁移到另一种服务器上时，通常会遇到多字节问题。本文分析了有关多字节字符问题的根源，并给出了一些解决方案和指导原则。
尽管Java平台和大多数J2EE服务器都能很好地支持国际化，我在开发中文或日文应用时仍会遇到许多有关多字节字符方面的问题:
·编码和字符集之间有什么区别?
·为什么多字节字符应用从一种操作系统迁移到另一种上时显示会有差异?
·为什么多字节字符应用从一种应用服务器迁移到另一种上时显示会有差异?
·为什么我的多字节字符应用在IE浏览器里显示正常，可到了Mozila浏览器里却又不行?
·为什么以UTF-16(通用转换格式)编码的应用在大多数J2EE服务器上都不能很好地显示?
如果你也有同样的问题，本文将有助于你找到答案。
字符的基础知识
字符在计算机出现之前就早已存在。大约3,000年前，古代中国就出现了一些特殊的文字符号(即甲骨文)。这些文字符号有特定的形状和含义，它们中的大部分都有名字和发音。所有这些文字符号汇集成了字码表，一套从属于特定语言的独特字符集合，它们与计算机没有任何关系。几千年过去了，许多语言都在发展，数以千计的字符被创造出来。如今我们要将所有这些字符都数字化为0和1，这样计算机才能理解它们。
用键盘输入单词的时候要用到字符输入法。对于简单的字符，键盘和字符间存在着一对一的映射关系;而对于较复杂的语言，需要多次敲击键盘才能输入一个字符。
在你能从屏幕上看到字符之前，操作系统必须先将字符存放在内存里。实际上操作系统在字码表的字符与一系列非负整数之间定义了一一对应的关系，它们被存放在内存里并被操作系统调用，这些整数被称为字符代码。
字符可以用文件存储或通过网络传输。软件用字符编码来定义每个字符的字符代码与八进制序列数之间的对应方法(算法)。有些字符代码对应一个字节，如ASCII码;还有一些字符代码需要对应两个或更多的字节(如中文和日文)，这种对应关系依赖于不同的字符编码方式。
不同的语言使用不同的字码表，每个字码表都有一些特定的编码方式。在某些情况下,当你选用某种语言时就已经不自觉地选择了某种字符编码方式。例如当你选用中文的时候，在默认情况下你用的可能就是GBK中文字码表及称作GBK的特定字符编码方式。
为了不致混淆，我避免使用字符集这个词。显然，字符集与字码表是同义词。字符集在HTTP Mime(多用途网际邮件扩充协议)页头里被误用，其实这里的“charset(字符集)”是指“encoding(编码)”。
Java的特征之一是字符是16位的，这样就能支持Unicode(一种表示各种语言中许多不同种类的字符的标准方式)。不幸的是，这个特征在开发多字节J2EE应用中也引发了许多问题，本文将就此进行讨论。
开发阶段引起的显示问题
J2EE应用开发包括若干个阶段(如图1所示)，每个阶段都可能导致多字节字符显示问题。
图1 J2EE应用开发生命周期
