Unicode、UTF-16、UTF-8
Java 内部处理字符使用的字序方式是 Unicode,这是一种通行全球的编码方式。Unicode 因为必须将中、韩、日、英、法、阿拉伯……等许多国家所使用的文字都纳入,目前已经包含了六万多个字符,所以 Unicode 使用了 16 个位来为字符编码。因为 Unicode 使用了 16 位编码,所以每个字符都用 16 位来储存或传输是很自然的事,这种储存或传输的格式称为 UTF-16(是不是很像战斗机的名字)。如果你使用到的字符都是西方字符,那么你一定不会想用 UTF-16 的格式,因为体积比 8 位的 Latin-1(一种扩充 ASCII 的编码)多了一倍。所以 Unicode 另有一种储存或传输的格式,叫做 UTF-8。UTF-8 的格式在编码英文时,只需要 8 位,但是中文则是 24 位,所以中文字出现比例高的地方还是使用 UTF-16 比较节省空间。Java 的 Class File(也就是 bytecode)中有一字段叫做常数区(Constant Pool),一律使用 UTF-8 为字符编码。
Unicode 与繁体中文编码的互转
虽然 Java 内部完整地使用 Unicode,但是你所使用的操作系统可不见得。以繁体中文版的 Windows 98 来说,预设的编码方式是 MS950,这是一种兼容于 Big 5的编码方式。字符串数据从 Windows 一送进 JRE,JRE 的转码系统马上先把字符串编码由 MS950 转成 Unicode,才能进行处理。字符串资料由 JRE 一送出给 Windows,JRE 的转码系统马上先将其由 Unicode 转成 MS950,操作系统才能处理。
想知道你的 JDK 或 JRE 会用什么样的编码方式来和操作系统沟通,请执行下面的 Java 程序:
public class ShowNativeEncoding {
public static void main(String[] args) {
String enc = System.getProperty("file.encoding");
System.out.println(enc);
}
}
· Unicode:有次序记号的 Unicode。次序记号占用两个 byte,如果其值是0xFEFF,表示使用 big-endian(由大到小)的次序为 Unicode 编码;如果其值是 0xFFFF,表示使用 little-endian(由小到大)的次序为 Unicode 编码。
编译时的注意事项
编译的时候,如果你不说明原始文件编码方式的话, javac 编译器在读进此原始程序文件,开始编译之前,会先去询问操作系统档案预设的编码方式为何。以繁体中文 Windows 98 来说,javac 会先询问 Windows 98,得知档案是用 MS950 的方式编码。然后就可以将档案由 MS950 转成 Unicode 编码方式,开始进行编译。
通常在编译阶段,会造成的错误有下列几种可能:
1. 如果操作系统的国籍资料设定错误,会造成 javac 编译器取得的编码信息是错的。
2. 较差劲的编译器可能没有主动询问操作系统的编码方式,而是采用编译器预设的编码方式。
3. 如果原始程序不是用编译当时操作系统预设的编码方式存盘的,也会造成错误。比方说,原始程序文件是台湾程序员写的,在繁体中文版的 Windows上以 MS950 编码存盘,再经由网络传送到泰国,在泰文版的 Windows 上编译(泰文版 Windows 预设的档案编码方式是 MS874)。
这种因为原始程序文件编码方式和编译器无法匹配所造成的问题,轻则编译成功但执行时文字出现乱码或出现 Error/Exception,重则无法成功编译。这时候,你需要主动透过「-encoding」选项来指定原始程序的编码方式,编译器会以你指定的编码为主,不会再去询问操作系统。下面的例子,我们告诉编译器「TaiwanClass.java」是以繁体中文版 Windows 的「MS950」编码的:
javac –encoding MS950 TaiwanClass.java
如果你手上只有某 class 文件,没有原始程序文件,而且你确定其 constant pool 的UTF-8 字段编码错误,你有两种方式可以用来修正编码:
1. 先反编译,取得原始程序,再修改,编译。
2. 或者直接利用 bytecode 编辑软件,直接修改 class 文件
I/O 转码
Java 现行的 IO 一律使用 Stream 的方式,相关的类别都放在 java.io 中。输出 binary 的资料使用 OutputStream 的子类别,输入 binary 的资料使用 InputStream 的子类别,输出文字的资料使用 Writer 的子类别,输入文字的资料使用 Reader 的子类别。
你可能会觉得很奇怪:「有必要用不同的方式来处理文字和 binary 吗?文字资料不也是 binary 的一种?」没错,其实他们非常类似,最大的差异在于,InputStream/OutputStream 会原封不动地传送资料,但是 Reader/Writer 会将资料当作文字对待,所以 Reader/Writer 在「必要时」会把(文字)资料转码。什么时候才是所谓的「必要时」呢?
Java 的 Stream(包括 Reader 和 Writer)是可以互相串接的。当 Reader 的资料来源是另一个 Reader 时,不转码,当 Reader 的资料来源是一个 InputStream 时,就会转码。当 Writer 的资料去处是另一个 Writer 时,不转码,当 Writer 的资料去处是一个 OutputStream 时,就会转码。
由什么码转成什么码?这是可以指定的。因为转码只发生在 Reader/InputStream 的交界处与 Writer/OutputStream 的交界处,所以正是由 InputStreamReader 和 OutputStreamWriter 此二类别负责,下面两个 constructor 的第二个参数,正是用来指定转码的方式。
public InputStreamReader(InputStream in, String enc)
throws UnsupportedEncodingException;
public OutputStreamWriter(OutputStream out, String enc)
throws UnsupportedEncodingException;
InputStreamReader 负责将 enc 的编码方式转成 Unicode(因为资料是从「外部」送过来给「内部」的),OutputStreamWriter 负责将 Unicode 的编码方式转成 enc(因为资料要从「内部」送给「外部」)。JRE 内部当然都一定是用 Unicode 编码,而外部的编码就不一定,要看当时的环境为何。你可以透过 getEncoding() 的 method,来得知 InputStreamReader 与 OutputStreamWriter 的编码方式。
请注意:即使你没用到 InputStreamReader 与 OutputStreamWriter,只有用到其它的 Reader 和 Writer,但是这些 Reader 和 Writer 内部也很有可能(但非绝对)是直接或间接通到 InputStreamReader 与 OutputStreamWriter。比方说:FileReader 内部其实是透过一个 InputStreamReader 的中介来将资料从 FileInputStream 取过来的,此时 InputStreamReader 的转码方式是采用 OS 的文字编码(以繁体中文的 Windows 为例,就是「MS950」)转成 Unicode。
如果你清楚地知道你要读写的档案(或资料来源 / 去处)是采用某种编码方式,你也可以主动指定编码方式。但是,请记得抓取可能导致的 UnsupportedEncodingException,并务必处理之,不可对此例外置之不理,因为该 JRE 有可能没有附上此种编码表(也有可能你的编码名称给错)。
档案 I/O 转码
如果你是在泰文版的 Windows 上,想读取用 MS950 编码的繁体中文文字文件,你就必须主动指定编码,不可以直接用 FileReader,否则无法成功读取。方法如下:
FileInputStream fis = new FileInputStream(fileName);
InputStreamReader reader = new InputStreamReader(fis, "MS950");
然后,透过 Reader 读出来的就会是正确的中文。