首先,谢谢你回答我这个问题,请你说的时候说明白点,因为我是个新手,问题如下.
我在MySQL中 插入表的语句为 insert into news(id,title,content,ndatetime)values(2,"心系玉树","目前……","20010-01-20 17:00:05");
这样的话 查询表 没有一点问题可是我在myEclipse中 如果使用预编译的SQL语句插入数据的话,再查询数据库,所有值都插入到数据库了,可是除了日期以外,其他的都是乱码
以下是JAVA的文件
package newdao;
import comdb.ConnectionManager;
import java.sql.*;
import java.text.SimpleDateFormat;
import java.util.Date;
public class NewsFirsTitleDB2 { /**
 * @param args
 */
public static void main(String[] args) {
// TODO Auto-generated method stub
Connection con=null;
PreparedStatement stmt=null;
try
{
SimpleDateFormat hmfromat=new SimpleDateFormat("yyyy-MM-dd hh:mm:ss");
con=ConnectionManager.getConnection();
String sql="insert into news(title,content,newtime)VALUES(?,?,?);";
stmt=con.prepareStatement(sql);
stmt.setString(1, "玉树");
stmt.setString(2, "爱神的箭");
stmt.setString(3, hmfromat.format(new Date()));
stmt.executeUpdate();
}catch(SQLException sqle)
{
sqle.printStackTrace();
}finally
{
ConnectionManager.closeStatement(stmt);
ConnectionManager.closeConnection(con);
}
}}

解决方案 »

  1.   

    很有可能是mysql的编码没有配置好。
    去网上找一下有关mysql的编码配置的,一搜一大堆。
      

  2.   

    是要改一下字符集的,具体在哪改我忘了,好像是个*.ini的文件吧
      

  3.   


    乱码肯定是编码和解码方式不一致产生的!step_1: 在mysql 中输入 status 可看到db 编码是什么
            可选utf-8 or gbk  step_2:  连接时jdbc:mysql://server:port/dbName?characterEncoding=gbk"; 连接时写上字符编码
    这两步没有问题的话基本上就不会有问题!
      

  4.   

    为什么那么多人用GBK?
    utf-8支持多国语言的大字符集不用。浪费
    新MYSQL配置的时候选字符集的时候看到那个有日文的就是UTF-8的那个选项,默认latin1
    没法新装就找ini文件,查询里面的latin1来换成UTF-8
    还有如果没有查询工具,你直接用命令行来查询mysql中数据,就算是中文正确的,永远显示的是乱码,除非你mysql装的GBK,命令行提示符也设置编码为GBK,在CMD中文只支持GBK,不支持UTF-8。其他的还有个乱七八糟的根本不用。
    页面编码要和数据库统一
    其他的没什么问题,一般这种问题就是因为页面编码与数据库编码格式不统一,或者数据库安装的默认字符集不支持中文。
      

  5.   

    不对不对,只要我插入的字符不是汉字,都可以过,而且我试过,删和查询,都没有问题,就改的时候和插入值的时候只要是汉字,当查看MYSQL数据库的时候就是乱码,.*int文件改过了,还是没有用,到底哪里的问题啊。晕死了。
      

  6.   

    mysql 安装时候设置成UTF-8,在MyEclipse中设置编译的格式也必须是UTF-8才行不然就会产生乱码的!
      

  7.   

    con=ConnectionManager.getConnection();你获取连接时,连接串没有配置好
    里面有useUnicode=true;characeerencoding=GBK类似的配置
      

  8.   

    看一下你的MyEclipse的编码是什么,或者你的连接数据库的url中设置的编码是不是和数据库中一样,或者数据库中的表中的编码是不是和Myeclipse中的编码一样。
      

  9.   

    设置MYeclipse的编码 然后  查看并设置mysql的编码 
      

  10.   

    public class ConnectionManager {
    private static final String DRIVER_CLASS="com.mysql.jdbc.Driver";
    private static final String DATABASE_URL="jdbc:mysql://localhost:3306/newsdb";
    private static final String DATABASE_USER="root";
    private static final String DATABASE_PASSWORD="3022103";
    public static Connection getConnection()
    {
    Connection dbcon=null;
    try {
    Class.forName(DRIVER_CLASS);
    dbcon=DriverManager.getConnection(DATABASE_URL, DATABASE_USER, DATABASE_PASSWORD);
    } catch (Exception e) {
    e.printStackTrace();
    }
    return dbcon;
    }
      

  11.   

    这个是连接的url你们看吧,在my.in里面的default chaset两个全都改成gbk了。我用gnk的原因是因为myeclipse默认就是gbk所以不想换来换去了。
      

  12.   

    如同8楼所说,url加一些参数,比如:
    private static final String DATABASE_URL="jdbc:mysql://localhost:3306/newsdb?useUnicode=true&characterEncoding=utf8";
      

  13.   

    解决方案
    思路:让服务器端和客户端的字符集保持一致。
    服务器端的编码是由字符集(Character Set)和校对规则(Collation)决定的。
    (以下摘自 MySQL 5.1 手册。更多内容可参见:http://dev.mysql.com/doc/refman/5.1/zh/charset.html)
    字符集是一套符号和编码。校对规则是在字符集内用于比较字符的一套规则。让我们使用一个假想字符集的例子来区别清楚。
    假设我们有一个字母表使用了四个字母:‘A’、‘B’、‘a’、‘b’。我们为每个字母赋予一个数值:‘A’=0,‘B’= 1,‘a’= 2,‘b’= 3。字母‘A’是一个符号,数字0是‘A’的编码,这四个字母和它们的编码组合在一起是一个字符集。
    假设我们希望比较两个字符串的值(在if……else语句中我们经常做值的比较):‘A’和‘B’。比较的最简单的方法是查找编码:‘A’为0,‘B’为1。因为0 小于1,我们可以说‘A’小于‘B’。我们做的仅仅是在我们的字符集上应用了一个校对规则。校对规则是一套规则(在这种情况下仅仅是一套规则):“对编码进行比较。”我们称这种全部可能的规则中的最简单的校对规则为一个binary(二元)校对规则。
    但是,如果我们希望小写字母和大写字母是等价的,应该怎样?那么,我们将至少有两个规则:(1)把小写字母‘a’和‘b’视为与‘A’和‘B’等价;(2)然后比较编码。我们称这是一个大小写不敏感的校对规则。比二元校对规则复杂一些。
    在实际生活中,大多数字符集有许多字符:不仅仅是‘A’和‘B’,而是整个字母表,有时候有许多种字母表,或者一个东方的(比如中文、日文、韩文、藏文、泰文等等)使用上千个字符的书写系统,还有许多特殊符号和标点符号。并且在实际生活中,大多数校对规则有许多个规则:不仅仅是大小写不敏感,还包括重音符不敏感(“重音符” 是附属于一个字母的符号,象德语的‘Ö’符号)和多字节映射(例如,作为规则‘Ö’=‘OE’就是两个德语校对规则的一种)。
    (以上摘自MySQL 5.1 手册。更多内容可参见:http://dev.mysql.com/doc/refman/5.1/zh/charset.html)
    MySQL 4.1.x开始支持以下这些事情
    使用多种字符集(Character Set)来存储字符
    使用多种校对规则(Collation)来比较字符串
    在同一台服务器、同一个数据库或甚至在同一个表中使用不同字符集或校对规则来混合字符串
    允许定义任何级别的字符集和校对规则
    MySQL 4.1及以上版本的字符集支持(Character Set Support)有两个方面:字符集(Character Set)和校对规则(Collation)。 字符集和校对规则有4个级别的默认设置:服务器(server),数据库(database),数据表(table)和连接(connection)。
    MySQL 中是根据下面几个变量确定服务器端和客户端用的什么字符集:
    character_set_client    客户端字符集
    character_set_connection  客户端与服务器端连接采用的字符集
    character_set_results   SELECT查询返回数据的字符集
    character_set_database  数据库采用的字符集
    也就是说,只要保证这几个变量采用一致的字符集,就不会出现乱码问题了。
    查看系统的字符集用下面的命令:
    mysql> SHOW VARIABLES LIKE 'character_set_%';
    +--------------------------+-----------------------------------------+
    | Variable_name            | Value                                   |
    +--------------------------+-----------------------------------------+
    | character_set_client     | utf8                                    |
    | character_set_connection | utf8                                    |
    | character_set_database   | utf8                                    |
    | character_set_filesystem | binary                                  |
    | character_set_results    | utf8                                    |
    | character_set_server     | utf8                                    |
    | character_set_system     | utf8                                    |
    | character_sets_dir       | E:\usr\MySQL Server 5.0\share\charsets\ |
    +--------------------------+-----------------------------------------+
    8 rows in set (0.00 sec)
    可以看到,我的这几个变量都是一致的。但如果不一致呢?网上许多教程告诉你“你set names下就解决了”。
    那么set names是什么呢? set names实际上就是同时设置了character_set_client,character_set_connection,character_set_results这三个系统变量。
    例如在mysql命令行上输入 set names 'gbk' 命令等同于:
    SET character_set_client = gbk;
    SET character_set_connection = gbk;
    SET character_set_results = gbk;
    很多情况下,这样设置了之后就能把乱码问题解决了。但是还是不能完全避免出现乱码的可能,为什么呢?
    因为character_set_client,character_set_connection这两个变量仅用与保证与character_set_database编码的一致,而character_set_results则用与保证SELECT返回的结果与程序的编码一致。
    例如,你的数据库(character_set_database)用的是utf8的字符集,那么你就要保证character_set_client,character_set_connection也是utf8的字符集。
    而你的程序也许采用的并不是utf8,比如你的程序用的是gbk,那么你若把character_set_results也设置为utf8的话就会出现乱码问题。此时你应该把character_set_results设置为gbk。这样就能保证数据库返回的结果与你的程序的编码一致。
    到此应该就可以解决绝大多数我们遇到的乱码问题了,另外还必须强调的是,有时候乱码的出现有可能是以上几种原因混合造成的。
    总而言之,我们应当尽量的保证数据库中的数据是正确的,就是客户端到服务器端或者服务器端到客户端转换的过程中不要产生乱码,那么问题处理起来就相对简单了。
    为便于大家记忆,总结为以下四点:
    1、要保证数据库中存的数据与数据库编码一致,即数据编码与character_set_database一致。
    2、要保证通讯的字符集与数据库的字符集一致,即character_set_client,character_set_connection与character_set_database一致。
    3、要保证SELECT的返回与程序的编码一致,即character_set_results与程序编码一致。
    4、要保证程序编码与浏览器编码一致,即程序编码与<meta http-equiv="Content-Type" content="text/html; charset=?" />一致。
    附:
    1、MySQL服务器能够支持多种字符集。可以使用SHOW CHARACTER SET语句列出可用的字符集:
    mysql> show character set;
    +----------+-----------------------------+---------------------+--------+
    | Charset  | Description                 | Default collation   | Maxlen |
    +----------+-----------------------------+---------------------+--------+
    | big5     | Big5 Traditional Chinese    | big5_chinese_ci     |      2 |
    | dec8     | DEC West European           | dec8_swedish_ci     |      1 |
    | cp850    | DOS West European           | cp850_general_ci    |      1 |
    | hp8      | HP West European            | hp8_english_ci      |      1 |
    | koi8r    | KOI8-R Relcom Russian       | koi8r_general_ci    |      1 |
    | latin1   | cp1252 West European        | latin1_swedish_ci   |      1 |
    | latin2   | ISO 8859-2 Central European | latin2_general_ci   |      1 |
    | swe7     | 7bit Swedish                | swe7_swedish_ci     |      1 |
    | ascii    | US ASCII                    | ascii_general_ci    |      1 |
    | ujis     | EUC-JP Japanese             | ujis_japanese_ci    |      3 |
    | sjis     | Shift-JIS Japanese          | sjis_japanese_ci    |      2 |
    | hebrew   | ISO 8859-8 Hebrew           | hebrew_general_ci   |      1 |
    | tis620   | TIS620 Thai                 | tis620_thai_ci      |      1 |
    | euckr    | EUC-KR Korean               | euckr_korean_ci     |      2 |
    | koi8u    | KOI8-U Ukrainian            | koi8u_general_ci    |      1 |
    | gb2312   | GB2312 Simplified Chinese   | gb2312_chinese_ci   |      2 |
    | greek    | ISO 8859-7 Greek            | greek_general_ci    |      1 |
    | cp1250   | Windows Central European    | cp1250_general_ci   |      1 |
    | gbk      | GBK Simplified Chinese      | gbk_chinese_ci      |      2 |
    | latin5   | ISO 8859-9 Turkish          | latin5_turkish_ci   |      1 |
    | armscii8 | ARMSCII-8 Armenian          | armscii8_general_ci |      1 |
    | utf8     | UTF-8 Unicode               | utf8_general_ci     |      3 |
    | ucs2     | UCS-2 Unicode               | ucs2_general_ci     |      2 |
    | cp866    | DOS Russian                 | cp866_general_ci    |      1 |
    | keybcs2  | DOS Kamenicky Czech-Slovak  | keybcs2_general_ci  |      1 |
    | macce    | Mac Central European        | macce_general_ci    |      1 |
    | macroman | Mac West European           | macroman_general_ci |      1 |
    | cp852    | DOS Central European        | cp852_general_ci    |      1 |
    | latin7   | ISO 8859-13 Baltic          | latin7_general_ci   |      1 |
    | cp1251   | Windows Cyrillic            | cp1251_general_ci   |      1 |
    | cp1256   | Windows Arabic              | cp1256_general_ci   |      1 |
    | cp1257   | Windows Baltic              | cp1257_general_ci   |      1 |
    | binary   | Binary pseudo charset       | binary              |      1 |
    | geostd8  | GEOSTD8 Georgian            | geostd8_general_ci  |      1 |
    | cp932    | SJIS for Windows Japanese   | cp932_japanese_ci   |      2 |
    | eucjpms  | UJIS for Windows Japanese   | eucjpms_japanese_ci |      3 |
    +----------+-----------------------------+---------------------+--------+