我的数据库全设成utf8 为什么用asp.net插入的汉子全成了？？ 为什么你的问题在后台查询前要执行 set names 'x'语句。x为你的数据库的字符集，gb2312或者gbk.
我试过了 SET NAMES 'GB2312' 不行的 没有任何变化
以下内容来自互联网： 首先实现了一个StringConvert bean（GBtoISO()和ISOtoGB()两个方法），解决了与MySQL数据库交互的时候的部分中文乱码问题：在JSP程序中读取MySQL的中文内容，用这两个方法可以解决乱码问题。 但是从JSP写入到MySQL的中文内容都成了乱码，并且再读出来的时候也显示为“？？”，在这里应该出现了编码转换过程中的字符信息丢失。郁闷的是，我在命令行窗口中登陆到MySQL后，执行如“INSERT INTO customer VALUES(''字符'',...)”这样的语句时，写入到数据表中的中文内容又是显示正常的！！！数据库使用的字符集是utf8。 碰壁多次，终于发现一条解决问题的路径：查看MySQL手册的时候，看到一条这样的语句：To allow multiple character sets to be sent from the client, the "UTF-8" encoding should be used, either by configuring "utf8" as the default server character set, or by configuring the JDBC driver to use "UTF-8" through the characterEncoding property. 此外，在查阅《MySQL权威指南》时，发现在查询语句中可以使用这样的语法将字符串转换到一个给定的字符集：_charset str。 其中charset必须是服务器支持的某个字符集。在本例中，shopdb数据库使用的默认字符集是utf8，于是开始测试： 先输入INSERT INTO publish Values(''8'',_gb2312 ''高等教育出版社'') 写入后中文变成“？？” 再试INSERT INTO publish Values(''8'',_gbk ''高等教育出版社'') 结果同上 INSERT INTO publish Values(''8'',_utf8 ''高等教育出版社'') 这下更干脆，什么都没有！！ 快疯了!!没办法，用show character set;命令查看MySQL支持的字符集，心想我都试一遍总有一个能成功吧。浏览了一下，发现没有几个熟悉的字符集，就只剩下一个latin1(ISO-8859-1)比较常见了，不会是它吧，一试之下果然便是。 INSERT INTO publish Values(''8'',_latin1 ''高等教育出版社'') 输入中文能够正确显示。 这下总算找到方法了，把Tomcat下配置的数据库连接池的url改为＂...characterEncoding=UTF-8＂，然后把写入数据库的中文内容用 String s2 = new String(s1.getBytes("gb2312"),"ISO-8859-1")进行转码，其中s1为中文字符串．然后再写入到数据库一切显示正常。 为解决这个问题查看了n多资料，现作一个总结：由于字符集和字符编码方式的不同，在OS以及程序之间传递数据（尤其是multiple character sets中的数据）时便会产生乱码以及字符信息的丢失．解决这个问题的关键便是了解数据输出端和接收端使用的字符集和字符编码方式，如果这两种编码方式不同，便需要在数据出口或入口处进行 转码。一般的说，在编写代码,编译，以及运行期间都会字符数据的传递，因此需要特别小心。 在编写代码的时候，你可能会使用某种开发工具，例如我正在使用的Eclipse．或许在写的时候一切正常，可是一旦保存后再次打开文档，所有的中文字符都变成了乱码。这是因为在编写的时候，这些字符数据都在内存的某个stream中，ok，这没问题，可是保存的时候这个stream中的数据会被写入到硬盘，使用的就是你的开发工具默认的编码方式，如果很不幸你的开发工具默认编码方式是ISO-8859-1，中文字符信息就不能正确地存储。Eclipse中可以这样查看并修改默认字符编码方式：Project->Properties->info，这里有＂default encoding for text file＂。如果设置为GBK，那么编写代码并保存这关就过了。 对于JSP程序而言，编写完代码后就交给Container，首先它们会被转成.java文件，然后编译成.class才能提交给服务器执行．这个过程也存在字符编码问题．java编译器(javac)使用操作系统的语言环境作为默认的字符编码方式，JRE(Java Runtime Environment)也是这样。只有当编译和运行环境的字符编码方式与存储源文件的编码方式相同时，中文字符才能正确地显示。否则就需要在运行时进行转码，使它们使用兼容的编码。这里的设置可以分为几个层次：操作系统层支持的语言，这是最重要的，因为它会影响ＪＶＭ的默认字符编码方式，同时对字符的显示，如字体等有直接影响；J2EE服务器层，大多数服务器都可以对字符编码进行自定义的配置，例如Tomcat就可以通过web.xml中设置javaEncoding参数设置字符编码，默认是UTF-8． IE也可以设置成总是使用UTF-8编码来发送请求．应用程序层，每个配置在服务器下的程序都可以设置自己的编码方式，这个我目前还没有用到，以后再学习。 运行时的转码，运行时期，应用程序很可能需要与外部系统进行交互，例如对数据库进行读写，对外部文件进行读写．在这些情况下，应用程序免不了要和外部系统进行数据交换。那么对于中文字符， 数据出入口的编码方式就显得特别重要了。一般外部系统都有自己的字符编码方式，我的例子中配置的MySQL就是使用的UTF-8编码。JSP页面通过设定＂charset=gb2312＂, 使用gb2312编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理中文字符。
为什么用asp.net插入的汉子全成了？？ 为什么你的问题在后台查询前要执行
set names 'x'语句。x为你的数据库的字符集，gb2312或者gbk.
首先实现了一个StringConvert bean（GBtoISO()和ISOtoGB()两个方法），解决了与MySQL数据库交互的时候的部分中文乱码问题：在JSP程序中读取MySQL的中文内容，用这两个方法可以解决乱码问题。 但是从JSP写入到MySQL的中文内容都成了乱码，并且再读出来的时候也显示为“？？”，在这里应该出现了编码转换过程中的字符信息丢失。郁闷的是，我在命令行窗口中登陆到MySQL后，执行如“INSERT INTO customer VALUES(''字符'',...)”这样的语句时，写入到数据表中的中文内容又是显示正常的！！！数据库使用的字符集是utf8。 碰壁多次，终于发现一条解决问题的路径：查看MySQL手册的时候，看到一条这样的语句：To allow multiple character sets to be sent from the client, the "UTF-8" encoding should be used, either by configuring "utf8" as the default server character set, or by configuring the JDBC driver to use "UTF-8" through the characterEncoding property. 此外，在查阅《MySQL权威指南》时，发现在查询语句中可以使用这样的语法将字符串转换到一个给定的字符集：_charset str。 其中charset必须是服务器支持的某个字符集。在本例中，shopdb数据库使用的默认字符集是utf8，于是开始测试： 先输入INSERT INTO publish Values(''8'',_gb2312 ''高等教育出版社'') 写入后中文变成“？？” 再试INSERT INTO publish Values(''8'',_gbk ''高等教育出版社'') 结果同上 INSERT INTO publish Values(''8'',_utf8 ''高等教育出版社'') 这下更干脆，什么都没有！！ 快疯了!!没办法，用show character set;命令查看MySQL支持的字符集，心想我都试一遍总有一个能成功吧。浏览了一下，发现没有几个熟悉的字符集，就只剩下一个latin1(ISO-8859-1)比较常见了，不会是它吧，一试之下果然便是。 INSERT INTO publish Values(''8'',_latin1 ''高等教育出版社'') 输入中文能够正确显示。 这下总算找到方法了，把Tomcat下配置的数据库连接池的url改为＂...characterEncoding=UTF-8＂，然后把写入数据库的中文内容用 String s2 = new String(s1.getBytes("gb2312"),"ISO-8859-1")进行转码，其中s1为中文字符串．然后再写入到数据库一切显示正常。 为解决这个问题查看了n多资料，现作一个总结：由于字符集和字符编码方式的不同，在OS以及程序之间传递数据（尤其是multiple character sets中的数据）时便会产生乱码以及字符信息的丢失．解决这个问题的关键便是了解数据输出端和接收端使用的字符集和字符编码方式，如果这两种编码方式不同，便需要在数据出口或入口处进行 转码。一般的说，在编写代码,编译，以及运行期间都会字符数据的传递，因此需要特别小心。 在编写代码的时候，你可能会使用某种开发工具，例如我正在使用的Eclipse．或许在写的时候一切正常，可是一旦保存后再次打开文档，所有的中文字符都变成了乱码。这是因为在编写的时候，这些字符数据都在内存的某个stream中，ok，这没问题，可是保存的时候这个stream中的数据会被写入到硬盘，使用的就是你的开发工具默认的编码方式，如果很不幸你的开发工具默认编码方式是ISO-8859-1，中文字符信息就不能正确地存储。Eclipse中可以这样查看并修改默认字符编码方式：Project->Properties->info，这里有＂default
encoding for text file＂。如果设置为GBK，那么编写代码并保存这关就过了。 对于JSP程序而言，编写完代码后就交给Container，首先它们会被转成.java文件，然后编译成.class才能提交给服务器执行．这个过程也存在字符编码问题．java编译器(javac)使用操作系统的语言环境作为默认的字符编码方式，JRE(Java Runtime Environment)也是这样。只有当编译和运行环境的字符编码方式与存储源文件的编码方式相同时，中文字符才能正确地显示。否则就需要在运行时进行转码，使它们使用兼容的编码。这里的设置可以分为几个层次：操作系统层支持的语言，这是最重要的，因为它会影响ＪＶＭ的默认字符编码方式，同时对字符的显示，如字体等有直接影响；J2EE服务器层，大多数服务器都可以对字符编码进行自定义的配置，例如Tomcat就可以通过web.xml中设置javaEncoding参数设置字符编码，默认是UTF-8． IE也可以设置成总是使用UTF-8编码来发送请求．应用程序层，每个配置在服务器下的程序都可以设置自己的编码方式，这个我目前还没有用到，以后再学习。 运行时的转码，运行时期，应用程序很可能需要与外部系统进行交互，例如对数据库进行读写，对外部文件进行读写．在这些情况下，应用程序免不了要和外部系统进行数据交换。那么对于中文字符， 数据出入口的编码方式就显得特别重要了。一般外部系统都有自己的字符编码方式，我的例子中配置的MySQL就是使用的UTF-8编码。JSP页面通过设定＂charset=gb2312＂, 使用gb2312编码，在它与数据库交互的时候就需要进行显式的转码才能正确处理中文字符。