中文化和国际化问题权威解析之三:Java中文问题分析
来源:互联网 发布:自动加微信群软件 编辑:程序博客网 时间:2024/05/30 05:15
本章从实际的中文问题中,分析问题的根本原因,以及解决之道。
注意,本章虽然着重说明“中文问题”,但本章所推出的结论却是适合于世界所有语言文字的。
概述
我们在实际开发中碰到的中文问题,真是形形色色,无法一一列举。但是它们不是随机产生的,而是有规律可循,有办法解决的。
我们碰到最多的中文问题,都发生在使用Java Servlet写WEB应用时。其次,使用Java Mail API发送e-mail也会有类似的问题。从表象上区分,大致上有以下几种:
- 好端端的中文显示成了问号“?”,且一个中文变成2个问号。
- 好端端的中文显示成了问号“?”,且一个中文变成1个问号。
- 好端端的中文显示成了看不懂的符号,如“ÎÒ°®Alibaba”。
- WEB页面中部分中文显示正常,部分中文是乱码。
要分析这些问题的根本原因,首先要了解这些中文字符的输入源,其次是了解这些字符被输出到用户浏览器经过了哪些转换和输出环节。中文字符可以来源于:
- 程序内嵌的中文,我们在程序里直接书写中文字符串。
- 文本文件,利用FileInputStream读入文件内容并转换成字符。
- XML文件,利用XML解析器读入内存。
- 数据库,利用SQL查询,取得的结果。
- 模板文件,例如Velocity或WebMacro模板,我们使用模板生成WEB页面。
- JSP页面,在JSP生成的WEB页面。
- 用户通过浏览器提交的表单。
中文字符被装入内存以后,还要经过若干个转换和输出环节,最后才能到达用户的浏览器被用户看到。
- 文本通过response.getWriter()输出到浏览器端。
- 浏览器读取服务器的HTTP响应,并将响应中包含的HTML页面显示在浏览器上。
- 文本可能被写入XML文件、文本文件、数据库中。
以上列举的任何一个环节发生错误,都可能产生“乱码”现象。因此发生乱码现象时,不要慌,想想这个乱码的文本是从哪里来的,又是以什么方式输出的。
字符的输入、转换、输出环节
内嵌在程序代码中的中文
因为Java源代码(.java)本身是一个文本文件,所以和读普通文本文件一样,编译器(javac)必须以字节流的方式读入文件内容,并以适当的编码转换成Unicode字符而存储在Java字节码文件(.class)中。例如:Java源代码文件中包含GBK编码的中文字符,则使用下面的命令编译:
如果不指定
从文本文件中读入的字符
正如前面的 TestDecoding例子所示,在读入文本文件时,需要指定正确的编码。如果不指明编码,那么Java就会使用系统默认的编码来转换文件中的字节流。下列代码往往会产生问题:
XML标准极为严格地遵守Unicode标准。XML文件的字符编码是定义在XML文件中,而不是定义在XML解析器中的。如果不明确指定,任何标准的XML解析总是以UTF-8的方式解码XML文件。可以用下面的方式在XML文件中指定字符编码: 在解码过程中,如果 注意 注意,XML规范并没有定义GBK和GB18030编码,因此不能在XML文件使用这两种编码。目前可以使用的中文编码是GB2312和BIG5。相信这种情况以后会改变。如果确实想使用中文大字符集,请指定UTF-8作为XML文件的编码。 首先,数据库一般都可以设置以何种字符编码方式存储文本;其次,数据库的客户端 —— JDBC驱动 —— 必须设置成和数据库的内置字符编码一致;最后,尽可能使用UTF-8存取文本数据,因为这样可以在数据库中方便地存储所有国家的文字。 注意 我们Alibaba的Oracle数据库目前采用7位ASCII码存储文本(包括中文),这是一个极大的错误,已经导致了很多问题。我们后面会讲到。 Velocity和WebMacro是常用的Java模板系统。模板文件也是简单的文本文件。Velocity和WebMacro都可以在各自的配置文件定义读取模板所用的字符编码方式。例如Velocity可以这样设置: 如果是在 这样 JSP是一种特殊的WEB页面,在第一次使用时,被自动编译成一个普通的servlet。在JSP的开头指定JSP的字符编码: 上面这行告诉 2. 使用GBK编码输出JSP servlet中的所有字符,相当于: 3. 浏览器是根据页面的content type来决定以何种方式来编码用户输入的表单的。例如,一个页面的content type是text/html; charset=GBK,那么,当用户按下页面中的submit按钮时,浏览器自动将用户的输入用GBK方式编码并发送回服务器端。服务器接到用户的请求后,需要用正确的方式来解码,方法是: 然后再调用 注意 必须在第一次调用request.getParameter(parameterName)之前调用request.setCharacterEncoding(charset),因为解码是在第一次调用request.getParameter(parameterName)时发生的。 Servlet规范规定,如果没有设定request.setCharacterEncoding,则使用ISO-8859-1来解码用户输入的表单,而不是使用系统默认的编码。 对于multipart form(例如,上传图片的form表单),情况要复杂一些。因为servlet并没有直接支持multipart form。所以大多数应用程序使用了第三方的工具包来解析multipart form,例如:Oreilly COS工具包。然而,这些工具包大多使用系统默认的编码来解析用户表单,和servlet规范不一致。如果你的servlet代码没有特别指明编码方式,则两种form表单将有不同的表现,必有一种情况会出现乱码现象。 Servlet可以用两种方式向浏览器输出内容: 在此我们只讨论输出文本的情形:response.getWriter()。在调用response.getWriter()前,我们必须设置content type: response.getWriter() 在Turbine中,在配置文件中指定下面的内容,Turbine会为你自动设置content type: 浏览器收到从WEB服务器返回的页面时, 2. 如果HTTP响应中没有指定字符集,那么浏览器会检查HTML页面中是否包含: 如果找到,则使用这里指定的字符编码。 文本还可能被写入XML文件、文本文件、数据库中。类似的,输出文件时一般都要指定字符编码。如果不指定,通常Java会选择系统默认的编码。这为程序运行的结果产生了不确定因素。 明白了各输入、转换、输出环节是怎样工作的,我们的分析工作就有头绪了。在深入分析之前,有不少情况,观察乱码的表面现象就可以得到大概的结论。 这个现象通常表明字符在输入时出错,也就是解码错误。 虽然输出编码是对的,但在此之前,由于错误的输入编码,每个中文字变成了两个不相干的欧洲字符。而这些欧洲字符的编码和GBK编码是相冲突的(但也不一定完全冲突,例如上例中的第三个字节B0,被转换成GBK的E3A1)。因此大部分中文被输出成两个问号。 如果出现乱码的中文字是从Velocity模板读入的,说明Velocity配置文件中的input.encoding设置不正确;如果这个中文字是从数据库读入的,说明数据库的配置出错,也有可能文本在保存进数据库之前就已经错了;如果这个中文字是从用户表单输入的,很可能是你忘了调用request.setCharacterEncoding("GBK")。 这个现象通常表明字符在输出时出错,也就是编码错误。 这很可能是因为没有设置response.setContentType("text/html; charset=GBK")。 这个现象通常表明字符在输入输出时都出错了。 明眼人一看就发现,实际上在这种情况下,最后输出到浏览器上的字节流是正确的!只是因为content type被设成了错误的ISO-8859-1编码,所以才导致浏览器显示不正确的。事实上,用户可以手工改变浏览器的设置,使浏览器使用GBK对字节流重新解码。 看起来象是数学中的“负负得正”。为什么会这样呢?这是因为ISO-8859-1编码的特殊性导致的。ISO-8859-1字符集的编码范围是0000-00FF,正好和一个字节的编码范围相对应。这种特性保证了使用ISO-8859-1进行编码/解码可以保持编码数值“不变”。虽然中文字符在输入JVM时,被错误地“拆”成了两个欧洲字符,但由于输出时也是用ISO-8859-1,结果被“拆”开的中文字的两半又被神奇地合并在一起。 这种情形在英文版的Linux上最常发生,事实上我们公司的很多程序就是这样做的。英文版Linux的系统默认编码为ISO-8859-1。假设我们的servlet从模板中生成动态网页: 同样的代码,如果在中文Windows上运行,因为系统默认编码为GBK,因而会转变成“一个中文变成一个问号”的情形。 如果页面中有部分字符不是来源于模板,而是来源于XML文件或UTF-8编码的数据库,又会转变成“WEB页面中部分中文显示正常,部分中文是乱码”的情形。 此外,把一个中文字符转换成两个欧洲字符,不仅使字符串变长了一倍,影响效率,而且前面所说的和Unicode相关的功能一概失效:断句断词、排序、查看字符属性、格式化日期和数字。 可见,使用这种方法显示中文,引入了诸多不确定因素,实在不是一种可取的方法。但是很多程序员满足于“完成任务”,却不求甚解,不理解Unicode的精义。甚至网上很多的文章也主张这么做,真是可悲可叹。 很明显,这是由于同一页面中的字符是从不同的输入源取得的。假设有如下常见情形: 结果就是: Content Type 浏览器环境 服务器环境 从模板取得的中文字 从XML取得的中文字 从用户表单取得的中文字 text/html 中文Windows 中文Windows 一个中文变成1个问号 一个中文变成1个问号 碰巧正常 英文Linux 碰巧正常 一个中文变成1个问号 碰巧正常 英文Windows 中文Windows 一个中文变成1个问号 一个中文变成1个问号 中文变成欧洲字符 英文Linux 中文变成欧洲字符 一个中文变成1个问号 中文变成欧洲字符 text/html; charset=GBK 任意 中文Windows 正常 正常 一个中文变成2个问号 英文Linux 一个中文变成2个问号 正常 一个中文变成2个问号 注意 所谓“碰巧正常”是指虽然在服务器上,一个中文被当作两个欧洲字符处理,但是输出到浏览器以后,又被重新组合成了正确的字节序列,并且浏览器按默认的选项,会以中文GBK解码此序列。对于“中文变成欧洲字符”的情形,可以在浏览器上人工设置字符编码为GBK,或是在HTML中设置<meta http-equiv="Content-Type" content="text/html; charset=GBK">标记,来显示出中文。 以上只是分析了最常见的“乱码”现象。实际上,还可能会发生更复杂一点的情形。但是无论什么情形,都可以通过仔细分析中文字符经过的每一个输入、转换、输出环节,来了解它的原因。从XML文件中读入的字符
数据库
模板文件
JSP页面
Servlet输出
其它输出环节
“乱码”分析
一个中文变成了两个问号“?”
一个中文变成了一个问号“?”
中文显示成了看不懂的符号,如“ÎÒ°®Alibaba”
WEB页面中部分中文显示正常,部分中文是乱码
深入分析
- 中文化和国际化问题权威解析之三:Java中文问题分析
- 中文化和国际化问题权威解析之三:Java中文问题分析
- 中文化和国际化问题权威解析之三:Java中文问题分析
- 中文化和国际化问题权威解析之三:Java中文问题分析
- 中文化和国际化问题权威解析之四:Java中文化和国际化攻略
- 中文化和国际化问题权威解析之四:Java中文化和国际化攻略
- 中文化和国际化问题权威解析之四:Java中文化和国际化攻略
- 中文化和国际化问题权威解析之四:Java中文化和国际化攻略
- 中文化和国际化问题权威解析
- 中文化和国际化问题权威解析
- 中文化和国际化问题权威解析之二:Java国际化基础
- 中文化和国际化问题权威解析之二:Java国际化基础
- 中文化和国际化问题权威解析之二:Java国际化基础
- 中文化和国际化问题权威解析之二:Java国际化基础
- 中文化和国际化问题权威解析之五:URL编码/Misc
- 中文化和国际化问题权威解析之六:MIME编码/字符传输编码
- 中文化和国际化问题权威解析之七:JS中的escape、encodeURI、encodeURIComponent解惑
- 中文化和国际化问题权威解析之五:URL编码/Misc
- ansys使用小技巧
- 中文化和国际化问题权威解析之一:字符编码发展历程
- OPhone/OMS编程:OMS显示图片和拨打电话的例子
- Teradata使用SELECT查询创建表时需要注意的问题
- 中文化和国际化问题权威解析之二:Java国际化基础
- 中文化和国际化问题权威解析之三:Java中文问题分析
- 090811这几天的计划
- 编写线程函数时,链接时报错:undefined refrence to 'pthread_create '
- 中文化和国际化问题权威解析之四:Java中文化和国际化攻略
- 中文化和国际化问题权威解析之五:URL编码/Misc
- 【论程序设计方法~ 好文章呀!】
- 中文化和国际化问题权威解析之六:MIME编码/字符传输编码
- 中文化和国际化问题权威解析之七:JS中的escape、encodeURI、encodeURIComponent解惑
- Asp.net 中文件以Binary 形式数据库的保存和读取