Java中文&编码问题小结

Java 字符编码转换过程说明

 

 

常见问题

 

 

 

JVM

JVM 启动后， JVM 会设置一些系统属性以表明 JVM 的缺省区域。

user.language,user.region,file.encoding 等。 可以使用 System.getProperties() 详细查看所有的系统属性。

 

如在英文操作系统 ( 如 UNIX) 下，可以使用如下属性定义强制指定 JVM 为中文环境 -Dclient.encoding.override=GBK -Dfile.encoding=GBK -Duser.language=zh -Duser.region=CN

 

.java-- > .class 编译

说明：一般 javac 根据当前 os 区域设置 , 自动决定源文件的编码 . 可以通过 -encoding 强制指定 .

 

错误可能 :

1 gbk 编码源文件在英文环境下编译 ,javac 不能正确转换 . 曾见于 java/jsp 在英文 unix 下 . 检测方法 : 写 /u4e00 格式的汉字，绕开 javac 编码 , 再在 jvm 中 , 将汉字作为 int 打印，看值是否相等；或直接以 UTF-8 编码打开 .class 文件，看看常量字符串是否正确保存汉字。

 

文件读写

外部数据如文件经过读写和转换两个步骤，转为 jvm 所使用字符。 InputStream/OutputStream 用于读写原始外部数据， Reader/Writer 执行读写和转换两个步骤。

 

1 文件读写转换由 java.io.Reader/Writer 执行；输入输出流 InputStream/OutputStream  处理汉字不合适 , 应该首选使用 Reader/Writer ，如 FileReader/FileWriter 。

 

2 FileReader/FileWriter 使用 JVM 当前编码读写文件 . 如果有其它编码格式 , 使用 InputStreamReader/OutputStreamWriter

 

3 PrintStream 有点特殊，它自动使用 jvm 缺省编码进行转换。

 

 

读取 .properties 文件

.propeties 文件由 Properties 类以 iso8859-1 编码读取，因此不能在其中直接写汉字，需要使用 JDK 的 native2ascii 工具转换汉字为 /uXXXX 格式。命令行： native2ascii –encoding GBK inputfile outputfile

 

读取 XML 文件

1 XML 文件读写同于文件读写，但应注意确保 XML 头中声明如 <? xml version=”1.0” encoding=”gb2312” ?> 与文件编码保持一致。

 

2 javax.xml.SAXParser 类接受 InputStream 作为输入参数，对于 Reader ，需要用 org.xml.sax.InputSource 包装一下，再给 SAXParser 。

 

3 对于 UTF-8 编码 XML ，注意防止编辑器自动加上 /uFFFE BOM 头 , xml parser 会报告 content is not allowed in prolog 。

 

 

字节数组

1 使用 new String(byteArray,encoding) 和   String.getBytes(encoding)  在字节数组和字符串之间进行转换

 

也可以用 ByteArrayInputStream/ByteArrayOutputStream 转为流后再用 InputStreamReader/OutputStreamWriter 转换。

 

错误编码的字符串 (iso8859-1 转码 gbk)

如果我们得到的字符串是由错误的转码方式产生的，例如：对于 gbk 中文，由 iso8859-1 方式转换，此时如果用调试器看到的字符串一般是 的样子，长度一般为文本的字节长度，而非汉字个数。

 

可以采用如下方式转为正确的中文：

text = new String( text.getBytes(“iso8859-1”),”gbk”);

 

JDBC

转换过程由 JDBC Driver 执行，取决于各 JDBC 数据库实现。对此经验尚积累不够。

 

1 对于 ORACLE 数据库，需要数据库创建时指定编码方式为 gbk ，否则会出现汉字转码错误

2 对于 SQL Server 2000 ，最好以 nvarchar/nchar 类型存放文本，即不存在中文 / 编码转换问题。

3 连接 Mysql ，将 connectionString 设置成 encoding 为 gb2312 ：

  String connectionString   = "jdbc:mysql://localhost/test?useUnicode=true&characterEncoding=gb2312";

 

WEB/Servlet/JSP

1 对于 JSP ，确定头部加上 <%@ page contentType="text/html;charset=gb2312"%> 这样的标签。

2 对于 Servlet ，确定 设置 setContentType (“text/html; charset=gb2312”) ，以上两条用于使得输出汉字没有问题。

3 为输出 HTML head 中加一个 <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> ，让浏览器正确确定 HTML 编码。

 

4 为 Web 应用加一个 Filter ，确保每个 Request 明确调用 setCharacterEncoding 方法 , 让输入汉字能够正确解析。

 

 

import java.io.IOException;

import javax.servlet.Filter;

import javax.servlet.FilterChain;

import javax.servlet.FilterConfig;

import javax.servlet.ServletException;

import javax.servlet.ServletRequest;

import javax.servlet.ServletResponse;

import javax.servlet.UnavailableException;

import javax.servlet.http.HttpServletRequest;

 

/**

  * Example filter that sets the character encoding to be used in parsing the

  * incoming request

  */

public class SetCharacterEncodingFilter

    implements Filter {

  public SetCharacterEncodingFilter()

  {}

  protected boolean debug = false;

  protected String encoding = null;

  protected FilterConfig filterConfig = null;

  public void destroy() {

    this.encoding = null;

    this.filterConfig = null;

  }

 

  public void doFilter(ServletRequest request, ServletResponse response,

                       FilterChain chain) throws IOException, ServletException {

//    if (request.getCharacterEncoding() == null)

//    {

//       String encoding = getEncoding();

//      if (encoding != null)

//        request.setCharacterEncoding(encoding);

//

//    }

      request.setCharacterEncoding(encoding);

      if ( debug ){

        System.out.println( ((HttpServletRequest)request).getRequestURI()+"setted to "+encoding );

      }

    chain.doFilter(request, response);

  }

 

  public void init(FilterConfig filterConfig) throws ServletException {

    this.filterConfig = filterConfig;

    this.encoding = filterConfig.getInitParameter("encoding");

    this.debug = "true".equalsIgnoreCase( filterConfig.getInitParameter("debug") );

  }

 

  protected String getEncoding() {

    return (this.encoding);

  }

}

 

 

web.xml 中加入：

 

  <filter>

    <filter-name>LocalEncodingFilter</filter-name>

    <display-name>LocalEncodingFilter</display-name>

    <filter-class>com.ccb.ectipmanager.request.SetCharacterEncodingFilter</filter-class>

    <init-param>

      <param-name>encoding</param-name>

      <param-value>gb2312</param-value>

    </init-param>

    <init-param>

      <param-name>debug</param-name>

      <param-value>false</param-value>

    </init-param>

  </filter>

 

   <filter-mapping>

    <filter-name>LocalEncodingFilter</filter-name>

    <url-pattern>/*</url-pattern>

  </filter-mapping>

 

5 用于 Weblogic （ vedor-specific ）：

其一 : 在 web.xml 里加上如下脚本 :

<context-param>

  <param-name>weblogic.httpd.inputCharset./*</param-name>

  <param-value>GBK</param-value>

</context-param>

其二（可选）在 weblogic.xml 里加上如下脚本 :

<charset-params>

  <input-charset>

      <resource-path>/*</resource-path>

      <java-charset-name>GBK</java-charset-name>

  </input-charset>

</charset-params>

 

SWING/AWT/SWT

对于 SWING/AWT ， Java 会有些缺省字体如 Dialog/San Serif ，这些字体到系统真实字体的映射在 $JRE_HOME/lib/font.properties.XXX 文件中指定。排除字体显示问题时，首先需要确定 JVM 的区域为 zh_CN ，这样 font.properties.zh_CN 文件才会发生作用。对于 font.properties.zh_CN , 需要检查是否映射缺省字体到中文字体如宋体。

 

在 Swing 中， Java 自行解释 TTF 字体，渲染显示；对于 AWT,SWT 显示部分交由操作系统。首先需要确定系统装有中文字体。

 

1 汉字显示为 ” □ ” ，一般为显示字体没有使用中文字体，因为 Java 对于当前字体显示不了的字符，不会像 Windows 一样再采用缺省字体显示。

2 部分不常见汉字不能显示，一般为显示字库中汉字不全，可以换另外的中文字体试试。

3 对于 AWT/SWT ，首先确定 JVM 运行环境的区域设置为中文，因为此处设计 JVM 与操作系统 api 调用的转换问题，再检查其它问题。

 

JNI

JNI 中 jstring 以 UTF-8 编码给我们，需要我们自行转为本地编码。对于 Windows ，可以采用 WideCharToMultiByte/MultiByteToWideChar 函数进行转换，对于 Unix ，可以采用 iconv 库。

 

这里从 SUN jdk 1.4 源代码中找到一段使用 jvm String 对象的 getBytes 的转换方式，相对简单和跨平台，不需要第三方库，但速度稍慢。函数原型如下：

 

/* Convert between Java strings and i18n C strings */

JNIEXPORT jstring

NewStringPlatform(JNIEnv *env, const char *str);

 

JNIEXPORT const char *

GetStringPlatformChars(JNIEnv *env, jstring jstr, jboolean *isCopy);

 

JNIEXPORT jstring JNICALL

JNU_NewStringPlatform(JNIEnv *env, const char *str);

 

JNIEXPORT const char * JNICALL

JNU_GetStringPlatformChars(JNIEnv *env, jstring jstr, jboolean *isCopy);

 

JNIEXPORT void JNICALL

JNU_ReleaseStringPlatformChars(JNIEnv *env, jstring jstr, const char *str);

 

 

附件 jni_util.h,jni_util.c

 

 

TUXEDO/JOLT

JOLT 对于传递的字符串需要用如下进行转码

new String(ls_tt.getBytes("GBK"),"iso8859-1")

 

对于返回的字符串

new String(error_message.getBytes("iso8859-1"),"GBK");

jolt 的系统属性 bea.jolt.encoding 不应该设置 , 如果设置 ,JSH 会报告说错误的协议 .

 

 

JDK1.4/1.5 新增部分

字符集相关类 (Charset/CharsetEncoder/CharsetDecoder)

jdk1.4 开始，对字符集的支持在 java.nio.charset 包中实现。

 

常用功能：

1 列出 jvm 所支持字符集： Charset.availableCharsets()

2 能否对看某个 Unicode 字符编码， CharsetEncoder.canEncode()

 

Unicode Surrogate/CJK EXT B

Unicode 范围一般所用为 /U0000-/UFFFF 范围， jvm 使用 1 个 char 就可以表示，对于 CJK EXT B 区汉字，范围大于 /U20000 ，则需要采用 2 个 char 方能表示，此即 Unicode Surrogate 。这 2 个 char 的值范围 落在 Character.SURROGATE 区域内，用 Character.getType() 来判断。

 

jdk 1.4 尚不能在 Swing 中正确处理 surrogate 区的 Unicode 字符， jdk1.5 可以。对于 CJK EXT B 区汉字，目前可以使用的字库为 ” 宋体 - 方正超大字符集 ”, 随 Office 安装。

 

常见问题

在 JVM 下，用 System.out.println 不能正确打印中文，显示为 ???

System.out.println 是 PrintStream ，它采用 jvm 缺省字符集进行转码工作，如果 jvm 的缺省字符集为 iso8859-1 ，则中文显示会有问题。此问题常见于 Unix 下， jvm 的区域没有明确指定的情况。

 

在英文 UNIX 环境下 , 用 System.out.println 能够正确打印汉字，但是内部处理错误

可能是汉字在输入转换时，就没有正确转码：

即 gbk 文本 à (iso8859-1 转码 ) à jvm char(iso8859-1 编码汉字 ) à (iso8859-1 转码 ) à 输出。

gbk 汉字经过两次错误转码，原封不动的被传递到输出，但是在 jvm 中，并未以正确的 unicode 编码表示，而是以一个汉字字节一个 char 的方式表示，从而导致此类错误。

 

 

GB2312-80 ， GBK ， GB18030-2000 汉字字符集

 

GB2312-80 是在国内计算机汉字信息技术发展初始阶段制定的，其中包含了大部分常用的一、二级汉字，和 9 区的符号。该字符集是几乎所有的中文系统和国际化的软件都支持的中文字符集，这也是最基本的中文字符集。其编码范围是高位 0xa1 － 0xfe ，低位也是 0xa1-0xfe ；汉字从 0xb0a1 开始，结束于 0xf7fe ；

 

GBK 是 GB2312-80 的扩展，是向上兼容的。它包含了 20902 个汉字，其编码范围是 0x8140-0xfefe ，剔除高位 0x80 的字位。其所有字符都可以一对一映射到 Unicode 2.0 ，也就是说 JAVA 实际上提供了 GBK 字符集的支持。这是现阶段 Windows 和其它一些中文操作系统的缺省字符集，但并不是所有的国际化软件都支持该字符集，感觉是他们并不完全知道 GBK 是怎么回事。值得注意的是它不是国家标准，而只是规范。随着 GB18030-2000 国标的发布，它将在不久的将来完成它的历史使命。

 

GB18030-2000(GBK2K) 在 GBK 的基础上进一步扩展了汉字，增加了藏、蒙等少数民族的字形。 GBK2K 从根本上解决了字位不够，字形不足的问题。它有几个特点，

 

它并没有确定所有的字形，只是规定了编码范围，留待以后扩充。

编码是变长的，其二字节部分与 GBK 兼容；四字节部分是扩充的字形、字位，其编码范围是首字节 0x81-0xfe 、二字节 0x30-0x39 、三字节 0x81-0xfe 、四字节 0x30-0x39 。

 

UTF-8/UTF-16/UTF-32

 

UTF ，即 Unicode Transformer Format ，是 Unicode 代码点 (code point) 的实际表示方式，按其基本长度所用位数分为 UTF-8/16/32 。它也可以认为是一种特殊的外部数据编码，但能够与 Unicode 代码点做一一对应。

 

UTF-8 是变长编码，每个 Unicode 代码点按照不同范围，可以有 1-3 字节的不同长度。

UTF-16 长度相对固定，只要不处理大于 /U200000 范围的字符，每个 Unicode 代码点使用 16 位即 2 字节表示，超出部分使用两个 UTF-16 即 4 字节表示。按照高低位字节顺序，又分为 UTF-16BE/UTF-16LE 。

UTF-32 长度始终固定，每个 Unicode 代码点使用 32 位即 4 字节表示。按照高低位字节顺序，又分为 UTF-32BE/UTF-32LE 。

 

UTF 编码有个优点，即尽管编码字节数不等，但是不像 gb2312/gbk 编码一样，需要从文本开始寻找，才能正确对汉字进行定位。在 UTF 编码下，根据相对固定的算法，从当前位置就能够知道当前字节是否是一个代码点的开始还是结束，从而相对简单的进行字符定位。不过定位问题最简单的还是 UTF-32 ，它根本不需要进行字符定位，但是相对的大小也增加不少。

 

 

关于 GCJ JVM

GCJ 并未完全依照 sun jdk 的做法，对于区域和编码问题考虑尚不够周全。 GCJ 启动时，区域始终设为 en_US ，编码也缺省为 iso8859-1 。但是可以用 Reader/Writer 做正确编码转换。