Web应用乱码问题.ppt

第九章 Web应用乱码问题 本章主要内容 9.1 简介 9.2 常见的中文编码问题及其解决方案 9.3 页面显示非英文乱码问题举例 9.4 页面间传递非英文参数乱码问题举例 9.5 数据库操作中非英文乱码问题举例 9.6 总结 9.7 练习 9.1 简介 每个国家（或区域）都规定了本国家（或地区）计算机信息交换用的字符编码集，如美国的扩展ASCII码, 中国的GB2312-80，日本的JIS 等，作为该国家/区域内信息处理的基础，有着统一编码的重要作用。字符编码集按长度分为SBCS（单字节字符集），DBCS（双字节字符集）两大类。早期的软件（尤其是操作系统），为了解决本地字符信息的计算机处理，出现了各种本地化版本（L10N），为了区分，引进了LANG, CodePage等概念。但是由于各个本地字符集代码范围重叠，相互间信息交换困难；软件各个本地化版本独立维护成本较高。因此有必要将本地化工作中的共性抽取出来，作一致处理，将特别的本地化处理内容降低到最少。这也就是所谓的国际化（I18N）。各种语言信息被进一步规范为Locale 信息。处理的底层字符集变成了几乎包含了所有字形的Unicode。 9.1 简介 现在大部分具有国际化特征的软件核心字符处理都是以Unicode 为基础的，在软件运行时根据当时的Locale/Lang/CodePage 设置确定相应的本地字符编码设置，并依此处理本地字符。在处理过程中需要实现Unicode 和本地字符集的相互转换，甚或以Unicode 为中间的两个不同本地字符集的相互转换。这种方式在网络环境下被进一步延伸，任何网络两端的字符信息也需要根据字符集的设置转换成可接受的内容。 Java语言内部是用Unicode表示字符的，遵守Unicode V2.0。Java程序无论是从/往文件系统以字符流读/写文件，还是往URL连接写HTML信息，或从URL连接读取参数值，都会有字符编码的转换。这样做虽然增加了编程的复杂度，容易引起混淆，但却是符合国际化的思想的。 9.1 简介 从理论上来说，这些根据字符集设置而进行的字符转换不应该产生太多问题。而事实是由于应用程序的实际运行环境不同，Unicode和各个本地字符集的补充、完善，以及系统或应用程序实现的不规范，转码时出现的问题时时困扰着程序员和用户。 9.2 常见的中文编码问题及其解决方案 网上常出现的JSP编码问题一般都表现在客户端，如：浏览器中看到的 JSP页面中的汉字怎么都成了“？”; JSP页面无法显示GBK汉字；JSP页面中内嵌在%...%、%=...%等标签包含的Java代码中的中文成了乱码，但页面的其它汉字是正常显示的；JSP不能接收表单提交的汉字等。隐藏在这些问题后面的是各种错误的字符转换和处理。解决类似的字符编码问题，需要了解JSP的运行过程，检查可能出现问题的各个点。 运行于Java应用服务器的JSP为浏览器提供HTML内容，其过程如图所示： 9.2 常见的中文编码问题及其解决方案 其中有字符编码转换的地方有：JSP编译。Java应用服务器将根据虚拟机的 “file.encoding”值读取JSP源文件，编译生成 Java源文件，再根据“file.encoding”的值写回文件系统。如果当前系统语言支持GBK，那么这时候不会出现编码问题。如果是英文的系统，如LANG是en_US的Linux、AIX或Solaris，则要将虚拟机的file.encoding 值置成GBK。系统语言如果是GB2312，则根据需要，确定要不要设置file.encoding，将 file.encoding设为GBK可以解决潜在的GBK字符乱码问题。 Java需要被编译为.class才能在虚拟机中执行，这个过程存在与上边一样的 file.encoding问题。从这里开始Servlet和JSP的运行就类似了，只不过Servlet的编译不是自动进行的。 9.2 常见的中文编码问题及其解决方案 Servlet需要将HTML页面内容转换为浏览器可接受的编码发送出去。依赖于各Java AP Server的实现方式，有的将查询浏览器的accept-charset和accept-language参数或以其它的方式确定编码，有的则不管。因此采用固定编码也许是最好的解决方法。对于中文网页，可在JSP中设置contentType=“text/html; charset=GB2312”；如果页面中有GBK字符，则设置为contentType=“text/html; charset=GBK”。我们推荐使用的编码是“UTF-8”。 9.3 页面显示非英文乱码