字符集问题解决方法

‘壹’ Mysql字符集的问题,更改数据库的字符集问题

码一片，记得我以前也曾经有过一次切换出现乱码的经验，原因肯定是Mysql版本之间的差异问题。

只好查资料，发现了一个解决方法，就是在mysql_connect后面加一句SET NAMES UTF8，即可使得UTF8的数据库消除乱码，对于GBK的数据库则使用SET NAMES GBK，代码如下：

$mysql_mylink = mysql_connect($mysql_host, $mysql_user, $mysql_pass);
mysql_query("SET NAMES 'GBK'");

‘贰’ oracle字符集问题[复制粘贴勿扰]，如何解决

你的环境变量设置根本就是错的，所以无效！
尝试将NLS设置为set NLS_LANG=SIMPLIFIED CHINESE_CHINA.AL32UTF8，你确定你设置变量名是NLS_LANG？而正确的是LNS_LANG，所以你的系统环境根本就没改变。
把变量名改正确，然后重启试下就知道了。

‘叁’ 高分请教oracle字符集问题

基本上不可能正常使用，以下回答属于转载：

经常看到一些朋友问ORACLE字符集方面的问题，我想以迭代的方式来介绍一下。

第一次迭代：掌握字符集方面的基本概念。
有些朋友可能会认为这是多此一举，但实际上正是由于对相关基本概念把握不清，才导致了诸多问题和疑问。
首先是字符集的概念。
我们知道，电子计算机最初是用来进行科学计算的（所以叫做“计算机”），但随着技术的发展，还需要计算机进行其它方面的应用处理。这就要求计算机不仅能处理数值，还能处理诸如文字、特殊符号等其它信息，而计算机本身能直接处理的只有数值信息，所以就要求对这些文字、符号信息进行数值编码，最初的字符集是我们都非常熟悉的ASCII，它是用7个二进制位来表示128个字符，而后来随着不同国家、组织的需要，出现了许许多多的字符集，如表示西欧字符的ISO8859系列的字符集，表示汉字的GB2312-80、GBK等字符集。
字符集的实质就是对一组特定的符号，分别赋予不同的数值编码，以便于计算机的处理。
字符集之间的转换。字符集多了，就会带来一个问题，比如一个字符，在某一字符集中被编码为一个数值，而在另一个字符集中被编码为另一个数值，比如我来创造两个字符集demo_charset1与demo_charset2，在demo_charset1中，我规定了三个符号的编码为：A（0001），B（0010），？（1111）；而在demo_charset2中，我也规定了三个符号的编码为：A（1001），C（1011），？（1111），这时我接到一个任务，要编写一个程序，负责在demo_charset1与demo_charset2之间进行转换。由于知道两个字符集的编码规则，对于demo_charset1中的0001，在转换为demo_charset2时，要将其编码改为1001；对于demo_charset1中的1111，转换为demo_charset2时，其数值不变；而对于demo_charset1中的0010，其对应的字符为B，但在demo_charset2没有对应的字符，所以从理论上无法转换，对于所有这类无法转换的情况，我们可以将它们统一转换为目标字符集中的一个特殊字符（称为“替换字符”），比如在这里我们可以将？作为替换字符，所以B就转换为了？，出现了信息的丢失；同样道理，将demo_charset2的C字符转换到demo_charset1时，也会出现信息丢失。
所以说，在字符集转换过程中，如果源字符集中的某个字符在目标字符集中没有定义，将会出现信息丢失。
数据库字符集的选择。
我们在创建数据库时，需要考虑的一个问题就是选择什么字符集与国家字符集（通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）。考虑这个问题，我们必须要清楚数据库中都需要存储什么数据，如果只需要存储英文信息，那么选择US7ASCII作为字符集就可以；但是如果要存储中文，那么我们就需要选择能够支持中文的字符集（如ZHS16GBK）；如果需要存储多国语言文字，那就要选择UTF8了。
数据库字符集的确定，实际上说明这个数据库所能处理的字符的集合及其编码方式，由于字符集选定后再进行更改会有诸多的限制，所以在数据库创建时一定要考虑清楚后再选择。
而我们许多朋友在创建数据库时，不考虑清楚，往往选择一个默认的字符集，如WE8ISO8859P1或US7ASCII，而这两个字符集都没有汉字编码，所以用这种字符集存储汉字信息从原则上说就是错误的。虽然在有些时候选用这种字符集好象也能正常使用，但它会给数据库的使用与维护带来一系列的麻烦，在后面的迭代过程中我们将深入分析。
客户端的字符集。
有过一些Oracle使用经验的朋友，大多会知道通过NLS_LANG来设置客户端的情况，NLS_LANG由以下部分组成：NLS_LANG=<Language>_<Territory>.<Clients Characterset>，其中第三部分<Clients Characterset>的本意就是用来指明客户端操作系统缺省使用的字符集。所以按正规的用法，NLS_LANG应该按照客户端机器的实际情况进行配置，尤其对于字符集一项更是如此，这样Oracle就能够在最大程度上实现数据库字符集与客户端字符集的自动转换（当然是如果需要转换的话）。
总结一下第一次迭代的重点：
字符集：将特定的符号集编码为计算机能够处理的数值；
字符集间的转换：对于在源字符集与目标字符集都存在的符号，理论上转换将不会产生信息丢失；而对于在源字符集中存在而在目标字符集中不存在的符号，理论上转换将会产生信息丢失；
数据库字符集：选择能够包含所有将要存储的信息符号的字符集；
客户端字符集设置：指明客户端操作系统缺省使用的字符集。

第二次迭代：通过实例加深对基本概念的理解
下面我将引用网友tellin在ITPUB上发表的“CHARACTER SET研究及疑问”帖子，该朋友在帖子中列举了他做的相关实验，并对实验结果提出了一些疑问，我将对他的实验结果进行分析，并回答他的疑问。
实验结果分析一

quote:
--------------------------------------------------------------------------------
最初由 tellin 发布
设置客户端字符集为US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
查看服务器字符集为US7ASCII
SQL> SELECT * FROM NLS_DATABASE_PARAMETERS;
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET US7ASCII

建立测试表
SQL> CREATE TABLE TEST (R1 VARCHAR2(10));

Table created.

插入数据
SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
----------
东北

SQL> EXIT

--------------------------------------------------------------------------------

这一部分的实验数据的存取与显示都正确，好象没什么问题，但实际上却隐藏着很大的隐患。
首先，要将汉字存入数据库，而将数据库字符集设置为US7ASCII是不合适的。US7ASCII字符集只定义了128个符号，并不支持汉字。另外，由于在SQL*PLUS中能够输入中文，操作系统缺省应该是支持中文的，但在NLS_LANG中的字符集设置为US7ASCII，显然也是不正确的，它没有反映客户端的实际情况。
但实际显示却是正确的，这主要是因为Oracle检查数据库与客户端的字符集设置是同样的，那么数据在客户与数据库之间的存取过程中将不发生任何转换。具体地说，在客户端输入“东北”，“东”的汉字的编码为182（10110110）、171（10101011），“北”汉字的编码为177（10110001）、177（10110001），它们将不做任何变化的存入数据库中，但是这实际上导致了数据库标识的字符集与实际存入的内容是不相符的，从某种意义上讲，这也是一种不一致性，也是一种错误。而在SELECT的过程中，Oracle同样检查发现数据库与客户端的字符集设置是相同的，所以它也将存入的内容原封不动地传送到客户端，而客户端操作系统识别出这是汉字编码所以能够正确显示。
在这个例子中，数据库与客户端的设置都有问题，但却好象起到了“负负得正”的效果，从应用的角度看倒好象没问题。但这里面却存在着极大的隐患，比如在应用length或substr等字符串函数时，就可能得到意外的结果。另外，如果遇到导入/导出（import /export）将会遇到更大的麻烦。有些朋友在这方面做了大量的测试，如eygle研究了“源数据库字符集为US7ASCII，导出文件字符集为US7ASCII或ZHS16GBK，目标数据库字符集为ZHS16GBK”的情况，他得出的结论是 “如果的是在Oracle92中，我们发现对于这种情况，不论怎样处理，这个导出文件都无法正确导入到Oracle9i数据库中”、“对于这种情况，我们可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后修改第二、三字符，修改 0001 为0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中”。我想对于这些结论，这样理解可能更合适一些：由于ZHS16GBK字符集是US7ASCII的超级，所以如果按正常操作，这种转换应该没有问题；但出现问题的本质是我们让本应只存储英文字符的US7ASCII数据库，非常规地存储了中文信息，那么在转化过程中出现错误或麻烦就没什么奇怪的了，不出麻烦倒是有些奇怪了。
所以说要避免这种情况，就是要在建立数据库时选择合适的字符集，不让标签（数据库的字符集设置）与实际（数据库中实际存储的信息）不符的情况发生。

实验结果分析二

quote:
--------------------------------------------------------------------------------
[ 更改客户端字符集为ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

无法正常显示数据

SQL> SELECT * FROM TEST;

R1
--------------------
6+11

疑问1：ZHS16GBK为US7ASCII的超集，为什么在ZHS16GBK环境下无法正常显示

--------------------------------------------------------------------------------

这主要是因为Oracle检查发现数据库设置的字符集与客户端配置字符集不同，它将对数据进行字符集的转换。数据库中实际存放的数据为182（10110110）、171（10101011）、177（10110001）、177（10110001），由于数据库字符集设置为US7ASCII，它是一个7bit的字符集，存储在8bit的字节中，则Oracle忽略各字节的最高bit，则182（10110110）就变成了54（0110110），在ZHS16GBK中代表数字符号“6”（当然在其它字符集中也是“6”），同样过程也发生在其它3个字节，这样“东北”就变成了“6+11”。

实验结果分析三

quote:
--------------------------------------------------------------------------------
最初由 tellin 发布
用ZHS16GBK插入数据
SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
6+11
??

SQL> EXIT

--------------------------------------------------------------------------------

当客户端字符集设置为ZHS16GBK后向数据库插入“东北”，Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致，需要进行转换，但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符，所以Oracle用统一的“替换字符”插入数据库，在这里为“？”，编码为63（00111111），这时，输入的信息实际上已经丢失，不管字符集设置如何改变（如下面引用的实验结果），第二行SELECT出来的结果也都是两个“？”号（注意是2个，而不是4个）。

quote:
--------------------------------------------------------------------------------

更改客户端字符集为US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:\>SQLPLUS "/ AS SYSDBA"

无法显示用ZHS16GBK插入的字符集，但可以显示用US7ASCII插入的字符集
SQL> SELECT * FROM TEST;

R1
----------
东北
??

更改服务器字符集为ZHS16GBK
SQL> update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';

1 row updated.

SQL> COMMIT;

更改客户端字符集为ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

可以显示以前US7ASCII的字符集，但无法显示用ZHS16GBK插入的数据，说明用ZHS16GBK插入的数据为乱码。

SQL> SELECT * FROM TEST;

R1
--------------------
东北
??

--------------------------------------------------------------------------------

需要指出的是，通过“update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';”来修改数据库字符集是非常规作法，很可能引起问题，在这里只是原文引用网友的实验结果。

实验结果分析四

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> SELECT * FROM TEST;

R1
--------------------
东北
??
东北

SQL> EXIT

--------------------------------------------------------------------------------

由于此时数据库与客户端的字符集设置均为ZHS16GBK，所以不会发生字符集的转换，第一行与第三行数据显示正确，而第二行由于存储的数据就是63（00111111），所以显示的是“？”号。

quote:
--------------------------------------------------------------------------------

更改客户端字符集为US7ASCII

D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII

D:\>SQLPLUS "/ AS SYSDBA"

无法显示数据

SQL> SELECT * FROM TEST;

R1
----------
??
??
??

疑问2：第一行数据是用US7ASCII环境插入的，为何无法正常显示？

--------------------------------------------------------------------------------

将客户端字符集设置改为US7ASCII后进行SELECT，Oracle检查发现数据库设置的字符集为ZHS16GBK，数据需要进行字符集转换，而第一行与第三行的汉字“东”与“北”在客户端字符集US7ASCII中没有对应字符，所以转换为“替换字符”（“？”），而第二行数据在数据库中存的本来就是两个“？”号，所以虽然在客户端显示的三行都是两个“？”号，但在数据库中存储的内容却是不同的。

实验结果分析五

quote:
--------------------------------------------------------------------------------

SQL> INSERT INTO TEST VALUES('东北');

1 row created.

SQL> EXIT
更改客户端字符集为ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

D:\>SQLPLUS "/ AS SYSDBA"

无法显示用US7ASCII插入的字符集，但可以显示用ZHS16GBK插入的字符集
SQL> SELECT * FROM TEST;

R1
--------------------
东北
??
东北
6+11

SQL>
疑问3：US7ASCII为ZHS16GBK的子集，为何在US7ASCII环境下插入的数据无法显示？ [/B]
--------------------------------------------------------------------------------

在客户端字符集设置为US7ASCII时，向字符集为ZHS16GBK的数据库中插入“东北”，需要进行字符转换，“东北”的ZHS16GBK编码为182（10110110）、171（10101011）与177（10110001）、177（10110001），由于US7ASCII为7bit编码，Oracle将这两个汉字当作四个字符，并忽略各字节的最高位，从而存入数据库的编码就变成了54（00110110）、43（00101011）与49（00110001）、49（00110001），也就是“6+11”，原始信息被改变了。这时，将客户端字符集设置为ZHS16GBK再进行SELECT，数据库中的信息不需要改变传到客户端，第一、三行由于存入的信息没有改变能显示“东北”，而第二、四行由于插入数据时信息改变，所以不能显示原有信息了。

分析了这么多的内容，但实际上总结起来也很简单
分析了这么多的内容，但实际上总结起来也很简单，要想在字符集方面少些错误与麻烦，需要坚持两条基本原则：
在数据库端：选择需要的字符集（通过create database中的CHARACTER SET与NATIONAL CHARACTER SET子句指定）；
在客户端：设置操作系统实际使用的字符集（通过环境变量NLS_LANG设置）。

‘肆’ 请教mysql 字符集的问题。

跟mysql字符集有关的有：
1. 数据库的的字符集
2. 文本字段( varchar , text ,char ) 的字符集
你指的是哪个呢？
以下例子以utf8为字符集（注意是utf8 不是 utf-8 )
建库时指定字符集： create database XXXX charset utf8
一旦在建库时指定了字符集，在建表时就可以不用指定字符集了，它会默认继承数据库的字符集。
如果建表时还想指定字符集：create table XXXX ( xxxxxxx ) type=MyISAM default charset utf8
或
create table XXXX ( aa varchar(8) charset utf8, bb char(4) charset utf8) type=MyISAM default charset utf8;
一旦设置了utf8为字符集，在读取时，特别是用作网页作为输出 和 从网页接受数据时，要注意：
1. 请将网页的编码设置为 utf-8 (请注意是 utf-8 不是 utf8 )
2. 在进行 数据库操作 之前请先执行一下SQL： set names utf8 ， 然后再执行其它SQL语句

上面的思想是：请尽量保持所有的操作都用同一种编码。

‘伍’ mysql字符集问题 请教怎么解决

一、转码失败
在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。
针对这种情况，前几篇文章介绍过客户端发送请求到服务端。
其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。
比如下面简单一条语句：
set @a = "文本字符串";
insert into t1 values(@a);

• 变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。

2. 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。

3. 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。
那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。


二、客户端乱码
表数据正常，但是客户端展示后出现乱码。
这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。
那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。
这一类又分为以下三个不同的小类：

1)字段编码和表一致，客户端是不同的编码
比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。

2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形
比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。

3）每个字段的编码不一致，导致乱码和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。


三、LATIN1
还有一种情形就是以 LATIN1 的编码存储数据
估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。

‘陆’ 怎样修改mysql数据库字符集

首先，MySQL的字符集问题主要是两个概念，一个是Character Sets，一个是Collations，前者是字符内容
及编码，后者是对前者进行比较操作的一些规则。这两个参数集可以在数据库实例、单个数据库、表、列等四个级
别指定。
对于使用者来说，一般推荐使用utf8编码来存储数据。而要解决乱码问题，不单单是MySQL数据的存储问题，还
和用户的程序文件的编码方式、用户程序和MySQL数据库的连接方式都有关系。

首先，MySQL有默认的字符集，这个是安装的时候确定的，在编译MySQL的时候可以通过DEFAULT_CHARSET=
utf8和DEFAULT_COLLATION=utf8_general_ci这两个参数（MySQL5.5版本，5.1版本用--with-charset=
utf8 --with-collation=utf8_general_ci）来指定默认的字符集为utf8，这也是最一劳永逸的办法，这样指定后，
客户端连接到数据库的编码方式也默认是utf8了，应用程序不需要任何处理。

但是遗憾的是，很多人编译安装MySQL的时候没有指定这两个参数，大多数人更是通过二进制程序的方式安装，那
么这时候MySQL的默认字符集是latin1。而这时候我们仍然可以指定MySQL的默认字符集，通过my.cnf文件增加
两个参数：
1.在[mysqld]下添加
default-character-set=utf8（mysql 5.5 版本添加character-set-server=utf8）
2.在[client]下添加
default-character-set=utf8
这样我们建数据库建表的时候就不用特别指定utf8的字符集了。配置文件里的这种写法解决了数据存储和比较的问题
，但是对客户端的连接是没有作用的，客户端这时候一般需要指定utf8方式连接才能避免乱码。也就是传说总的set
names命令。事实上，set names utf8命令对应的是服务器端以下几个命令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = xutf8;
但这三个参数是不能写在配置文件my.cnf里的。只能通过set命令来动态修改。我们需要的是在配置文件里写好一劳
永逸的办法。那么这时候，是否有在服务端解决问题的办法呢，可行的思路是在init_connect里设置。这个命令在每
个普通用户连接上来的时候都会触发执行，可以在[mysqld]部分增加以下一行设置连接字符集：
在[mysqld]下添加：
init_connect = 'SET NAMES utf8'
总结：
1、首选在编译安装MySQL的时候指定两个参数使用utf8编码。
2、次选在配置文件my.cnf或my.ini设定两个参数，同时设置init_connect参数。
3、第三在配置文件my.cnf或my.ini设定两个参数，同时客户端的连接指定set names命令。
4、在配置文件my.cnf里的client和server处加入default-character-set参数方便管理。

‘柒’ 用VS2008输出一个变量的值时如何解决字符集的问题

看你传递的字符串是WCHAR*、char* 还是string 了针对这些都有不同的字符串转换，string的 可以用strTemp.c_str(); WCHAR* 直接CString（strTemp）就行，如果是char* 就比较麻烦了，需要使用函数WideCharToMultiByte() 进行转化，具体转化方法你查查这个函数的用法吧。你这些问题是字符串转换的问题，在C++中使用Unicode的程序中很常见。

‘捌’ oracle 11g字符集问题，回显都是问号怎么解决。

你是在服务器端插入数据的吧，尝试在XP的客户端输入数据试试。
这是因为字符集的问题造成的
你系统字符集是zh_CN.gb2312
环境变量字符集是ZHS16GBK
服务器数据库字符集是 ZHS16GBK
由于你环境变量字符集和你的服务器数据库一样，所以欺骗了数据库，你输入中文没有进行转码，所以数据库保存的字符代码是zh_CN.gb2312的代码，而该代码在ZHS16GBK里找不到对应的字符，它就会用？符号表示。
解决方法把你的环境变量字符集修改得和你操作系统字符集合一样或者是超集就可以了
export NLS_LANG=American_America.ZHS16CGB231280

‘玖’ win7系统下oracle客户端字符集设置问题

win7的字符集我没弄过，我弄过win8的，你可以尝试一下，就是去环境变量里面新增一个字符集。截图给你看一下：

你先去尝试一下，我的就是这样解决的，如果不行再想其他的办法。希望能够帮到你

‘拾’ MYsql 字符集乱码的问题，困扰了好久，帮我解决了再加100分

1、MySQL库、表存储设置UTF-8

2、驱动连接字符串String url=

”jdbc:mysql://127.0.0.1:3306/dbname?useUnicode=true&characterEncoding=UTF-8“

3、JSP页面中<%@ page contentType="text/html; charset=utf-8"%>

这样应该就可以传递正确编码了、不过你的输入输出环节的转换代码具体是什么样的？

此前如果有遗漏可能还要检查：

4、设置Tomcat6的server.xml中<Connector>标签：<Connector port="8080"protocol="HTTP/1.1" connectionTimeout="20000"
URIEncoding="utf-8" useBodyEncodingForURI="true" redirectPort="8443" />

5、JSP页面读取后台中文变量<%=newstring(aStrVal.getstring(2).getbytes("iso8859-1"),"utf-8")%>

控制装饰层从前端接收中文变量String aStrVal =new String(req.getParameter("strPara").getBytes("ISO8859_1"));

6、如果第4个措施因特殊情况不能修改，则可以自己写过滤器：

packagefilters;

importjava.io.IOException;
importjavax.servlet.Filter;
importjavax.servlet.FilterChain;
importjavax.servlet.FilterConfig;
importjavax.servlet.ServletException;
importjavax.servlet.ServletRequest;
importjavax.servlet.ServletResponse;
importjavax.servlet.UnavailableException;

{
/**
*
*thisfilter.
*/
protectedStringencoding="UTF-8";

/**
*.Ifthisvalue
*isnull,.
*/
=null;
/**
*?
*/
protectedbooleanignore=true;

publicvoiddestroy(){
this.encoding=null;
this.filterConfig=null;
}

publicvoiddoFilter(ServletRequestrequest,ServletResponseresponse,
FilterChainchain)throwsIOException,ServletException{

//
if(ignore||(request.getCharacterEncoding()==null)){
Stringencoding=selectEncoding(request);
if(encoding!=null)
request.setCharacterEncoding(encoding);
}
chain.doFilter(request,response);
}

/**
*Placethisfilterintoservice.
*@
*/
publicvoidinit(FilterConfigfilterConfig)throwsServletException{

this.filterConfig=filterConfig;
this.encoding=filterConfig.getInitParameter("encoding");
Stringvalue=filterConfig.getInitParameter("ignore");
if(value==null)
this.ignore=true;
elseif(value.equalsIgnoreCase("true"))
this.ignore=true;
elseif(value.equalsIgnoreCase("yes"))
this.ignore=true;
else
this.ignore=false;
}

protectedStringselectEncoding(ServletRequestrequest){
return(this.encoding);
}
}

<filter>
<filter-name>encodingFilter</filter-name>
<filter-class>filters.SetCharacterEncodingFilter</filter-class>
<init-param>
<param-name>encoding</param-name>
<param-value>GBK</param-value>
</init-param>
<init-param>
<param-name>ignore</param-name>
<param-value>false</param-value>
</init-param>
</filter>

<filter-mapping>
<filter-name>encodingFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

另外请确认如下都已经设置好：

MySQL 5.1在在my.ini内的 [mysql] 和[mysqld]两处 default-character-set=utf8

MySQL 5.5在在my.ini内的 [mysql]default-character-set=utf8；[mysqld]character-set-server=utf8

Myeclipse偏好首选设置里：

General->Workspace Text file encoding；

General->Content Types，右侧Content Types树，点开Text，确认Java Source File下面的Default encoding框中是UTF-8，用到jsp、js、css同上；

--看你的截图只是数据前后交换的问题，项目工作空间的都没问题了。