Java/J2EE 中文问题终极解决之道
souzz.net 2005-12-17 文章出处:赛迪论坛 Java 中文问题一直困扰着很多初学者,如果了解了 Java 系统的中文问题原理,我们就 可以对中文问题能够采取根本的解决之道。 最古老的解决方案是使用 String 的字节码转换,这种方案
问题是不方便,我们需要破坏对象封 装性,进行字节码转换。 还有一种方式是对 J2EE 容器进行编码设置,如果 J2EE 应用系统脱离该容器,则会发生乱码, 而且指定容器配置不符合 J2EE 应用和容器分离的原则。 在 Java 内部运算中,涉及到的所有字符串都会被转化为 UTF-8 编码来进行运算。那么,在被 Java 转化之前,字符串是什么样的字符集? Java 总是根据操作系统的默认编码字符集来决定 字符串的初始编码,而且 Java 系统的输入和输出的都是采取操作系统的默认编码。 因此,如果能统一 Java 系统的输入、输出和操作系统 3 者的编码字符集合,将能够使 Java 系 统正确处理和显示汉字。这是处理
Java 系统汉字的一个原则,但是在实际项目中,能够正确 抓住和控制住 Java 系统的输入和输出部分是比较难的。J2EE 中,由于涉及到外部浏览器和数 据库等,所以中文问题乱码显得非常突出。 J2EE 应用
程序是运行在 J2EE 容器中。在这个系统中,输入途径有很多种:一种是通过页面表 单打包成请求(request)发往服务器的;第二种是通过数据库读入;还有第 3 种输入比较复杂, JSP 在第一次运行时总是被编译成 Servlet,JSP 中常常包含中文字符,那么编译使用 javac 时, Java 将根据默认的操作系统编码作为初始编码。除非特别指定,如在 Jbuilder/eclipse 中可以指 定默认的字符集。 输出途径也有几种:第一种是 JSP 页面的输出。由于
JSP 页面已经被编译成 Servlet,那么在输 出时,也将根据操作系统的默认编码来选择输出编码,除非指定输出编码方式;还有输出途径 是数据库,将字符串输出到数据库。 由此看来,一个 J2EE 系统的输入输出是非常复杂,而且是动态变化的,而 Java 是跨平台运行 的,在实际编译和运行中,都可能涉及到不同的操作
系统,如果任由 Java 自由根据操作系统 来决定输入输出的编码字符集,这将不可控制地出现乱码。 正是由于 Java 的跨平台特性,使得字符集问题必须由具体系统来统一解决,所以在一个 Java 应用系统中,解决中文乱码的根本办法是明确指定整个应用系统统一字符集。 指定统一字符集时,到底是指定 ISO8859_1 、GBK 还是 UTF-8 呢? (1)如统一指定为 ISO8859_1,因为目前大多数
软件都是西方人编制的,他们默认的字符集
就是 ISO8859_1,包括操作系统 Linux 和数据库 MySQL
等。这样,如果指定 Jive 统一编码为 ISO8859_1,那么就有下面 3 个环节必须把握: 开发和编译代码时指定字符集为 ISO8859_1。 运行操作系统的默认编码必须是 ISO8859_1,如 Linux。 在 JSP 头部声明:。 (2)如果统一指定为 GBK 中文字符集,上述 3 个环节同样需要做到,不同的是只能运行在默 认编码为 GBK 的操作系统,如中文 Windows。 统一编码为 ISO8859_1 和 GBK 虽然带来编制代码的方便,但是各自只能在相应的操作系统上 运行。但是也破坏了 Java 跨平台运行的优越性,只在一定范围内行得通。例如,为了使得 GB K 编码在
linux 上运行,设置 Linux 编码为 GBK。 那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决
方案呢? 将 Java/J2EE 系统的统一编码定义为 UTF-8。UTF-8 编码是一种兼容所有语言的编码方式,惟 一比较麻烦的就是要找到应用系统的所有出入口,然后使用 UTF-8 去“结扎”它。 一个 J2EE 应用系统需要做下列几步
工作: 开发和编译代码时指定字符集为 UTF-8。JBuilder 和 Eclipse 都可以在项目属性中设置。 使用过滤器, 如果所有请求都经过一个 Servlet 控制分配器, 那么