JSP中文乱码问题解决办法

当用request对象获取客户提交的汉字字符时，会出现乱码问题，所以对含有汉字字符的信息必须进行特殊处理。

常见的几种字符集编码：

? ASCII码：不支持中文

? ISO-8859-1：不支持中文

? GB2313、GBK：支持中文

? Unicode：支持中文

? UTF-8：支持中文

在解决JSP中文乱码问题前，弄清以下几点：

(1) windows平台采用的默认字符集编码是：GBK

(2) IE浏览器默认采用UTF-8字符集编码方式发送Http请求。

(3) Tomcat在处理Get请求时，永远采用ISO-8859-1编码；

Tomcat在处理Post请求时，默认采用ISO-8859-1编码；如果进行了如下设置request.setCharacterEncoding(“GBK”)，则采用GBK编码。

可以使用如下几种方式解决JSP中文乱码问题。

1、方法一：调用自定义的转换函数 <%@ page contentType="text/html;charset=GB2312" %>

<%!

public String getStr(String s) {

String str = s;

try {

byte[] b = str.getBytes("ISO-8859-1");

str = new String(b);

return str;

} } catch (Exception e) { return str; }

%>

使用内置对象request将获取的数据，使用ISO-8859-1进行重新编码，并保存到一个字节数组中，然后调用new String()方法，以GBK方式将这个字节数组构造出一个新的字符串，这个新的字符串就是我们想要的结果。

适用于以下三种情况：

(1) 以Get方式提交表单，提交的数据中包含汉字字符。

(2) 以Post方式提交表单，提交的数据中包含汉字字符。

(3) 在浏览器的地址栏中发出Http请求时，查询字符串中包含汉字字符。

2、方法二：调用request.setCharacterEncoding(“GBK”);

<%@ page contentType="text/html;Charset=GB2312" pageEncoding="GBK" %>

<% request.setCharacterEncoding("GB2312"); %>

由于Tomcat服务器处理Get请求或Post请求时，默认采用的编码方式是ISO-8859-1，通过内置对象request的getParameter()方法得到的字符串是以ISO-8859-1转换而来，这是导致乱码产生的原因之一。

为了避免Tomcat以ISO-8859-1的编码方式返回字符串，对于以Post方式提交的表单数据，可以在通过内置对象request获取数据之前，调用request.setCharacterEncoding(“GBK”)，明确指定对浏览器发送来的数据进行重新编码(或者称为解码)时，采用的GBK的编码方式。

适用于以下情况：

(1) 以Post方式提交表单，提交的数据中包含汉字字符。

计算机最初的操作系统支持的编码是单字节的字符编码，于是，在计算机中一切处理程序最初都是以单字节编码的英文为准进行处理。

随着计算机的发展，为了适应世界其它民族的语言（当然包括我们的汉字），人们提出了UNICODE编码，它采用双字节编码，兼容英文字符和其它民族的双字节字符编码，所以，目前，大多数国际性的软件内部均采用UNICODE编码，在软件运行时，它获得本地支持系统（多数时间是操作系统）默认支持的编码格式，然后再将软件内部的UNICODE转化为本地系统默认支持的格式显示出来。

Java的JDK和JVM即是如此，我这里说的JDK是指国际版的JDK，我们大多数程序员使用的是国际化的JDK版本，以下所有的JDK均指国际化的JDK版本。我们的汉字是双字节编码语言，为了能让计算机处理中文，我们自己制定的gb2312、GBK、GBK2K等标准以适应计算机处理的需求。

所以，大部分的操作系统为了适应我们处理中文的需求，均定制有中文操作系统，它们采用的是GBK,GB2312编码格式以正确显示我们的汉字。如：中文Windows默认采用的是GBK编码显示，在中文Windows20xx中保存文件时默认采用的保存文件的编码格式也是GBK的，即所有在中文Windows20xx中保存的文件它的内部编码默认均采用GBK编码，注意：GBK是在GB2312基础上扩充来的。

由于Java语言内部采用UNICODE编码，所以在Java程序运行时，就存在着一个从UNICODE编码和对应的操作系统及浏览器支持的编码格式转换输入、输出的问题，这个转换过程有着一系列的步骤，如果其中任何一步出错，则显示出来的汉字就会出是乱码，这就是我们常见的Java中文问题。

3、分析常见的Java中文问题几个必须清楚的原则

首先，经过上面的详细分析，我们可以清晰地看到，任何Java程序的生命期中，其编码转换的关键过程是在于：最初编译成class文件的转码和最终向用户输出的转码过程。

其次，我们必须了解Java在编译时支持的、常用的编码格式有以下几种：

*ISO-8859-1，8-bit, 同8859_1,ISO-8859-1,ISO_8859_1等编码

*Cp1252，美国英语编码，同ANSI标准编码

*UTF-8，同unicode编码

*GB2312，同gb2312-80,gb2312-1980等编码

*GBK，同MS936，它是gb2312的扩充及其它的编码，如韩文、日文、繁体中文等。同时，我们要注意这些编码间的兼容关体系如下：

unicode和UTF-8编码是一一对应的关系。GB2312可以认为是GBK的子集，即GBK编码是

在gb2312上扩展来的。同时，GBK编码包含了20902个汉字，编码范围为：0×8140-0xfefe，所有的字符可以一一对应到UNICODE2.0中来。

再次，对于放在操作系统中的.Java源程序文件，在编译时，我们可以指定它内容的编码格式，具体来说用-encoding来指定。注意：如果源程序中含有中文字符，而你用-encoding指定为其它的编码字符，显然是要出错的。

用-encoding指定源文件的编码方式为GBK或gb2312，无论我们在什么系统上编译含有中文字符的Java源程序都不会有问题，它都会正确地将中文转化为UNICODE存储在class文件中。

然后，我们必须清楚，几乎所有的WEB容器在其内部默认的字符编码格式都是以ISO-8859-1为默认值的，同时，几乎所有的浏览器在传递参数时都是默认以UTF-8的方式来传递参数的。

所以，虽然我们的Java源文件在出入口的地方指定了正确的编码方式，但其在容器内部运行时还是以ISO-8859-1来处理的。

网络上讨论的大多数是此类问题，多是因为JSP文件移植平台时不能正确显示的问题，对于这类问题，我们了解了Java中程序编码转换的原理，解决起来就容易多了。我们建议的解决办法如下：

1、我们要保证JSP向客户端输出时是采用中文编码方式输出的，即无论如何我们首先在我们的JSP源代编中加入以下一行：

<%@page contentType=”text/html; charset=gb2312″%>

2、为了让JSP能正确获得传入的参数，我们在JSP源文件头加入下面一句：

<%request.setCharacterEncoding(”GB2312″); %>

3、为了让JSP编译器能正确地解码我们的含有中文字符的JSP文件，我们需要在JSP源文件中指定我们的JSP源文件的编码格式，具体来说，我们在JSP源文件头上加入下面的一句即可：

<%@page pageEncoding=”GB2312″%>

或<%@page pageEncoding=”GBK”%>

这是JSP规范2.0新增加的指令。

在编译Servlet类的源程序时，用-encoding指定编码为GBK或GB2312，且在向用户输出时的编码部分用response对象的setContentType(”text/html;charset=GBK”);或gb2312来设置输出编码格式，同样在接收用户输入时，我们用request.setCharacterEncoding(”GB2312″)；这样无论我们的servlet类移植到什么操作系统中，只有客户端的浏览器支持中文显示，就可以正确显示。

 

第二篇：PHP中文乱码的常见解决方法总结

PHP中文乱码的常见解决方法总结

PHP中文乱码是PHP开发中的常见问题之一。PHP中文乱码有时发生在网页本身，有些产生在于MySQL交互的过程中，有时与操作系统有关。下面进行一番总结。

一.首先是PHP网页的编码

1. php文件本身的编码与网页的编码应匹配

a. 如果欲使用gb2312编码，那么php要输出头：header(“Content-Type: text/html; charset=gb2312")，静态页面添加，所有文件的编码格式为ANSI，可用记事本打开，另存为选择编码为ANSI，覆盖源文件。

b. 如果欲使用utf-8编码，那么php要输出头 ：header(“Content-Type: text/html; charset=utf-8")，静态页面添加，所有文件的编码格式为utf-8。保存为utf-8可能会有点麻烦，一般utf-8文件开头会有BOM，如果使用 session就会出问题，可用editplus来保存，在editplus中，工具->参数选择->文件->UTF-8签名，选择总是删除，再保存就可以去掉BOM信息了。

2. php本身不是Unicode的，所有substr之类的函数得改成mb_substr(需要装mbstring扩展);或者用iconv转码。

二.PHP与Mysql的数据交互

PHP与数据库的编码应一致

1. 修改mysql配置文件my.ini或my.cnf，mysql最好用utf8编码

[mysql]

default-character-set=utf8

[mysqld]

default-character-set=utf8

default-storage-engine=MyISAM

在[mysqld]下加入:

default-collation=utf8_bin

init_connect='SET NAMES utf8'

2. 在需要做数据库操作的php程序前加mysql_query("set names '编码'");，编码和php编码一致，如果php编码是gb2312那mysql编码就是gb2312，如果是utf-8那mysql编码就是 utf8，这样插入或检索数据时就不会出现乱码了

三.PHP与操作系统相关

Windows和Linux的编码是不一样的，在Windows环境下，调用PHP的函数时参数如果是utf-8编码会出现错误，比如 move_uploaded_file()、filesize()、readfile()等，这些函数在处理上传、下载时经常会用到，调用时可能会出现下面的错误:

Warning: move_uploaded_file()[function.move-uploaded-file]:failed to open stream: Invalid argument in ...

Warning: move_uploaded_file()[function.move-uploaded-file]:Unable to move '' to '' in ... Warning: filesize() [function.filesize]: stat failed for ... in ...

Warning: readfile() [function.readfile]: failed to open stream: Invalid argument in ..

在Linux环境下用gb2312编码虽然不会出现这些错误，但保存后的文件名出现乱码导致无法读取文件，这时可先将参数转换成操作系统识别的编码，编码转换可用mb_convert_encoding(字符串,新编码,原编码)或iconv(原编码,新编码,字符串)，这样处理后保存的文件名就不会出现乱码，也可以正常读取文件，实现中文名称文件的上传、下载。 其实还有更好的解决方法，彻底与系统脱离，也就不用考虑系统是何编码。可以生成一个只有字母和数字的序列作为文件名，而将原来带有中文的名字保存在数据库中，这样调用

move_uploaded_file()就不会出现问题，下载的时候只需将文件名改为原来带有中文的名字。实现下载的代码如下

header("Pragma: public");

header("Expires: 0");

header("Cache-Component: must-revalidate, post-check=0, pre-check=0");

header("Content-type: $file_type");

header("Content-Length: $file_size");

header("Content-Disposition: attachment; filename=\"$file_name\"");

header("Content-Transfer-Encoding: binary");

readfile($file_path);

$file_type是文件的类型，$file_name是原来的名字，$file_path是保存在服务上文件的地址。

四.再来总结一下为什么会乱码

一般来说，乱码的出现有2种原因，首先是由于编码(charset) 设置错误，导致浏览器以错误的编码来解析，从而出现了满屏乱七八糟的“天书”，其次是文件被以错误的编码打开，然后保存，比如一个文本文件原先是GB2312 编码的，却以UTF-8 编码打开再保存。要解决上述乱码问题，首先需要知道开发中哪些环节涉及到了编码：

1、文件编码：指的是页面文件(.html,.php等)本身是以何种编码来保存的。记事本和Dreamweaver 在打开页面时候会自动识别文件编码因而不太会出问题。而ZendStudio却不会自动识别编码，它只会根据首选项的配置固定以某种编码打开文件，如果工作时候一不注意，用错误编码打开文件，做了修改之后一保存，乱码就出现了(我深有体会)。

2、页面申明编码：在HTML代码HEAD里面，可以用 来告诉浏览器网页采用了什么编码，目前中文网站开发中XXX主要用的是GB2312和UTF-8 两种编码。

3、数据库连接编码：指的是进行数据库操作时候以哪种编码与数据库传输数据，这里需要注意的是不要与数据库本身的编码混淆，比如MySQL内部默认是latin1编码，也就是说Mysql是以latin1编码来存储数据，以其他编码传输给Mysql的数据会被转换成latin1编码。

知道了WEB开发中哪些地方涉及到了编码，也就知道了乱码产生的原因：上述3项编码设置不一致，由于各种编码绝大部分是兼容ASCII的，所以英文符号不会出现，中文就倒霉了。

五.决战一些常见的错误情况与解决：

1、数据库采用UTF8 编码，而页面申明编码是GB2312 ，这是最常见的产生乱码的原因。这时候在PHP脚本里面直接SELECT数据出来的就是乱码，需要在查询前先使用： mysql_query("SET NAMES GBK"); 来设定MYSQL连接编码，保证页面申明编码与这里设定的连接编码一致(GBK是GB2312的扩展 )。如果页面是UTF-8 编码的话，可以用： mysql_query("SET NAMES UTF8");

注意是UTF8而不是一般用的UTF-8。假如页面申明的编码与数据库内部编码一致可以不设定连接编码。

注：事实上MYSQL的数据输入输出比上面讲的更复杂一些，MYSQL配置文件my.ini中定义了2个默认编码，分别是[client]里的default -character-set和[mysqld] 里的default-character-set 来分别设定默认时候客户端连接和数据库内部所采用的编码。我们上面指定的编码其实是MYSQL客户端连接服务器时候的命令行参数character_set_client，来告诉MYSQL服务器接受到的客户端数据是什么编码的，而不是采用默认编码。

2、页面申明编码与文件本身编码不一致，这种情况很少发生，因为如果编码不一致美

工做页面时候在浏览器看到的就是乱码了。更多时候是发布以后修改一些小BUG，以错误编码打开页面然后保存导致的。或者是用某些FTP软件直接在线修改文件，比如CuteFTP，由于软件编码配置错误而导致转换错了编码。

3、一些租用虚拟主机的朋友，明明上述3项编码都设置正确了还是有乱码。比方说网页是GB2312 编码的，IE等浏览器打开却总是识别成UTF-8 ，网页HEAD里面已经申明是GB2312 了，手动修改浏览器编码为GB2312 后页面显示正常。产生原因是服务器Apache设定了服务器全局的默认编码，在httpd.conf里面加了AddDefaultCharset UTF-8 。这时候服务器会首先发送HTTP头给浏览器，其优先级比页面里申明编码高，自然浏览器就识别错了。解决办法有2个，请管理员在配置文件自己的虚机里加上一条AddDefaultCharset GB2312 来覆盖全局配置，或者在自己目录的.htaccess里配置。

总结:总之一句话,要解决PHP中文乱码最好最快的解决办法就是,页面申明的编码与数据库内部编码一致,如果页面申请的页码与数据库内部编码不一致时,就设定连接编码 ,mysql_query("SET NAMES XXX "); XXX为连接编码.一定可以解决乱码的问题.