Java中文编码及各种编码互转和Java判断文件编码

Unicode UTF-8 GBK 及一点Java代码

Unicode UTF-8 GBK这些不同的编码，我们可以想象为不同的字典。同一个汉字，在不同的字典里面，我们用不同的编号保存。比如汉字"陈"在Unicode里编号为9648,在GBK里面是0xB3C2,在UTF-8中呢就是0xE99988. 大家可以通过"附件->系统工具->编码映射表"查找" 陈"这个字的编码，可以得到它的Unicode编码及GBK的编码。UTF-8的生成依赖于对应字符的Unicode编码。规则如下：

  

Unicode	UTF-8	说明
0000 - 007F	0xxxxxxx	对于这个范围的Unicode，UTF-8编码也用一个字节来表示
0080 - 07FF	110xxxxx 10xxxxxx	对于这个范围的Unicode，UTF-8编码也用两个字节来表示。在第一个字节前加上110,在后一个节里加上10
0800 - FFFF	1110xxxx 10xxxxxx 10xxxxxx	对于这个范围的Unicode，UTF-8编码也用两个字节来表示。在第一个字节前加上110,在后两个节里加上10

 

 

"陈"字落在第三个区间，它的utf-8编码需要用三个字节表示，具体转换过程如下：

①　9648的二进制编码如下 1001011001001000

②　将它分成4-6-6三段分别是 1001 011001 001000

③　分别在前面加上1110 10 10 变成如下：11101001 10011001 10001000

 

在Java当中我们可以通过如下方法输出"陈"这个字：

1) System.out.println("/u9648");

2) byte[] bs = new byte[]{(byte)179,(byte)194};

System.out.println(new String(bs,"GBK"));

注：179是B3的十进制，194是C2的十进制

3) byte[] bs = new byte[]{(byte)233,(byte)153,(byte)136};

System.out.println(new String(bs,"utf-8"));

注：数组里的值就是上面utf-8二制值对应的十进制值 

233 - 11101001,   153 - 10011001,  136 - 10001000 

 

 

反过来我们看下面的代码：

System.out.println("陈".getBytes("GBK").length);

System.out.println("陈".getBytes("UTF-8").length);

打印出来的值分别是2,3

 

关于编码的很有意思的是例子就是在一个新建的文本文件里面输入"联通"两个字，结果却不能正确显示。这是因为缺省系统文本文件用的是GBK编码输入，而联通的GBK编码如下：

 

文字	十六进制	二进制	说明
联	0xC1AA	11000001 10101010	由于它的两个字节由110 和10开头，所以双击打开的时候，把内容的GBK编码认成了UTF-8编码，所以把它当成 00001 101010 这个Unicode编码所代码的文字，这个字符的Unicode值为 /u006A，它就是字符J
通	0xCDA8	11001101 10101000	这个转换成UTF-8后，没有对应的字符存在，所以最终文档没办法正确显示

 

 

GBK中文与UTF-8字符与转例子

import java.io.UnsupportedEncodingException;

/*
 * GBK中文与UTF-8字符与转例子
 */
public class CharacterConvert {
 public static void main(String[] args) {
  String utf8 = gbkToUtf8("陈");
  System.out.println(utf8);

  System.out.println(utf8Togbk(utf8));
 }

 /*
  * 中文字符串转换为UTF-8字符串输出
  */
 public static String gbkToUtf8(String str) {
  StringBuffer sb = new StringBuffer("");
  for (int i = 0, size = str.length(); i < size; i++) {
   String s = str.substring(i, i + 1);
   try {
    byte[] bytes = s.getBytes("UTF-8");
    if (bytes.length == 3) {
     // 表示是中文,中文在UTF-8中占三个字节
     sb.append(gbkToUtf8(bytes));
    } else {
     sb.append(s);
    }
   } catch (UnsupportedEncodingException e) {
    e.printStackTrace();
   }
  }

  return sb.toString();
 }

 private static String gbkToUtf8(byte[] bytes) {
  StringBuffer sb = new StringBuffer();

  String s = Integer.toBinaryString(bytes[0]);
  s = s.substring(s.length() - 8);// 得到是32位的二进制字符串,只取后8位
  sb.append(s.substring(s.length() - 4));// 去掉前4位

  s = Integer.toBinaryString(bytes[1]);
  s = s.substring(s.length() - 8);// 得到是32位的二进制字符串,只取后8位
  sb.append(s.substring(s.length() - 6));// 去掉前2位

  s = Integer.toBinaryString(bytes[2]);
  s = s.substring(s.length() - 8);// 得到是32位的二进制字符串,只取后8位
  sb.append(s.substring(s.length() - 6));// 去掉前2位

  String utf8 = "\\u"
    + Integer.toHexString(Integer.valueOf(sb.toString(), 2));

  return utf8;
 }

 /*
  * UTF-8字符串转换为中文字符串输出 \\u开头及后4位是对应的中文
  */
 public static String utf8Togbk(String utf8) {
  int length = utf8.length();
  int index = 0;
  StringBuffer sb = new StringBuffer();
  while (index < length) {
   if (length - index < 2) {
    sb.append(utf8.charAt(index));
    index++;
   } else if ("\\u".equals(utf8.substring(index, index + 2))) {
    index += 2;
    String s = utf8.substring(index, index + 4);
    char ch = (char) Integer.parseInt(s, 16);
    try {
     s = new String((ch + "").getBytes("gbk"), "gbk");
     sb.append(s);
     index += 4;
    } catch (UnsupportedEncodingException e) {
     e.printStackTrace();
    }

   } else {
    sb.append(utf8.charAt(index));
    index++;
   }

  }

  return sb.toString();
 }

}

 

 

Java 中的中文编码问题

 

不知道大家有没有想过一个问题，那就是为什么要编码？我们能不能不编码？要回答这个问题必须要回到计算机是如何表示我们人类能够理解的符号的，这些符号也就是我们人类使用的语言。由于人类的语言有太多，因而表示这些语言的符号太多，无法用计算机中一个基本的存储单元—— byte 来表示，因而必须要经过拆分或一些翻译工作，才能让计算机能理解。我们可以把计算机能够理解的语言假定为英语，其它语言要能够在计算机中使用必须经过一次翻译，把它翻译成英语。这个翻译的过程就是编码。所以可以想象只要不是说英语的国家要能够使用计算机就必须要经过编码。这看起来有些霸道，但是这就是现状，这也和我们国家现在在大力推广汉语一样，希望其它国家都会说汉语，以后其它的语言都翻译成汉语，我们可以把计算机中存储信息的最小单位改成汉字，这样我们就不存在编码问题了。

所以总的来说，编码的原因可以总结为：

1. 计算机中存储信息的最小单元是一个字节即 8 个 bit，所以能表示的字符范围是 0~255 个
2. 人类要表示的符号太多，无法用一个字节来完全表示
3. 要解决这个矛盾必须需要一个新的数据结构 char，从 char 到 byte 必须编码

 

明白了各种语言需要交流，经过翻译是必要的，那又如何来翻译呢？计算中提拱了多种翻译方式，常见的有 ASCII、ISO-8859-1、GB2312、GBK、UTF-8、UTF-16 等。它们都可以被看作为字典，它们规定了转化的规则，按照这个规则就可以让计算机正确的表示我们的字符。目前的编码格式很多，例如 GB2312、GBK、UTF-8、UTF-16 这几种格式都可以表示一个汉字，那我们到底选择哪种编码格式来存储汉字呢？这就要考虑到其它因素了，是存储空间重要还是编码的效率重要。根据这些因素来正确选择编码格式，下面简要介绍一下这几种编码格式。

• ASCII 码

学过计算机的人都知道 ASCII 码，总共有 128 个，用一个字节的低 7 位表示，0~31 是控制字符如换行回车删除等；32~126 是打印字符，可以通过键盘输入并且能够显示出来。

• ISO-8859-1

128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码基础上又制定了一些列标准用来扩展 ASCII 编码，它们是 ISO-8859-1~ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所有应用的最广泛。ISO-8859-1 仍然是单字节编码，它总共能表示 256 个字符。

• GB2312

它的全称是《信息交换用汉字编码字符集 基本集》，它是双字节编码，总的编码范围是 A1-F7，其中从 A1-A9 是符号区，总共包含 682 个符号，从 B0-F7 是汉字区，包含 6763 个汉字。

• GBK

全称叫《汉字内码扩展规范》，是国家技术监督局为 windows95 所制定的新的汉字内码规范，它的出现是为了扩展 GB2312，加入更多的汉字，它的编码范围是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能表示 21003 个汉字，它的编码是和 GB2312 兼容的，也就是说用 GB2312 编码的汉字可以用 GBK 来解码，并且不会有乱码。

• GB18030

全称是《信息交换用汉字编码字符集》，是我国的强制标准，它可能是单字节、双字节或者四字节编码，它的编码与 GB2312 编码兼容，这个虽然是国家标准，但是实际应用系统中使用的并不广泛。

• UTF-16

说到 UTF 必须要提到 Unicode（Universal Code 统一码），ISO 试图想创建一个全新的超语言字典，世界上所有的语言都可以通过这本字典来相互翻译。可想而知这个字典是多么的复杂，关于 Unicode 的详细规范可以参考相应文档。Unicode 是 Java 和 XML 的基础，下面详细介绍 Unicode 在计算机中的存储形式。

UTF-16 具体定义了 Unicode 字符在计算机中存取方法。UTF-16 用两个字节来表示 Unicode 转化格式，这个是定长的表示方法，不论什么字符都可以用两个字节表示，两个字节是 16 个 bit，所以叫 UTF-16。UTF-16 表示字符非常方便，每两个字节表示一个字符，这个在字符串操作时就大大简化了操作，这也是 Java 以 UTF-16 作为内存的字符存储格式的一个很重要的原因。

• UTF-8

UTF-16 统一采用两个字节表示一个字符，虽然在表示上非常简单方便，但是也有其缺点，有很大一部分字符用一个字节就可以表示的现在要两个字节表示，存储空间放大了一倍，在现在的网络带宽还非常有限的今天，这样会增大网络传输的流量，而且也没必要。而 UTF-8 采用了一种变长技术，每个编码区域有不同的字码长度。不同类型的字符可以是由 1~6 个字节组成。

UTF-8 有以下编码规则：

1. 如果一个字节，最高位（第 8 位）为 0，表示这是一个 ASCII 字符（00 - 7F）。可见，所有 ASCII 编码已经是 UTF-8 了。
2. 如果一个字节，以 11 开头，连续的 1 的个数暗示这个字符的字节数，例如：110xxxxx 代表它是双字节 UTF-8 字符的首字节。
3. 如果一个字节，以 10 开始，表示它不是首字节，需要向前查找才能得到当前字符的首字节

---

 

前面描述了常见的几种编码格式，下面将介绍 Java 中如何处理对编码的支持，什么场合中需要编码。

 

我们知道涉及到编码的地方一般都在字符到字节或者字节到字符的转换上，而需要这种转换的场景主要是在 I/O 的时候，这个 I/O 包括磁盘 I/O 和网络 I/O，关于网络 I/O 部分在后面将主要以 Web 应用为例介绍。下图是 Java 中处理 I/O 问题的接口：

Reader 类是 Java 的 I/O 中读字符的父类，而 InputStream 类是读字节的父类，InputStreamReader 类就是关联字节到字符的桥梁，它负责在 I/O 过程中处理读取字节到字符的转换，而具体字节到字符的解码实现它由 StreamDecoder 去实现，在 StreamDecoder 解码过程中必须由用户指定 Charset 编码格式。值得注意的是如果你没有指定 Charset，将使用本地环境中的默认字符集，例如在中文环境中将使用 GBK 编码。

写的情况也是类似，字符的父类是 Writer，字节的父类是 OutputStream，通过 OutputStreamWriter 转换字符到字节。如下图所示：

同样 StreamEncoder 类负责将字符编码成字节，编码格式和默认编码规则与解码是一致的。

如下面一段代码，实现了文件的读写功能：

String file = "c:/stream.txt"; String charset = "UTF-8"; // 写字符换转成字节流 FileOutputStream outputStream = new FileOutputStream(file); OutputStreamWriter writer = new OutputStreamWriter( outputStream, charset); try { writer.write("这是要保存的中文字符"); } finally { writer.close(); } // 读取字节转换成字符 FileInputStream inputStream = new FileInputStream(file); InputStreamReader reader = new InputStreamReader( inputStream, charset); StringBuffer buffer = new StringBuffer(); char[] buf = new char[64]; int count = 0; try { while ((count = reader.read(buf)) != -1) { buffer.append(buffer, 0, count); } } finally { reader.close(); }

在我们的应用程序中涉及到 I/O 操作时只要注意指定统一的编解码 Charset 字符集，一般不会出现乱码问题，有些应用程序如果不注意指定字符编码，中文环境中取操作系统默认编码，如果编解码都在中文环境中，通常也没问题，但是还是强烈的不建议使用操作系统的默认编码，因为这样，你的应用程序的编码格式就和运行环境绑定起来了，在跨环境下很可能出现乱码问题。

 

在 Java 开发中除了 I/O 涉及到编码外，最常用的应该就是在内存中进行字符到字节的数据类型的转换，Java 中用 String 表示字符串，所以 String 类就提供转换到字节的方法，也支持将字节转换为字符串的构造函数。如下代码示例：

String s = "这是一段中文字符串"; byte[] b = s.getBytes("UTF-8"); String n = new String(b,"UTF-8");

另外一个是已经被被废弃的 ByteToCharConverter 和 CharToByteConverter 类，它们分别提供了 convertAll 方法可以实现 byte[] 和 char[] 的互转。如下代码所示：

ByteToCharConverter charConverter = ByteToCharConverter.getConverter("UTF-8"); char c[] = charConverter.convertAll(byteArray); CharToByteConverter byteConverter = CharToByteConverter.getConverter("UTF-8"); byte[] b = byteConverter.convertAll(c);

这两个类已经被 Charset 类取代，Charset 提供 encode 与 decode 分别对应 char[] 到 byte[] 的编码和 byte[] 到 char[] 的解码。如下代码所示：

Charset charset = Charset.forName("UTF-8"); ByteBuffer byteBuffer = charset.encode(string); CharBuffer charBuffer = charset.decode(byteBuffer);

编码与解码都在一个类中完成，通过 forName 设置编解码字符集，这样更容易统一编码格式，比 ByteToCharConverter 和 CharToByteConverter 类更方便。

Java 中还有一个 ByteBuffer 类，它提供一种 char 和 byte 之间的软转换，它们之间转换不需要编码与解码，只是把一个 16bit 的 char 格式，拆分成为 2 个 8bit 的 byte 表示，它们的实际值并没有被修改，仅仅是数据的类型做了转换。如下代码所以：

ByteBuffer heapByteBuffer = ByteBuffer.allocate(1024); ByteBuffer byteBuffer = heapByteBuffer.putChar(c);

以上这些提供字符和字节之间的相互转换只要我们设置编解码格式统一一般都不会出现问题。

---

 

前面介绍了几种常见的编码格式，这里将以实际例子介绍 Java 中如何实现编码及解码，下面我们以“I am 君山”这个字符串为例介绍 Java 中如何把它以 ISO-8859-1、GB2312、GBK、UTF-16、UTF-8 编码格式进行编码的。

public static void encode() { String name = "I am 君山"; toHex(name.toCharArray()); try { byte[] iso8859 = name.getBytes("ISO-8859-1"); toHex(iso8859); byte[] gb2312 = name.getBytes("GB2312"); toHex(gb2312); byte[] gbk = name.getBytes("GBK"); toHex(gbk); byte[] utf16 = name.getBytes("UTF-16"); toHex(utf16); byte[] utf8 = name.getBytes("UTF-8"); toHex(utf8); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } }

我们把 name 字符串按照前面说的几种编码格式进行编码转化成 byte 数组，然后以 16 进制输出，我们先看一下 Java 是如何进行编码的。

下面是 Java 中编码需要用到的类图

图 1. Java 编码类图

首先根据指定的 charsetName 通过 Charset.forName(charsetName) 设置 Charset 类，然后根据 Charset 创建 CharsetEncoder 对象，再调用 CharsetEncoder.encode 对字符串进行编码，不同的编码类型都会对应到一个类中，实际的编码过程是在这些类中完成的。下面是 String. getBytes(charsetName) 编码过程的时序图

图 2.Java 编码时序图

从上图可以看出根据 charsetName 找到 Charset 类，然后根据这个字符集编码生成 CharsetEncoder，这个类是所有字符编码的父类，针对不同的字符编码集在其子类中定义了如何实现编码，有了 CharsetEncoder 对象后就可以调用 encode 方法去实现编码了。这个是 String.getBytes 编码方法，其它的如 StreamEncoder 中也是类似的方式。下面看看不同的字符集是如何将前面的字符串编码成 byte 数组的？

如字符串“I am 君山”的 char 数组为 49 20 61 6d 20 541b 5c71，下面把它按照不同的编码格式转化成相应的字节。

 

字符串“I am 君山”用 ISO-8859-1 编码，下面是编码结果：

从上图看出 7 个 char 字符经过 ISO-8859-1 编码转变成 7 个 byte 数组，ISO-8859-1 是单字节编码，中文“君山”被转化成值是 3f 的 byte。3f 也就是“？”字符，所以经常会出现中文变成“？”很可能就是错误的使用了 ISO-8859-1 这个编码导致的。中文字符经过 ISO-8859-1 编码会丢失信息，通常我们称之为“黑洞”，它会把不认识的字符吸收掉。由于现在大部分基础的 Java 框架或系统默认的字符集编码都是 ISO-8859-1，所以很容易出现乱码问题，后面将会分析不同的乱码形式是怎么出现的。

 

字符串“I am 君山”用 GB2312 编码，下面是编码结果：

GB2312 对应的 Charset 是 sun.nio.cs.ext. EUC_CN 而对应的 CharsetDecoder 编码类是 sun.nio.cs.ext. DoubleByte，GB2312 字符集有一个 char 到 byte 的码表，不同的字符编码就是查这个码表找到与每个字符的对应的字节，然后拼装成 byte 数组。查表的规则如下：

c2b[c2bIndex[char >> 8] + (char & 0xff)]

如果查到的码位值大于 oxff 则是双字节，否则是单字节。双字节高 8 位作为第一个字节，低 8 位作为第二个字节，如下代码所示：

if (bb > 0xff) { // DoubleByte if (dl - dp < 2) return CoderResult.OVERFLOW; da[dp++] = (byte) (bb >> 8); da[dp++] = (byte) bb; } else { // SingleByte if (dl - dp < 1) return CoderResult.OVERFLOW; da[dp++] = (byte) bb; }

从上图可以看出前 5 个字符经过编码后仍然是 5 个字节，而汉字被编码成双字节，在第一节中介绍到 GB2312 只支持 6763 个汉字，所以并不是所有汉字都能够用 GB2312 编码。

 

字符串“I am 君山”用 GBK 编码，下面是编码结果：

你可能已经发现上图与 GB2312 编码的结果是一样的，没错 GBK 与 GB2312 编码结果是一样的，由此可以得出 GBK 编码是兼容 GB2312 编码的，它们的编码算法也是一样的。不同的是它们的码表长度不一样，GBK 包含的汉字字符更多。所以只要是经过 GB2312 编码的汉字都可以用 GBK 进行解码，反过来则不然。

 

字符串“I am 君山”用 UTF-16 编码，下面是编码结果：

用 UTF-16 编码将 char 数组放大了一倍，单字节范围内的字符，在高位补 0 变成两个字节，中文字符也变成两个字节。从 UTF-16 编码规则来看，仅仅将字符的高位和地位进行拆分变成两个字节。特点是编码效率非常高，规则很简单，由于不同处理器对 2 字节处理方式不同，Big-endian（高位字节在前，低位字节在后）或 Little-endian（低位字节在前，高位字节在后）编码，所以在对一串字符串进行编码是需要指明到底是 Big-endian 还是 Little-endian，所以前面有两个字节用来保存 BYTE_ORDER_MARK 值，UTF-16 是用定长 16 位（2 字节）来表示的 UCS-2 或 Unicode 转换格式，通过代理对来访问 BMP 之外的字符编码。

 

字符串“I am 君山”用 UTF-8 编码，下面是编码结果：

UTF-16 虽然编码效率很高，但是对单字节范围内字符也放大了一倍，这无形也浪费了存储空间，另外 UTF-16 采用顺序编码，不能对单个字符的编码值进行校验，如果中间的一个字符码值损坏，后面的所有码值都将受影响。而 UTF-8 这些问题都不存在，UTF-8 对单字节范围内字符仍然用一个字节表示，对汉字采用三个字节表示。它的编码规则如下：

private CoderResult encodeArrayLoop(CharBuffer src, ByteBuffer dst){ char[] sa = src.array(); int sp = src.arrayOffset() + src.position(); int sl = src.arrayOffset() + src.limit(); byte[] da = dst.array(); int dp = dst.arrayOffset() + dst.position(); int dl = dst.arrayOffset() + dst.limit(); int dlASCII = dp + Math.min(sl - sp, dl - dp); // ASCII only loop while (dp < dlASCII && sa[sp] < '\u0080') da[dp++] = (byte) sa[sp++]; while (sp < sl) { char c = sa[sp]; if (c < 0x80) { // Have at most seven bits if (dp >= dl) return overflow(src, sp, dst, dp); da[dp++] = (byte)c; } else if (c < 0x800) { // 2 bytes, 11 bits if (dl - dp < 2) return overflow(src, sp, dst, dp); da[dp++] = (byte)(0xc0 | (c >> 6)); da[dp++] = (byte)(0x80 | (c & 0x3f)); } else if (Character.isSurrogate(c)) { // Have a surrogate pair if (sgp == null) sgp = new Surrogate.Parser(); int uc = sgp.parse(c, sa, sp, sl); if (uc < 0) { updatePositions(src, sp, dst, dp); return sgp.error(); } if (dl - dp < 4) return overflow(src, sp, dst, dp); da[dp++] = (byte)(0xf0 | ((uc >> 18))); da[dp++] = (byte)(0x80 | ((uc >> 12) & 0x3f)); da[dp++] = (byte)(0x80 | ((uc >> 6) & 0x3f)); da[dp++] = (byte)(0x80 | (uc & 0x3f)); sp++; // 2 chars } else { // 3 bytes, 16 bits if (dl - dp < 3) return overflow(src, sp, dst, dp); da[dp++] = (byte)(0xe0 | ((c >> 12))); da[dp++] = (byte)(0x80 | ((c >> 6) & 0x3f)); da[dp++] = (byte)(0x80 | (c & 0x3f)); } sp++; } updatePositions(src, sp, dst, dp); return CoderResult.UNDERFLOW; }

UTF-8 编码与 GBK 和 GB2312 不同，不用查码表，所以在编码效率上 UTF-8 的效率会更好，所以在存储中文字符时 UTF-8 编码比较理想。

 

对中文字符后面四种编码格式都能处理，GB2312 与 GBK 编码规则类似，但是 GBK 范围更大，它能处理所有汉字字符，所以 GB2312 与 GBK 比较应该选择 GBK。UTF-16 与 UTF-8 都是处理 Unicode 编码，它们的编码规则不太相同，相对来说 UTF-16 编码效率最高，字符到字节相互转换更简单，进行字符串操作也更好。它适合在本地磁盘和内存之间使用，可以进行字符和字节之间快速切换，如 Java 的内存编码就是采用 UTF-16 编码。但是它不适合在网络之间传输，因为网络传输容易损坏字节流，一旦字节流损坏将很难恢复，想比较而言 UTF-8 更适合网络传输，对 ASCII 字符采用单字节存储，另外单个字符损坏也不会影响后面其它字符，在编码效率上介于 GBK 和 UTF-16 之间，所以 UTF-8 在编码效率上和编码安全性上做了平衡，是理想的中文编码方式。

---

 

对于使用中文来说，有 I/O 的地方就会涉及到编码，前面已经提到了 I/O 操作会引起编码，而大部分 I/O 引起的乱码都是网络 I/O，因为现在几乎所有的应用程序都涉及到网络操作，而数据经过网络传输都是以字节为单位的，所以所有的数据都必须能够被序列化为字节。在 Java 中数据被序列化必须继承 Serializable 接口。

这里有一个问题，你是否认真考虑过一段文本它的实际大小应该怎么计算，我曾经碰到过一个问题：就是要想办法压缩 Cookie 大小，减少网络传输量，当时有选择不同的压缩算法，发现压缩后字符数是减少了，但是并没有减少字节数。所谓的压缩只是将多个单字节字符通过编码转变成一个多字节字符。减少的是 String.length()，而并没有减少最终的字节数。例如将“ab”两个字符通过某种编码转变成一个奇怪的字符，虽然字符数从两个变成一个，但是如果采用 UTF-8 编码这个奇怪的字符最后经过编码可能又会变成三个或更多的字节。同样的道理比如整型数字 1234567 如果当成字符来存储，采用 UTF-8 来编码占用 7 个 byte，采用 UTF-16 编码将会占用 14 个 byte，但是把它当成 int 型数字来存储只需要 4 个 byte 来存储。所以看一段文本的大小，看字符本身的长度是没有意义的，即使是一样的字符采用不同的编码最终存储的大小也会不同，所以从字符到字节一定要看编码类型。

另外一个问题，你是否考虑过，当我们在电脑中某个文本编辑器里输入某个汉字时，它到底是怎么表示的？我们知道，计算机里所有的信息都是以 01 表示的，那么一个汉字，它到底是多少个 0 和 1 呢？我们能够看到的汉字都是以字符形式出现的，例如在 Java 中“淘宝”两个字符，它在计算机中的数值 10 进制是 28120 和 23453，16 进制是 6bd8 和 5d9d，也就是这两个字符是由这两个数字唯一表示的。Java 中一个 char 是 16 个 bit 相当于两个字节，所以两个汉字用 char 表示在内存中占用相当于四个字节的空间。

这两个问题搞清楚后，我们看一下 Java Web 中那些地方可能会存在编码转换？

用户从浏览器端发起一个 HTTP 请求，需要存在编码的地方是 URL、Cookie、Parameter。服务器端接受到 HTTP 请求后要解析 HTTP 协议，其中 URI、Cookie 和 POST 表单参数需要解码，服务器端可能还需要读取数据库中的数据，本地或网络中其它地方的文本文件，这些数据都可能存在编码问题，当 Servlet 处理完所有请求的数据后，需要将这些数据再编码通过 Socket 发送到用户请求的浏览器里，再经过浏览器解码成为文本。这些过程如下图所示：

图 3. 一次 HTTP 请求的编码示例（查看大图）

如上图所示一次 HTTP 请求设计到很多地方需要编解码，它们编解码的规则是什么？下面将会重点阐述一下：

 

用户提交一个 URL，这个 URL 中可能存在中文，因此需要编码，如何对这个 URL 进行编码？根据什么规则来编码？有如何来解码？如下图一个 URL：

图 4.URL 的几个组成部分

上图中以 Tomcat 作为 Servlet Engine 为例，它们分别对应到下面这些配置文件中：

Port 对应在 Tomcat 的 <Connector port="8080"/> 中配置，而 Context Path 在 <Context path="/examples"/> 中配置，Servlet Path 在 Web 应用的 web.xml 中的

<servlet-mapping> <servlet-name>junshanExample</servlet-name> <url-pattern>/servlets/servlet/*</url-pattern> </servlet-mapping>

<url-pattern> 中配置，PathInfo 是我们请求的具体的 Servlet，QueryString 是要传递的参数，注意这里是在浏览器里直接输入 URL 所以是通过 Get 方法请求的，如果是 POST 方法请求的话，QueryString 将通过表单方式提交到服务器端，这个将在后面再介绍。

上图中 PathInfo 和 QueryString 出现了中文，当我们在浏览器中直接输入这个 URL 时，在浏览器端和服务端会如何编码和解析这个 URL 呢？为了验证浏览器是怎么编码 URL 的我们选择 FireFox 浏览器并通过 HTTPFox 插件观察我们请求的 URL 的实际的内容，以下是 URL：HTTP://localhost:8080/examples/servlets/servlet/ 君山 ?author= 君山在中文 FireFox3.6.12 的测试结果

图 5. HTTPFox 的测试结果

君山的编码结果分别是：e5 90 9b e5 b1 b1，be fd c9 bd，查阅上一届的编码可知，PathInfo 是 UTF-8 编码而 QueryString 是经过 GBK 编码，至于为什么会有“%”？查阅 URL 的编码规范 RFC3986 可知浏览器编码 URL 是将非 ASCII 字符按照某种编码格式编码成 16 进制数字然后将每个 16 进制表示的字节前加上“%”，所以最终的 URL 就成了上图的格式了。

默认情况下中文 IE 最终的编码结果也是一样的，不过 IE 浏览器可以修改 URL 的编码格式在选项 -> 高级 -> 国际里面的发送 UTF-8 URL 选项可以取消。

从上面测试结果可知浏览器对 PathInfo 和 QueryString 的编码是不一样的，不同浏览器对 PathInfo 也可能不一样，这就对服务器的解码造成很大的困难，下面我们以 Tomcat 为例看一下，Tomcat 接受到这个 URL 是如何解码的。

解析请求的 URL 是在 org.apache.coyote.HTTP11.InternalInputBuffer 的 parseRequestLine 方法中，这个方法把传过来的 URL 的 byte[] 设置到 org.apache.coyote.Request 的相应的属性中。这里的 URL 仍然是 byte 格式，转成 char 是在 org.apache.catalina.connector.CoyoteAdapter 的 convertURI 方法中完成的：

protected void convertURI(MessageBytes uri, Request request) throws Exception { ByteChunk bc = uri.getByteChunk(); int length = bc.getLength(); CharChunk cc = uri.getCharChunk(); cc.allocate(length, -1); String enc = connector.getURIEncoding(); if (enc != null) { B2CConverter conv = request.getURIConverter(); try { if (conv == null) { conv = new B2CConverter(enc); request.setURIConverter(conv); } } catch (IOException e) {...} if (conv != null) { try { conv.convert(bc, cc, cc.getBuffer().length - cc.getEnd()); uri.setChars(cc.getBuffer(), cc.getStart(), cc.getLength()); return; } catch (IOException e) {...} } } // Default encoding: fast conversion byte[] bbuf = bc.getBuffer(); char[] cbuf = cc.getBuffer(); int start = bc.getStart(); for (int i = 0; i < length; i++) { cbuf[i] = (char) (bbuf[i + start] & 0xff); } uri.setChars(cbuf, 0, length); }

从上面的代码中可以知道对 URL 的 URI 部分进行解码的字符集是在 connector 的 <Connector URIEncoding=”UTF-8”/> 中定义的，如果没有定义，那么将以默认编码 ISO-8859-1 解析。所以如果有中文 URL 时最好把 URIEncoding 设置成 UTF-8 编码。

QueryString 又如何解析？ GET 方式 HTTP 请求的 QueryString 与 POST 方式 HTTP 请求的表单参数都是作为 Parameters 保存，都是通过 request.getParameter 获取参数值。对它们的解码是在 request.getParameter 方法第一次被调用时进行的。request.getParameter 方法被调用时将会调用 org.apache.catalina.connector.Request 的 parseParameters 方法。这个方法将会对 GET 和 POST 方式传递的参数进行解码，但是它们的解码字符集有可能不一样。POST 表单的解码将在后面介绍，QueryString 的解码字符集是在哪定义的呢？它本身是通过 HTTP 的 Header 传到服务端的，并且也在 URL 中，是否和 URI 的解码字符集一样呢？从前面浏览器对 PathInfo 和 QueryString 的编码采取不同的编码格式不同可以猜测到解码字符集肯定也不会是一致的。的确是这样 QueryString 的解码字符集要么是 Header 中 ContentType 中定义的 Charset 要么就是默认的 ISO-8859-1，要使用 ContentType 中定义的编码就要设置 connector 的 <Connector URIEncoding=”UTF-8” useBodyEncodingForURI=”true”/> 中的 useBodyEncodingForURI 设置为 true。这个配置项的名字有点让人产生混淆，它并不是对整个 URI 都采用 BodyEncoding 进行解码而仅仅是对 QueryString 使用 BodyEncoding 解码，这一点还要特别注意。

从上面的 URL 编码和解码过程来看，比较复杂，而且编码和解码并不是我们在应用程序中能完全控制的，所以在我们的应用程序中应该尽量避免在 URL 中使用非 ASCII 字符，不然很可能会碰到乱码问题，当然在我们的服务器端最好设置 <Connector/> 中的 URIEncoding 和 useBodyEncodingForURI 两个参数。

 

当客户端发起一个 HTTP 请求除了上面的 URL 外还可能会在 Header 中传递其它参数如 Cookie、redirectPath 等，这些用户设置的值很可能也会存在编码问题，Tomcat 对它们又是怎么解码的呢？

对 Header 中的项进行解码也是在调用 request.getHeader 是进行的，如果请求的 Header 项没有解码则调用 MessageBytes 的 toString 方法，这个方法将从 byte 到 char 的转化使用的默认编码也是 ISO-8859-1，而我们也不能设置 Header 的其它解码格式，所以如果你设置 Header 中有非 ASCII 字符解码肯定会有乱码。

我们在添加 Header 时也是同样的道理，不要在 Header 中传递非 ASCII 字符，如果一定要传递的话，我们可以先将这些字符用 org.apache.catalina.util.URLEncoder 编码然后再添加到 Header 中，这样在浏览器到服务器的传递过程中就不会丢失信息了，如果我们要访问这些项时再按照相应的字符集解码就好了。

 

在前面提到了 POST 表单提交的参数的解码是在第一次调用 request.getParameter 发生的，POST 表单参数传递方式与 QueryString 不同，它是通过 HTTP 的 BODY 传递到服务端的。当我们在页面上点击 submit 按钮时浏览器首先将根据 ContentType 的 Charset 编码格式对表单填的参数进行编码然后提交到服务器端，在服务器端同样也是用 ContentType 中字符集进行解码。所以通过 POST 表单提交的参数一般不会出现问题，而且这个字符集编码是我们自己设置的，可以通过 request.setCharacterEncoding(charset) 来设置。

另外针对 multipart/form-data 类型的参数，也就是上传的文件编码同样也是使用 ContentType 定义的字符集编码，值得注意的地方是上传文件是用字节流的方式传输到服务器的本地临时目录，这个过程并没有涉及到字符编码，而真正编码是在将文件内容添加到 parameters 中，如果用这个编码不能编码时将会用默认编码 ISO-8859-1 来编码。

 

当用户请求的资源已经成功获取后，这些内容将通过 Response 返回给客户端浏览器，这个过程先要经过编码再到浏览器进行解码。这个过程的编解码字符集可以通过 response.setCharacterEncoding 来设置，它将会覆盖 request.getCharacterEncoding 的值，并且通过 Header 的 Content-Type 返回客户端，浏览器接受到返回的 socket 流时将通过 Content-Type 的 charset 来解码，如果返回的 HTTP Header 中 Content-Type 没有设置 charset，那么浏览器将根据 Html 的 <meta HTTP-equiv="Content-Type" content="text/html; charset=GBK" /> 中的 charset 来解码。如果也没有定义的话，那么浏览器将使用默认的编码来解码。

 

除了 URL 和参数编码问题外，在服务端还有很多地方可能存在编码，如可能需要读取 xml、velocity 模版引擎、JSP 或者从数据库读取数据等。

xml 文件可以通过设置头来制定编码格式

<?xml version="1.0" encoding="UTF-8"?>

Velocity 模版设置编码格式：

services.VelocityService.input.encoding=UTF-8

JSP 设置编码格式：

<%@page contentType="text/html; charset=UTF-8"%>

访问数据库都是通过客户端 JDBC 驱动来完成，用 JDBC 来存取数据要和数据的内置编码保持一致，可以通过设置 JDBC URL 来制定如 MySQL：url="jdbc:mysql://localhost:3306/DB?useUnicode=true&characterEncoding=GBK"。 

---

 

在了解了 Java Web 中可能需要编码的地方后，下面看一下，当我们碰到一些乱码时，应该怎么处理这些问题？出现乱码问题唯一的原因都是在 char 到 byte 或 byte 到 char 转换中编码和解码的字符集不一致导致的，由于往往一次操作涉及到多次编解码，所以出现乱码时很难查找到底是哪个环节出现了问题，下面就几种常见的现象进行分析。

 

例如，字符串“淘！我喜欢！”变成了“Ì Ô £ ¡Î Ò Ï²»¶ £ ¡”编码过程如下图所示

字符串在解码时所用的字符集与编码字符集不一致导致汉字变成了看不懂的乱码，而且是一个汉字字符变成两个乱码字符。

 

例如，字符串“淘！我喜欢！”变成了“？？？？？？”编码过程如下图所示

将中文和中文符号经过不支持中文的 ISO-8859-1 编码后，所有字符变成了“？”，这是因为用 ISO-8859-1 进行编解码时遇到不在码值范围内的字符时统一用 3f 表示，这也就是通常所说的“黑洞”，所有 ISO-8859-1 不认识的字符都变成了“？”。

 

例如，字符串“淘！我喜欢！”变成了“？？？？？？？？？？？？”编码过程如下图所示

这种情况比较复杂，中文经过多次编码，但是其中有一次编码或者解码不对仍然会出现中文字符变成“？”现象，出现这种情况要仔细查看中间的编码环节，找出出现编码错误的地方。

 

还有一种情况是在我们通过 request.getParameter 获取参数值时，当我们直接调用

String value = request.getParameter(name);

会出现乱码，但是如果用下面的方式

String value = String(request.getParameter(name).getBytes(" ISO-8859-1"), "GBK");

解析时取得的 value 会是正确的汉字字符，这种情况是怎么造成的呢？

看下如所示：

这种情况是这样的，ISO-8859-1 字符集的编码范围是 0000-00FF，正好和一个字节的编码范围相对应。这种特性保证了使用 ISO-8859-1 进行编码和解码可以保持编码数值“不变”。虽然中文字符在经过网络传输时，被错误地“拆”成了两个欧洲字符，但由于输出时也是用 ISO-8859-1，结果被“拆”开的中文字的两半又被合并在一起，从而又刚好组成了一个正确的汉字。虽然最终能取得正确的汉字，但是还是不建议用这种不正常的方式取得参数值，因为这中间增加了一次额外的编码与解码，这种情况出现乱码时因为 Tomcat 的配置文件中 useBodyEncodingForURI 配置项没有设置为”true”，从而造成第一次解析式用 ISO-8859-1 来解析才造成乱码的。

---

 

本文首先总结了几种常见编码格式的区别，然后介绍了支持中文的几种编码格式，并比较了它们的使用场景。接着介绍了 Java 那些地方会涉及到编码问题，已经 Java 中如何对编码的支持。并以网络 I/O 为例重点介绍了 HTTP 请求中的存在编码的地方，以及 Tomcat 对 HTTP 协议的解析，最后分析了我们平常遇到的乱码问题出现的原因。

综上所述，要解决中文问题，首先要搞清楚哪些地方会引起字符到字节的编码以及字节到字符的解码，最常见的地方就是读取会存储数据到磁盘，或者数据要经过网络传输。然后针对这些地方搞清楚操作这些数据的框架的或系统是如何控制编码的，正确设置编码格式，避免使用软件默认的或者是操作系统平台默认的编码格式。

 

JDK自带的转码工具 native2ascii.exe

 

activetoascii国际化中文转换it 分类：java
在做Java开发的时候，常常会出现一些乱码，或者无法正确识别或读取的文件，原因是编码方式的不一致。native2ascii是sun java sdk提供的一个工具。用来将别的文本类文件（比如*.txt,*.ini,*.properties,*.java等等）编码转为Unicode编码。
一．获取native2ascii
　　安装了jdk后，假如你是在windows上安装，那么在jdk的安装目录下，会有一个bin目录，其中native2ascii.exe正是。

二．使用方法
命令行格式：

native2ascii.exe -[options] [inputfile [outputfile]]
其中：
　　-[options]表示命令开关，有两个选项可供选择：
　　　　-reverse：用Latin-1或Unicode编码把文件转换成本地编码格式
　　　　-encoding encoding_name：要把文件转换的目标编码
　　inputfile：表示输入文件全名。
　　outputfile：输出文件名。如果缺少此参数，将输出到控制台。

具体介绍如下：
1．命令行交互方式
　　在这种方式下通过手工输入字符实时在Console中实现交互转码。退出按Ctrl+c
　　1)本地编码→Latin编码：
　　　直接敲入native2ascii.exe，程序光标会停在下一行,这时你可以直接敲入想要转换的字符，例如：

D:\jdk1.5.0_06\bin>native2ascii.exe
　 我们
　 \u6211\u4eec
　　2)Latin-1编码→指定编码：
　　　直接敲入native2ascii.exe -reverse，程序光标会停在下一行,这时你可以直接敲入想要转换的字符，例如：

D:\jdk1.5.0_06\bin>native2ascii.exe -reverse
　 \u6211\u4eec
　 我们
2．文件转换方式
　　在这种方式下通过指定inputfile和outputfile来实现转码。
　　1)指定编码→Latin编码：
　　　　例如：

D:\jdk1.5.0_06\bin>native2ascii.exe -encoding utf8 abc.txt bcd.txt
　　2)Latin-1编码→指定编码：
　　　　例如：

D:\jdk1.5.0_06\bin>native2ascii.exe -reverse utf8 abc.txt bcd.txt

native2ascii.exe 是 Java 的一个文件转码工具，是将特殊各异的内容转为 用指定的编码标准文体形式统一的表现出来，它通常位于 JDK_home\bin 目录下，安装好 Java SE 后，可在命令行直接使用 native2ascii 命令进行转码，示例：

native2ascii -encoding 8859_1 c:\test.txt c:\temp.txt
将 test.txt 文件内容用 8859_1 转码，另存为 temp.txt 文件
格式：native2ascii -[options] [inputfile [outputfile]]

参数选项 options
-reverse：将 Latin-1 或 Unicode 编码转为本地编码
-encoding encoding_name：指定转换时使用的编码
inputfile：要转换的文件
outputfile：转换后的文件

互转（-encoding，非英文内容（如中文）转为编码符 或 编码符之间的转换），
逆转（-reverse，通常是将编码符转为非英文内容，或非英文内容之间的转换），
逆转时被转的文件编码和本地编码需一致，示例：

中文转为 ISO 8859_1 编码后，将 8859_1 码转为中文：
native2ascii -encoding 8859_1 c:\a.txt c:\b.txt，将 a 用 8859_1 转码，存为 b (8859_1 码)
native2ascii -encoding GBK c:\b.txt c:\c.txt，将 b 用 GBK 转码，存为 c (GBK 码)
native2ascii -reverse c:\c.txt c:\d.txt，将 GBK 编码 c 用本地编码转码，存为 d (中文内容)

中文转为 GBK 编码后，将 GBK 码转为中文：
native2ascii -encoding GBK c:\a.txt c:\b.txt，将 a 用 GBK 转码，存为 b (GBK 码)
native2ascii -reverse c:\b.txt c:\c.txt，将 GBK 编码 b 用本地编码转码，存为 c (中文内容)

例如struts和struts2中的国际化utf-8的转换方式：
native2ascii -encoding UTF-8 ApplicationResources_zh_src.properties ApplicationResources_zh.properties

 

Java判断文件编码格式

1：简单判断是UTF-8或不是UTF-8，因为一般除了UTF-8之外就是GBK，所以就设置默认为GBK。

    按照给定的字符集存储文件时，在文件的最开头的三个字节中就有可能存储着编码信息，所以，基本的原理就是只要读出文件前三个字节，判定这些字节的值，就可以得知其编码的格式。其实，如果项目运行的平台就是中文操作系统，如果这些文本文件在项目内产生，即开发人员可以控制文本的编码格式，只要判定两种常见的编码就可以了：GBK和UTF-8。由于中文Windows默认的编码是GBK，所以一般只要判定UTF-8编码格式。
    对于UTF-8编码格式的文本文件，其前3个字节的值就是-17、-69、-65，所以，判定是否是UTF-8编码格式的代码片段如下：
File file = new File(path);
InputStream in= new java.io.FileInputStream(file);
byte[] b = new byte[3];
in.read(b);
in.close();
if (b[0] == -17 && b[1] == -69 && b[2] == -65)
System.out.println(file.getName() + "：编码为UTF-8");
else
System.out.println(file.getName() + "：可能是GBK，也可能是其他编码");

通过这个方法，只要知道文件头存储的编码信息，可以类似判断文件是否是某一编码格式的文件，不再限于是否是utf-8，就不在赘述。注意这个方法的局限：文件头必须有文件存储编码的信息，对于不规范的文件或被篡改过的就另当别论，呵呵。

2：更复杂的文件编码检测，可以使用一个开源项目cpdetector，它所在的网址是：http://cpdetector.sourceforge.net/。它的类库很小，只有500K左右，cpDetector是基于统计学原理的，不保证完全正确，利用该类库判定文本文件的代码如下：

读外部文件(先利用cpdetector检测文件的编码格式，然后用检测到的编码方式去读文件)

/**
  * 利用第三方开源包cpdetector获取文件编码格式
  *
  * @param path
  *            要判断文件编码格式的源文件的路径
  */
 public static String getFileEncode(String path) {
  /*
   * detector是探测器，它把探测任务交给具体的探测实现类的实例完成。
   * cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、
   * JChardetFacade、ASCIIDetector、UnicodeDetector。
   * detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的
   * 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar
   * cpDetector是基于统计学原理的，不保证完全正确。
   */
  CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();
  /*
   * ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于
   * 指示是否显示探测过程的详细信息，为false不显示。
   */
  detector.add(new ParsingDetector(false));
  /*
   * JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码
   * 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以
   * 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。
   */
  detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar
  // ASCIIDetector用于ASCII编码测定
  detector.add(ASCIIDetector.getInstance());
  // UnicodeDetector用于Unicode家族编码的测定
  detector.add(UnicodeDetector.getInstance());
  java.nio.charset.Charset charset = null;
  File f = new File(path);
  try {
   charset = detector.detectCodepage(f.toURI().toURL());
  } catch (Exception ex) {
   ex.printStackTrace();
  }
  if (charset != null)
   return charset.name();
  else
   return null;
 }
 String charsetName = getFileEncode(configFilePath);
 System.out.println(charsetName);
 inputStream = new FileInputStream(configFile);
 BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

读jar包内部资源文件(先利用cpdetector检测jar内部的资源文件的编码格式，然后以检测到的编码方式去读文件)：
/**
  * 利用第三方开源包cpdetector获取URL对应的文件编码
  *
  * @param path
  *            要判断文件编码格式的源文件的URL
  */
 public static String getFileEncode(URL url) {
  /*
   * detector是探测器，它把探测任务交给具体的探测实现类的实例完成。
   * cpDetector内置了一些常用的探测实现类，这些探测实现类的实例可以通过add方法 加进来，如ParsingDetector、
   * JChardetFacade、ASCIIDetector、UnicodeDetector。
   * detector按照“谁最先返回非空的探测结果，就以该结果为准”的原则返回探测到的
   * 字符集编码。使用需要用到三个第三方JAR包：antlr.jar、chardet.jar和cpdetector.jar
   * cpDetector是基于统计学原理的，不保证完全正确。
   */
  CodepageDetectorProxy detector = CodepageDetectorProxy.getInstance();
  /*
   * ParsingDetector可用于检查HTML、XML等文件或字符流的编码,构造方法中的参数用于
   * 指示是否显示探测过程的详细信息，为false不显示。
   */
  detector.add(new ParsingDetector(false));
  /*
   * JChardetFacade封装了由Mozilla组织提供的JChardet，它可以完成大多数文件的编码
   * 测定。所以，一般有了这个探测器就可满足大多数项目的要求，如果你还不放心，可以
   * 再多加几个探测器，比如下面的ASCIIDetector、UnicodeDetector等。
   */
  detector.add(JChardetFacade.getInstance());// 用到antlr.jar、chardet.jar
  // ASCIIDetector用于ASCII编码测定
  detector.add(ASCIIDetector.getInstance());
  // UnicodeDetector用于Unicode家族编码的测定
  detector.add(UnicodeDetector.getInstance());
  java.nio.charset.Charset charset = null;
  try {
   charset = detector.detectCodepage(url);
  } catch (Exception ex) {
   ex.printStackTrace();
  }
  if (charset != null)
   return charset.name();
  else
   return null;
 }
 URL url = CreateStationTreeModel.class.getResource("/resource/" + "配置文件");
 URLConnection urlConnection = url.openConnection();
 inputStream=urlConnection.getInputStream();
 String charsetName = getFileEncode(url);
 System.out.println(charsetName);
 BufferedReader in = new BufferedReader(new InputStreamReader(inputStream, charsetName));

3：探测任意输入的文本流的编码，方法是调用其重载形式：

charset=detector.detectCodepage(待测的文本输入流,测量该流所需的读入字节数);

上面的字节数由程序员指定，字节数越多，判定越准确，当然时间也花得越长。要注意，字节数的指定不能超过文本流的最大长度。

4：判定文件编码的具体应用举例：
    属性文件(.properties)是Java程序中的常用文本存储方式，象STRUTS框架就是利用属性文件存储程序中的字符串资源。它的内容如下所示：
    #注释语句
    属性名=属性值
    读入属性文件的一般方法是：
FileInputStream ios=new FileInputStream(“属性文件名”);
Properties prop=new Properties();
prop.load(ios);
String value=prop.getProperty(“属性名”);
ios.close();

    利用java.io.Properties的load方法读入属性文件虽然方便，但如果属性文件中有中文，在读入之后就会发现出现乱码现象。发生这个原因是load方法使用字节流读入文本，在读入后需要将字节流编码成为字符串，而它使用的编码是“iso-8859-1”,这个字符集是ASCII码字符集，不支持中文编码，
    方法一：使用显式的转码：
String value=prop.getProperty(“属性名”);
String encValue=new String(value.getBytes(“iso-8859-1″),”属性文件的实际编码”);

    方法二：象这种属性文件是项目内部的，我们可以控制属性文件的编码格式，比如约定采用Windows内定的GBK，就直接利用”gbk”来转码，     如果约定采用UTF-8，就使用”UTF-8″直接转码。
    方法三：如果想灵活一些，做到自动探测编码，就可利用上面介绍的方法测定属性文件的编码，从而方便开发人员的工作
    补充：可以用下面代码获得Java支持编码集合：
    Charset.availableCharsets().keySet();
    可以用下面的代码获得系统默认编码：
    Charset.defaultCharset();

Java 编码格式研究

 java中的String类是按照unicode进行编码的，当使用String(byte[] bytes, String encoding)构造字符串时，encoding所指的是bytes中的数据是按照那种方式编码的，而不是最后产生的String是什么编码方式，换句话说，是让系统把bytes中的数据由encoding编码方式转换成unicode编码。如果不指明，bytes的编码方式将由jdk根据操作系统决定。
        当我们从文件中读数据时，最好使用InputStream方式，然后采用String(byte[] bytes, String encoding)指明文件的编码方式。不要使用Reader方式，因为Reader方式会自动根据jdk指明的编码方式把文件内容转换成unicode编码。

        当我们从数据库中读文本数据时，采用ResultSet.getBytes()方法取得字节数组，同样采用带编码方式的字符串构造方法即可。

ResultSet rs;
bytep[] bytes = rs.getBytes();
String str = new String(bytes, "gb2312");

不要采取下面的步骤。

ResultSet rs;
String str = rs.getString();
str = new String(str.getBytes("iso8859-1"), "gb2312");

        这种编码转换方式效率底。之所以这么做的原因是，ResultSet在getString()方法执行时，默认数据库里的数据编码方式为iso8859-1。系统会把数据依照iso8859-1的编码方式转换成unicode。使用str.getBytes("iso8859-1")把数据还原，然后利用new String(bytes, "gb2312")把数据从gb2312转换成unicode，中间多了好多步骤。

        从HttpRequest中读参数时，利用reqeust.setCharacterEncoding()方法设置编码方式，读出的内容就是正确的了。

 几种编码方式：

2.1. iso8859-1

属于单字节编码，最多能表示的字符范围是0-255，应用于英文系列。比如，字母&apos;a&apos;的编码为0x61=97。

很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。而且在很多协议上，默认使用该编码。比如，虽然"中文"两个字不存在iso8859-1编码，以gb2312编码为例，应该是"d6d0 cec4"两个字符，使用iso8859-1编码的时候则将它拆开为4个字节来表示："d6 d0 ce c4"（事实上，在进行存储的时候，也是以字节为单位处理的）。而如果是UTF编码，则是6个字节"e4 b8 ad e6 96 87"。很明显，这种表示方法还需要以另一种编码为基础。

2.2. GB2312/GBK

这就是汉子的国标码，专门用来表示汉字，是双字节编码，而英文字母和iso8859-1一致（兼容iso8859-1编码）。其中gbk编码能够用来同时表示繁体字和简体字，而gb2312只能表示简体字，gbk是兼容gb2312编码的。

2.3. unicode (定长编码，Java里面都是unicode编码)

这是最统一的编码，可以用来表示所有语言的字符，而且是定长双字节（也有四字节的）编码，包括英文字母在内。所以可以说它是不兼容iso8859-1编码的，也不兼容任何编码。不过，相对于iso8859-1编码来说，uniocode编码只是在前面增加了一个0字节，比如字母&apos;a&apos;为"00 61"。

需要说明的是，定长编码便于计算机处理（注意GB2312/GBK不是定长编码），而unicode又可以用来表示所有字符，所以在很多软件内部是使用unicode编码来处理的，比如java。

2.4. UTF

考虑到unicode编码不兼容iso8859-1编码，而且容易占用更多的空间：因为对于英文字母，unicode也需要两个字节来表示。所以unicode不便于传输和存储。因此而产生了utf编码，utf编码兼容iso8859-1编码，同时也可以用来表示所有语言的字符，不过，utf编码是不定长编码，每一个字符的长度从1-6个字节不等。另外，utf编码自带简单的校验功能。一般来讲，英文字母都是用一个字节表示，而汉字使用三个字节。

注意，虽然说utf是为了使用更少的空间而使用的，但那只是相对于unicode编码来说，如果已经知道是汉字，则使用GB2312/GBK无疑是最节省的。不过另一方面，值得说明的是，虽然utf编码对汉字使用3个字节，但即使对于汉字网页，utf编码也会比unicode编码节省，因为网页中包含了很多的英文字符。

UTF: Unicode/UCS Transformation Format

UTF-8, 8bit编码, ASCII不作变换, 其他字符做变长编码, 每个字符1-3 byte. 通常作为外码. 有以下优点:
* 与CPU字节顺序无关, 可以在不同平台之间交流
* 容错能力高, 任何一个字节损坏后, 最多只会导致一个编码码位损失, 不会链锁错误(如GB码错一个字节就会整行乱码)

UTF-16, 16bit编码, 是变长码, 大致相当于20位编码, 值在0到0x10FFFF之间, 基本上就是unicode编码的实现. 它是变长码, 与CPU字序有关, 但因为最省空间, 常作为网络传输的外码.
UTF-16是unicode的preferred encoding.

UTF-32, 仅使用了unicode范围(0到0x10FFFF)的32位编码, 相当于UCS-4的子集.

UTF与unicode的关系:

Unicode是一个字符集, 可以看作为内码.
而UTF是一种编码方式, 它的出现是因为unicode不适宜在某些场合直接传输和处理. UTF-16直接就是unicode编码, 没有变换, 但它包含了0x00在编码内, 头256字节码的第一个byte都是0x00, 在操作系统(C语言)中有特殊意义, 会引起问题. 采用UTF-8编码对unicode的直接编码作些变换可以避免这问题, 并带来一些优点.

中国国标编码:

GB 13000: 完全等同于ISO 10646-1/Unicode 2.1, 今后也将随ISO 10646/Unicode的标准更改而同步更改.

GBK: 对GB2312的扩充, 以容纳GB2312字符集范围以外的Unicode 2.1的统一汉字部分, 并且增加了部分unicode中没有的字符.

GB 18030-2000: 基于GB 13000, 作为Unicode 3.0的GBK扩展版本, 覆盖了所有unicode编码, 地位等同于UTF-8, UTF-16, 是一种unicode编码形式. 变长编码, 用单字节/双字节/4字节对字符编码. GB18030向下兼容GB2312/GBK.
GB 18030是中国所有非手持/嵌入式计算机系统的强制实施标准.

java对字符的处理

在java应用软件中，会有多处涉及到字符集编码，有些地方需要进行正确的设置，有些地方需要进行一定程度的处理。

3.1. getBytes(charset)

这是java字符串处理的一个标准函数，其作用是将字符串所表示的字符按照charset编码，并以字节方式表示。注意字符串在java内存中总是按unicode编码存储的。比如"中文"，正常情况下（即没有错误的时候）存储为"4e2d 6587"，如果charset为"gbk"，则被编码为"d6d0 cec4"，然后返回字节"d6 d0 ce c4"。如果charset为"utf8"则最后是"e4 b8 ad e6 96 87"。如果是"iso8859-1"，则由于无法编码，最后返回 "3f 3f"（两个问号）。

3.2. new String(charset)

这是java字符串处理的另一个标准函数，和上一个函数的作用相反，将字节数组按照charset编码进行组合识别，最后转换为unicode存储。参考上述getBytes的例子，"gbk" 和"utf8"都可以得出正确的结果"4e2d 6587"，但iso8859-1最后变成了"003f 003f"（两个问号）。

因为utf8可以用来表示/编码所有字符，所以new String( str.getBytes( "utf8" ), "utf8" ) === str，即完全可逆。

3.3. setCharacterEncoding()

该函数用来设置http请求或者相应的编码。

对于request，是指提交内容的编码，指定后可以通过getParameter()则直接获得正确的字符串，如果不指定，则默认使用iso8859-1编码，需要进一步处理。参见下述"表单输入"。值得注意的是在执行setCharacterEncoding()之前，不能执行任何getParameter()。java doc上说明：This method must be called prior to reading request parameters or reading input using getReader()。而且，该指定只对POST方法有效，对GET方法无效。分析原因，应该是在执行第一个getParameter()的时候，java将会按照编码分析所有的提交内容，而后续的getParameter()不再进行分析，所以setCharacterEncoding()无效。而对于GET方法提交表单是，提交的内容在URL中，一开始就已经按照编码分析所有的提交内容，setCharacterEncoding()自然就无效。

对于response，则是指定输出内容的编码，同时，该设置会传递给浏览器，告诉浏览器输出内容所采用的编码。

3.4. 处理过程

下面分析两个有代表性的例子，说明java对编码有关问题的处理方法。

3.4.1. 表单输入

User input  *(gbk:d6d0 cec4)  browser  *(gbk:d6d0 cec4)  web server  iso8859-1(00d6 00d 000ce 00c4)  class，需要在class中进行处理：getbytes("iso8859-1")为d6 d0 ce c4，new String("gbk")为d6d0 cec4，内存中以unicode编码则为4e2d 6587。

l 用户输入的编码方式和页面指定的编码有关，也和用户的操作系统有关，所以是不确定的，上例以gbk为例。

l 从browser到web server，可以在表单中指定提交内容时使用的字符集，否则会使用页面指定的编码。而如果在url中直接用?的方式输入参数，则其编码往往是操作系统本身的编码，因为这时和页面无关。上述仍旧以gbk编码为例。

l Web server接收到的是字节流，默认时（getParameter）会以iso8859-1编码处理之，结果是不正确的，所以需要进行处理。但如果预先设置了编码（通过request. setCharacterEncoding ()），则能够直接获取到正确的结果。

l 在页面中指定编码是个好习惯，否则可能失去控制，无法指定正确的编码。

3.4.2. 文件编译

假设文件是gbk编码保存的，而编译有两种编码选择：gbk或者iso8859-1，前者是中文windows的默认编码，后者是linux的默认编码，当然也可以在编译时指定编码。

Jsp  *(gbk:d6d0 cec4)  java file  *(gbk:d6d0 cec4)  compiler read  uincode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4)  compiler write  utf(gbk: e4b8ad e69687; iso8859-1: *)  compiled file  unicode(gbk: 4e2d 6587; iso8859-1: 00d6 00d 000ce 00c4)  class。所以用gbk编码保存，而用iso8859-1编译的结果是不正确的。

class  unicode(4e2d 6587)  system.out / jsp.out  gbk(d6d0 cec4)  os console / browser。

l 文件可以以多种编码方式保存，中文windows下，默认为ansi/gbk。

l 编译器读取文件时，需要得到文件的编码，如果未指定，则使用系统默认编码。一般class文件，是以系统默认编码保存的，所以编译不会出问题，但对于jsp文件，如果在中文windows下编辑保存，而部署在英文linux下运行/编译，则会出现问题。所以需要在jsp文件中用pageEncoding指定编码。

l Java编译的时候会转换成统一的unicode编码处理，最后保存的时候再转换为utf编码。

l 当系统输出字符的时候，会按指定编码输出，对于中文windows下，System.out将使用gbk编码，而对于response（浏览器），则使用jsp文件头指定的contentType，或者可以直接为response指定编码。同时，会告诉browser网页的编码。如果未指定，则会使用iso8859-1编码。对于中文，应该为browser指定输出字符串的编码。

l browser显示网页的时候，首先使用response中指定的编码（jsp文件头指定的contentType最终也反映在response上），如果未指定，则会使用网页中meta项指定中的contentType。

3.5. 几处设置

对于web应用程序，和编码有关的设置或者函数如下。

3.5.1. jsp编译

指定文件的存储编码，很明显，该设置应该置于文件的开头。例如：<%@page pageEncoding="GBK"%>。另外，对于一般class文件，可以在编译的时候指定编码。

3.5.2. jsp输出

指定文件输出到browser是使用的编码，该设置也应该置于文件的开头。例如：<%@ page contentType="text/html; charset= GBK" %>。该设置和response.setCharacterEncoding("GBK")等效。

3.5.3. meta设置

指定网页使用的编码，该设置对静态网页尤其有作用。因为静态网页无法采用jsp的设置，而且也无法执行response.setCharacterEncoding()。例如：<META http-equiv="Content-Type" content="text/html; charset=GBK" />

如果同时采用了jsp输出和meta设置两种编码指定方式，则jsp指定的优先。因为jsp指定的直接体现在response中。

需要注意的是，apache有一个设置可以给无编码指定的网页指定编码，该指定等同于jsp的编码指定方式，所以会覆盖静态网页中的meta指定。所以有人建议关闭该设置。

3.5.4. form设置

当浏览器提交表单的时候，可以指定相应的编码。例如：<form accept-charset= "gb2312">。一般不必不使用该设置，浏览器会直接使用网页的编码。

4. 系统软件

下面讨论几个相关的系统软件。

4.1. mysql数据库

很明显，要支持多语言，应该将数据库的编码设置成utf或者unicode，而utf更适合与存储。但是，如果中文数据中包含的英文字母很少，其实unicode更为适合。

数据库的编码可以通过mysql的配置文件设置，例如default-character-set=utf8。还可以在数据库链接URL中设置，例如： useUnicode=true&characterEncoding=UTF-8。注意这两者应该保持一致，在新的sql版本里，在数据库链接URL里可以不进行设置，但也不能是错误的设置。

4.2. apache

appache和编码有关的配置在httpd.conf中，例如AddDefaultCharset UTF-8。如前所述，该功能会将所有静态页面的编码设置为UTF-8，最好关闭该功能。

另外，apache还有单独的模块来处理网页响应头，其中也可能对编码进行设置。

4.3. linux默认编码

这里所说的linux默认编码，是指运行时的环境变量。两个重要的环境变量是LC_ALL和LANG，默认编码会影响到java URLEncode的行为，下面有描述。

建议都设置为"zh_CN.UTF-8"。

4.4. 其它

为了支持中文文件名，linux在加载磁盘时应该指定字符集，例如：mount /dev/hda5 /mnt/hda5/ -t ntfs -o iocharset=gb2312。

另外，如前所述，使用GET方法提交的信息不支持request.setCharacterEncoding()，但可以通过tomcat的配置文件指定字符集，在tomcat的server.xml文件中，形如：<Connector ... URIEncoding="GBK"/>。这种方法将统一设置所有请求，而不能针对具体页面进行设置，也不一定和browser使用的编码相同，所以有时候并不是所期望的。

5. URL地址

URL地址中含有中文字符是很麻烦的，前面描述过使用GET方法提交表单的情况，使用GET方法时，参数就是包含在URL中。

5.1. URL编码

对于URL中的一些特殊字符，浏览器会自动进行编码。这些字符除了"/?&"等外，还包括unicode字符，比如汉子。这时的编码比较特殊。

IE有一个选项"总是使用UTF-8发送URL"，当该选项有效时，IE将会对特殊字符进行UTF-8编码，同时进行URL编码。如果改选项无效，则使用默认编码"GBK"，并且不进行URL编码。但是，对于URL后面的参数，则总是不进行编码，相当于UTF-8选项无效。比如"中文.html?a=中文"，当UTF-8选项有效时，将发送链接"%e4%b8%ad%e6%96%87.html?a=/x4e/x2d/x65/x87"；而UTF-8选项无效时，将发送链接"/x4e/x2d/x65/x87.html?a=/x4e/x2d/x65/x87"。注意后者前面的"中文"两个字只有4个字节，而前者却有18个字节，这主要时URL编码的原因。

当web server（tomcat）接收到该链接时，将会进行URL解码，即去掉"%"，同时按照ISO8859-1编码（上面已经描述，可以使用URLEncoding来设置成其它编码）识别。上述例子的结果分别是"/ue4/ub8/uad/ue6/u96/u87.html?a=/u4e/u2d/u65/u87"和"/u4e/u2d/u65/u87.html?a=/u4e/u2d/u65/u87"，注意前者前面的"中文"两个字恢复成了6个字符。这里用"/u"，表示是unicode。

所以，由于客户端设置的不同，相同的链接，在服务器上得到了不同结果。这个问题不少人都遇到，却没有很好的解决办法。所以有的网站会建议用户尝试关闭UTF-8选项。不过，下面会描述一个更好的处理办法。

5.2. rewrite

熟悉的人都知道，apache有一个功能强大的rewrite模块，这里不描述其功能。需要说明的是该模块会自动将URL解码（去除%），即完成上述web server（tomcat）的部分功能。有相关文档介绍说可以使用[NE]参数来关闭该功能，但我试验并未成功，可能是因为版本（我使用的是apache 2.0.54）问题。另外，当参数中含有"?& "等符号的时候，该功能将导致系统得不到正常结果。

rewrite本身似乎完全是采用字节处理的方式，而不考虑字符串的编码，所以不会带来编码问题。

5.3. URLEncode.encode()

这是Java本身提供对的URL编码函数，完成的工作和上述UTF-8选项有效时浏览器所做的工作相似。值得说明的是，java已经不赞成不指定编码来使用该方法（deprecated）。应该在使用的时候增加编码指定。

当不指定编码的时候，该方法使用系统默认编码，这会导致软件运行结果得不确定。比如对于"中文"，当系统默认编码为"gb2312"时，结果是"%4e%2d%65%87"，而默认编码为"UTF-8"，结果却是"%e4%b8%ad%e6%96%87"，后续程序将难以处理。另外，这儿说的系统默认编码是由运行tomcat时的环境变量LC_ALL和LANG等决定的，曾经出现过tomcat重启后就出现乱码的问题，最后才郁闷的发现是因为修改修改了这两个环境变量。

建议统一指定为"UTF-8"编码，可能需要修改相应的程序。

5.4. 一个解决方案

上面说起过，因为浏览器设置的不同，对于同一个链接，web server收到的是不同内容，而软件系统有无法知道这中间的区别，所以这一协议目前还存在缺陷。

针对具体问题，不应该侥幸认为所有客户的IE设置都是UTF-8有效的，也不应该粗暴的建议用户修改IE设置，要知道，用户不可能去记住每一个web server的设置。所以，接下来的解决办法就只能是让自己的程序多一点智能：根据内容来分析编码是否UTF-8。

比较幸运的是UTF-8编码相当有规律，所以可以通过分析传输过来的链接内容，来判断是否是正确的UTF-8字符，如果是，则以UTF-8处理之，如果不是，则使用客户默认编码（比如"GBK"），下面是一个判断是否UTF-8的例子，如果你了解相应规律，就容易理解。

public static boolean isValidUtf8(byte[] b,int aMaxCount){

       int lLen=b.length,lCharCount=0;

       for(int i=0;i<lLen && lCharCount<aMaxCount;++lCharCount){

              byte lByte=b[i++];//to fast operation, ++ now, ready for the following for(;;)

              if(lByte>=0) continue;//>=0 is normal ascii

              if(lByte<(byte)0xc0 || lByte>(byte)0xfd) return false;

              int lCount=lByte>(byte)0xfc?5:lByte>(byte)0xf8?4

                     :lByte>(byte)0xf0?3:lByte>(byte)0xe0?2:1;

              if(i+lCount>lLen) return false;

              for(int j=0;j<lCount;++j,++i) if(b[i]>=(byte)0xc0) return false;

       }

       return true;

}

相应地，一个使用上述方法的例子如下：

public static String getUrlParam(String aStr,String aDefaultCharset)

throws UnsupportedEncodingException{

       if(aStr==null) return null;

       byte[] lBytes=aStr.getBytes("ISO-8859-1");

       return new String(lBytes,StringUtil.isValidUtf8(lBytes)?"utf8":aDefaultCharset);

}

不过，该方法也存在缺陷，如下两方面：

l 没有包括对用户默认编码的识别，这可以根据请求信息的语言来判断，但不一定正确，因为我们有时候也会输入一些韩文，或者其他文字。

l 可能会错误判断UTF-8字符，一个例子是"学习"两个字，其GBK编码是" /xd1/xa7/xcf/xb0"，如果使用上述isValidUtf8方法判断，将返回true。可以考虑使用更严格的判断方法，不过估计效果不大。

有一个例子可以证明google也遇到了上述问题，而且也采用了和上述相似的处理方法，比如，如果在地址栏中输入"http://www.google.com/search?hl=zh-CN&newwindow=1&q=学习"，google将无法正确识别，而其他汉字一般能够正常识别。

最后，应该补充说明一下，如果不使用rewrite规则，或者通过表单提交数据，其实并不一定会遇到上述问题，因为这时可以在提交数据时指定希望的编码。另外，中文文件名确实会带来问题，应该谨慎使用。

6. 其它

下面描述一些和编码有关的其他问题。

6.1. SecureCRT

除了浏览器和控制台与编码有关外，一些客户端也很有关系。比如在使用SecureCRT连接linux时，应该让SecureCRT的显示编码（不同的session，可以有不同的编码设置）和linux的编码环境变量保持一致。否则看到的一些帮助信息，就可能是乱码。

另外，mysql有自己的编码设置，也应该保持和SecureCRT的显示编码一致。否则通过SecureCRT执行sql语句的时候，可能无法处理中文字符，查询结果也会出现乱码。

对于Utf-8文件，很多编辑器（比如记事本）会在文件开头增加三个不可见的标志字节，如果作为mysql的输入文件，则必须要去掉这三个字符。（用linux的vi保存可以去掉这三个字符）。一个有趣的现象是，在中文windows下，创建一个新txt文件，用记事本打开，输入"连通"两个字，保存，再打开，你会发现两个字没了，只留下一个小黑点。

6.2. 过滤器

如果需要统一设置编码，则通过filter进行设置是个不错的选择。在filter class中，可以统一为需要的请求或者回应设置编码。参加上述setCharacterEncoding()。这个类apache已经给出了可以直接使用的例子SetCharacterEncodingFilter。

6.3. POST和GET

很明显，以POST提交信息时，URL有更好的可读性，而且可以方便的使用setCharacterEncoding()来处理字符集问题。但GET方法形成的URL能够更容易表达网页的实际内容，也能够用于收藏。

从统一的角度考虑问题，建议采用GET方法，这要求在程序中获得参数是进行特殊处理，而无法使用setCharacterEncoding()的便利，如果不考虑rewrite，就不存在IE的UTF-8问题，可以考虑通过设置URIEncoding来方便获取URL中的参数。

6.4. 简繁体编码转换

GBK同时包含简体和繁体编码，也就是说同一个字，由于编码不同，在GBK编码下属于两个字。有时候，为了正确取得完整的结果，应该将繁体和简体进行统一。可以考虑将UTF、GBK中的所有繁体字，转换为相应的简体字，BIG5编码的数据，也应该转化成相应的简体字。当然，仍旧以UTF编码存储。

例如，对于"语言 ?言"，用UTF表示为"/xE8/xAF/xAD/xE8/xA8/x80 /xE8/xAA/x9E/xE8/xA8/x80"，进行简繁体编码转换后应该是两个相同的 "/xE8/xAF/xAD/xE8/xA8/x80>"。

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做正确编码转换。

 

 

GB2312，UTF-8,Unicode

===========================================================
作者: tbase(http://tbase.itpub.net)
发表于: 2005.09.28 15:55
分类: 基础和工具
出处: http://tbase.itpub.net/post/4931/42052
---------------------------------------------------------------

Unicode、Unicode-Bigendin 两个字节, 前面都有辨别码，分别是FF EF、EF FF，

UTF-8也使用了辨别码，但所有UTF-8字符都是3个字节的，辩证码是EF BB BF

而Ansi模式其实应该使用的是GB2312编码，没有辨别码，所以需要默认的编码，中文Windows就默认GB2312。编码每个中文用2个字节.

 

说研究就研究，尽量一丝不苟。
仔细研究了一下我们那个Properties的过程，发现原理是这个样子的。
首先对比了一下文件的Hex的编码情况：
使用记事本存储“我是人”三个字，发现如下：
首先可以发现Unicode、Unicode-Bigendin前面都有辨别码，分别是FF EF、EF FF，以此区别编码序列，也同时声明了这是一个Unicode的文件。每一个汉字使用两个字节。也就是说用的是UCS-4。
而UTF-8也使用了辨别码，但所有UTF-8字符都是3个字节的，辩证码是EF BB BF，和Unicode的辩证码其实是一个字符。每个汉字用3个字节表示。学习相关知识可知Unicode和UTF-8是可以直接映射的，两者影射其实是兼容的。
而Ansi模式其实应该使用的是GB2312编码，没有辨别码，所以需要默认的编码，中文Windows就默认GB2312。编码每个中文用2个字节，编码以后的内容和Unicode不同。
继续分析我们开发所用的环境的过程：
首先，分析Eclipse写出来的文件，此时我设置的工作空间编码为UTF-8，发现文件没有辨别码，也就是说这个文件被其他编辑器打开不可能知道这是什么编码。而文件里面其实根本就没有使用UTF-8编码，因为所有的中文都是2个字节的编码。我怀疑是UCS-4，所以分析一下，在刚才用记事本写的文件里面写入“美食同盟网”察看Hex状态的编码。
在Eclipse的文件里面“美”编码0xC3C0。Unicode里面是0x8E7F。Ansi里面是0xC3C0。Unicode-big里面肯定是0X7F8E，和Unicode那个反过来没的说。
所以，呵呵，我想一切旋疑都解开了。我们敬爱的Eclipse不管如何设置，其实他还是使用了你的操作系统的默认编码，而我们这里就是GB2312了，即使我们设置了UTF-8。其实问题是这样的，本来Eclipse默认latin-1编码，如果用那个方式，写了中文的双字节字符以后再打开就会造成乱码，而设置了UTF-8以后能解决以多字节（2个、3个）的方式打开文件的问题，不过其实还是用GB2312打开，这个可能是Eclipse对Properties文件未知格式的原因，因为用Eclipse打开存储UTF-8的XML文件是没有问题的，这个大家都有经验。由于Eclipse的多字节文件没有存储识别码，所以XML文件还有JSP文件的Charset一定要声明UTF-8，否则还是有可能出问题。
然后到这里已经真相大白了，这样再解释一下前几天出现的那些问题：
1、由于单字节多字节的问题和Eclipse不存储识别码的问题，我们最好把工作环境强行换到一个多字节环境，比如UTF-8。防止互相出现乱码，大家最好都用中文的Windows，否则估计还有可能出现问题。
2、解释上次native2ascii -encoding gb2312 ApplicationResources.properties ApplicationResources_zh.properties这个命令，网上那位老兄还说为什么Encoding改成UTF-8不行呢，因为你的Windows默认的就是gb2312，设UTF-8当然乱码。
3、解释native2ascii。其实这个过程和UTF-8没有任何关系，而且编码出来的文件的确是Unicode的转义字符。其实编出来的文件根本本就是最普通的单字节Ascii文件，只不过它把双字节的Hex方式直接用明文存储为单字节Ascii文件了，转换明文使用Big endian方式，也就是高位在后。为什么这样呢，因为Java多字节只支持Unicode，或者说是遗留，反正Java没有直接支持UTF-8，内部传输都使用Unicode。这不是问题，因为映射相同输出的时候Java很容易把Unicode转为UTF-8。而我们转那个文件只不过为了让Java可以轻松的把你的文件从转义字符转化为Unicode，过成就比如把“/uC3C0”这样的自符串转化为“美”的编码0xC3C0了。这么说有点乱，过程其实如下：
“美”在Eclipse存，然后在文件中如果用Hex察看是[C3 C0]。
然后用Native2ascii转，你看不到“美”只能看到u7f8e，而这时候如果用Hex察看是[5C 75 37 66 38 65]这么大一长串Ascii了。
这次明白了吧。
4、关于UTF-8和Unicode还有UCS的东西大家看看资料吧，一搜一大把。
UTF-8 and Unicode FAQ（中文，这个很官方，很有价值）
http://www.linuxfans.org/nuke/modules.php?name=News&file=article&op=view&sid=1749
谈谈Unicode编码 简要解释UCS/UTF/BMP/BOM（说的很通俗，而且涉及到的细节多，帮助大）
http://news.onlinedown.net/info/13164-1.htm