本篇内容主要讲解“MYSQL数据迁移到ORACLE中碰到的乱码问题的解决方法”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“MYSQL数据迁移到ORACLE中碰到的乱码问题的解决方法”吧!
首先来我们来看一下,转储数据有多种方法:
1。设置名字gbk;选择……到输出文件& # 39;/tmp/a1.txt& # 39;从test.t1;
2。mysql -uroot -h227.0.0.1——default-character-set=gbk - e“;选择……从test.t1"在在/tmp/a1.txt
3。,mysqldump -uroot -h227.0.0.1——选项卡“/tmp"——fields-terminated-by=& # 39;,,, & # 39;——lines-terminated-by=& # 39; $ $ $ $ $ & # 39;——default-character-set=utf8测试t1
创建测试表:
设置名称gbk;
CREATE TABLE t1的(col0 varchar (100),“col1”varchar (100))=MyISAM引擎默认字符集=use utf8;
插入t1值(& # 39;中国& # 39;,& # 39;1 aaaaaa& # 39;);
select * from t1;
下面我们分别来看一下,上面说的三种方法能不能正确转储中文到文本文件
1。设置名字gbk;select *到输出文件& # 39;/tmp/a1.txt& # 39;从test.t1;
========================================================================
root@127.0.0.1: 15:35:26>(没有);使用测试;
数据库改变
root@127.0.0.1:测试15:35:27>设置名字gbk;
查询好,0行影响(0.00秒)
root@127.0.0.1:测试15:35:30>select * from t1;
+ - - - - - - - - - - - - - - - - - - +
| col0 | col1,,|
+ - - - - - - - - - - - - - - - - - - +
|中国aaaaaa | 1 |
+ - - - - - - - - - - - - - - - - - - +
1行组(0.00秒)
root@127.0.0.1:测试15:35:33>select *到输出文件& # 39;/tmp/a1.txt& # 39;从test.t1;
查询好了,1行受影响(0.00秒)
root@127.0.0.1:测试15:35:53>系统的猫/tmp/a1.txt
涓?浗,1 aaaaaa
root@127.0.0.1:测试15:35:59>系统hexdump/tmp/a1。txt
0000000 b8e4 e5ad bd9b 3109 6161 6161 6161 000
000000 f
========================================================================
注解:用MYSQL客户端GBK看能正常显示中文,但输出文件里存的却是UTF8的编码数据。
,,在这里猜测是:
,,,当数据返回给MYSQL客户端的时候,数据经过character_set_results=gbk的转换。
,,,当数据返回给输出文件的时候,是直接转储数据。(经过测试,character_set_results不管设成什么,都不影响输出文件生成的结果)
2。mysql, - e“选择。“在比;/tmp/a2。txt
========================================================================
(root@PerfTestDB1 tmp) #, mysql -uroot -h227.0.0.1 - n - s——default-character-set=gbk - e“;从test.t1" select *;在/tmp/a2。txt
(root@PerfTestDB1 tmp) #/tmp/a2。txt
中国,,1 aaaaaa
(root@PerfTestDB1 tmp) # hexdump/tmp/a2。txt
0000000 d0d6 fab9 3109 6161 6161 6161 000,,
000000 d
========================================================================
注解:在这里能正常倾倒出来,是因为返回给MYSQL客户的时候,已经经过character_set_results=gbk的转换。
,这个相当于第一种方法里的前半部分,直接查看(select * from t1;)
3。,mysqldump,(这种方式将会产生文件:. sql,建表语句,. txt,数据)
========================================================================
(root@PerfTestDB1 tmp) #, mysqldump -uroot -h227.0.0.1——选项卡“/tmp"——fields-terminated-by=& # 39;,,, & # 39;——lines-terminated-by=& # 39; $ $ $ $ $ & # 39;——default-character-set=gbk测试t1
(root@PerfTestDB1 tmp) # t1。txt
涓?浗,,,1 aaaaaa $ $ $ $ $
(root@PerfTestDB1 tmp) # hexdump t1。txt
0000000 b8e4 e5ad bd9b
2626 3126 6161 6161 6161 0000010 2424 2424 0024,,,,,,,,,,,,
0000015
========================================================================
注解:不管上面的——default-character-set设成GBK/use UTF8 LATIN1,中的一个导出的结果都是一致的。
,,,其实这也说明这种方式也是直接将表的真实数据编码直接卸出来,而没有经过转换。
,,,为了进一步证明上述的说法。我STRACE了一下第2,第3两种方法。
,,,strace mysql -uroot -h227.0.0.1 - n - s——default-character-set=gbk - e“;从test.t1" select *;比;/tmp/mysql。日志
,,,strace, mysqldump -uroot -h227.0.0.1——选项卡“/tmp"——fields-terminated-by=& # 39;,,, & # 39;——lines-terminated-by=& # 39; $ $ $ $ $ & # 39;——default-character-set=gbk测试t1祝辞在/tmp/, mysqldump。日志
,,,通过查看日志文件:/tmp/mysql。日志/tmp/, mysqldump。日志,发现在mysql.log中。有这么一段:
,,,- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
