深入剖析JSP和Servlet对中文的处理过程-2(转)

Class：输出字符串

 

上文说过，字符串在内存中表现为Unicode编码。至于这种Unicode编码表示了什么，那要看它是从哪种字符集映射过来的，也就是说要看它的祖先。这好比在托运行李时，外观都是纸箱子，里面装了什么就要看寄邮件的人实际邮了什么东西。

看看上面的例子，如果给一串Unicode编码“00D6 00D0 00CE 00C4”，如果不作转换，直接用Unicode码表来对照它时，是四个字符（而且是特殊字符）；假如把它与“ISO8859-1”进行映射，则直接去掉前面的“00”即可得到“D6 D0 CE C4”， 这是ASCII码表中的四个字符；而假如把它当作GB2312来进行映射，得到的结果很可能是一大堆乱码，因为在GB2312中有可能没有（也有可能有） 字符与00D6等字符对应（如果对应不上，将得到0x3f，也就是问号，如果对应上了，由于00D6等字符太靠前，估计也是一些特殊符号，真正的汉字在 Unicode中的编码从4E00开始）。

各位看到了，同样的Unicode字符，可以解释成不同的样子。当然，这其中有一种是我们期望的结果。以上例而论，“D6 D0 CE C4”应该是我们所想要的，当把“D6 D0 CE C4”输出到IE中时，用“简体中文00D6 00D0 00CE 00C4”本来就是由ISO8859-1转化过去的。”方式查看，就能看到清楚的“中文”两个字了。（当然了，如果你一定要用“西欧字符”来看，那也没办法，你将得不到任何有何时何地的东西）为什么呢？因为“

给出如下结论：

在Class输出字符串前，会将Unicode的字符串按照某一种内码重新生成字节流，然后把字节流输入，相当于进行了一步“String.getBytes(???)”操作。???代表某一种字符集。

如果是Servlet，那么，这种内码就是在HttpServletResponse.setContentType()方法中指定的内码，也就是上文定义的<Servlet-charset。>

如果是JSP，那么，这种内码就是在<%@ page contentType=""%>中指定的内码，也就是上文定义的<Jsp-charset。>

如果是Java程序，那么，这种内码就是file.encoding中指定的内码，默认为ISO8859-1。

当输出对象是浏览器时

以流行的浏览器IE为例。IE支持多种内码。假如IE接收到了一个字节流“D6 D0 CE C4”，你可以尝试用各种内码去查看。你会发现用“简体中文”时能得到正确的结果。因为“D6 D0 CE C4”本来就是简体中文中“中文”两个字的编码。

OK，完整地看一遍。

 

JSP：源文件为GB2312格式的文本文件，且JSP源文件中有“中文”这两个汉字

 

如果指定了<Jsp-charset为GB2312，转化过程如下表。>

表4　Jsp-charset = GB2312时的变化过程

序号	步骤说明	结果
1	编写JSP源文件，且存为GB2312格式	D6 D0 CE C4 （D6D0=中 CEC4=文）
2	jspc把JSP源文件转化为临时JAVA文件，并把字符串按照GB2312映射到Unicode，并用UTF格式写入JAVA文件中	E4 B8 AD E6 96 87
3	把临时JAVA文件编译成CLASS文件	E4 B8 AD E6 96 87
4	运行时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码	4E 2D 65 87（在Unicode中4E2D=中 6587=文）
5	根据Jsp-charset=GB2312把Unicode转化为字节流	D6 D0 CE C4
6	把字节流输出到IE中，并设置IE的编码为GB2312（作者按：这个信息隐藏在HTTP头中）	D6 D0 CE C4
7	IE用“简体中文”查看结果	“中文”（正确显示）

 

如果指定了<Jsp-charset为ISO8859-1，转化过程如下表。>

表5　Jsp-charset = ISO8859-1时的变化过程

序号	步骤说明	结果
1	编写JSP源文件，且存为GB2312格式	D6 D0 CE C4 （D6D0=中 CEC4=文）
2	jspc把JSP源文件转化为临时JAVA文件，并把字符串按照ISO8859-1映射到Unicode，并用UTF格式写入JAVA文件中	C3 96 C3 90 C3 8E C3 84
3	把临时JAVA文件编译成CLASS文件	C3 96 C3 90 C3 8E C3 84
4	运行时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码	00 D6 00 D0 00 CE 00 C4 （啥都不是！！！）
5	根据Jsp-charset=ISO8859-1把Unicode转化为字节流	D6 D0 CE C4
6	把字节流输出到IE中，并设置IE的编码为ISO8859-1（作者按：这个信息隐藏在HTTP头中）	D6 D0 CE C4
7	IE用“西欧字符”查看结果	乱码，其实是四个ASCII字符，但由于大于128，所以显示出来的怪模怪样
8	改变IE的页面编码为“简体中文”	“中文”（正确显示）

 

奇怪了！为什么把<Jsp-charset设成GB2312和ISO8859-1是一个样的，都能正确显示？因为表4表5中的第2步和第5步互逆，是相互“抵消”的。只不过当指定为ISO8859-1时，要增加第8步操作，殊为不便。>

再看看不指定<Jsp-charset> 时的情况。

表6　未指定Jsp-charset 时的变化过程

序号	步骤说明	结果
1	编写JSP源文件，且存为GB2312格式	D6 D0 CE C4 （D6D0=中 CEC4=文）
2	jspc把JSP源文件转化为临时JAVA文件，并把字符串按照ISO8859-1映射到Unicode，并用UTF格式写入JAVA文件中	C3 96 C3 90 C3 8E C3 84
3	把临时JAVA文件编译成CLASS文件	C3 96 C3 90 C3 8E C3 84
4	运行时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码	00 D6 00 D0 00 CE 00 C4 （啥都不是！！！）
5	根据Jsp-charset=ISO8859-1把Unicode转化为字节流	D6 D0 CE C4
6	把字节流输出到IE中	D6 D0 CE C4
7	IE用发出请求时的页面的编码查看结果	视情况而定。如果是简体中文，则能正确显示，否则，需执行表5中的第8步

 

Servlet：源文件为JAVA文件，格式是GB2312，源文件中含有“中文”这两个汉字

 

如果<Compile-charset>＝GB2312，<Servlet-charset>=GB2312

表7　Compile-charset=Servlet-charset=GB2312 时的变化过程

序号	步骤说明	结果
1	编写Servlet源文件，且存为GB2312格式	D6 D0 CE C4 （D6D0=中 CEC4=文）
2	用javac –encoding GB2312把JAVA源文件编译成CLASS文件	E4 B8 AD E6 96 87　（UTF）
3	运行时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码	4E 2D 65 87 (Unicode)
4	根据Servlet-charset=GB2312把Unicode转化为字节流	D6 D0 CE C4 (GB2312)
5	把字节流输出到IE中并设置IE的编码属性为Servlet-charset=GB2312	D6 D0 CE C4 (GB2312)
6	IE用“简体中文”查看结果	“中文”（正确显示）

 

如果<Compile-charset>＝ISO8859-1，<Servlet-charset>=ISO8859-1

表8　Compile-charset=Servlet-charset=ISO8859-1时的变化过程

序号	步骤说明	结果
1	编写Servlet源文件，且存为GB2312格式	D6 D0 CE C4 （D6D0=中 CEC4=文）
2	用javac –encoding ISO8859-1把JAVA源文件编译成CLASS文件	C3 96 C3 90 C3 8E C3 84　（UTF）
3	运行时，先从CLASS文件中用readUTF读出字符串，在内存中的是Unicode编码	00 D6 00 D0 00 CE 00 C4 (啥都不是!!!)
4	根据Servlet-charset=ISO8859-1把Unicode转化为字节流	D6 D0 CE C4
5	把字节流输出到IE中并设置IE的编码属性为Servlet-charset=ISO8859-1	D6 D0 CE C4 (GB2312)
6	IE用“西欧字符”查看结果	乱码（原因同表5）
7	改变IE的页面编码为“简体中文”	“中文”（正确显示）

 

如果不指定Compile-charset或Servlet-charset，其默认值均为ISO8859-1。

 

当Compile-charset=Servlet-charset时，第2步和第4步能互逆，“抵消”，显示结果均能正确。读者可试着写一下Compile-charset<>Servlet-charset时的情况，肯定是不正确的。