1.1 乱码现象
DataWorks的数据离线集成(DataX)集成Oracle数据到MaxCompute的数据有乱码,但是看源库不是乱码,这是什么原因?
现象:【Oracle;工具:plsql-dev】
【MaxCompute;工具:DataWorks】
select OP_USER from test.mdtsb where
uuid='161A45E75BC88040E053441074848040';
1.2 问题分析
使用两个 oracle 函数:
【DUMP; CONVERT; 】
http://docs.oracle.com/database/122/SQLRF/DUMP.htm#SQLRF00635
http://docs.oracle.com/database/122/SQLRF/CONVERT.htm#SQLRF00620
为了避免转码正确是因为刚好乱码的列的真实字符集与操作系统字符集相同而导致显示正常,选择了使用 linux 环境,客户端字符集设置为 UTF8,使用 SQLplus 进行查询分析问题。
1.客户端环境:
SQL> select userenv('language') from dual;
USERENV('LANGUAGE')
----------------------------------------------------
SIMPLIFIED CHINESE_CHINA.AL32UTF8
2.使用 dump 函数把文本对应的编码输出出来:
SQL> select dump(OP_USER,1016) from test.mdtsb where
uuid='161A45E75BC88040E053441074848040' ;
DUMP(OP_USER,1016)
----------------------------------------------------
Typ=1 Len=6CharacterSet=AL32UTF8: c0,ee,be,b0,ea,bb
这个函数输出的信息有三个
- 长度是 6 字节
- 字符集是 AL32UTF8
- 字符编码是 c0,ee,be,b0,ea,bb
通过这些信息,我们猜测原来的字符集可能是 GBK 或者 GB18030、GB2312 这几个字符集的编码。因为三个汉字,如果是 UTF8 的话他们的编码大部分都是一个汉字对应三字节。而 GBK字符集对应的编码是双字节。
3.查看c0,ee,be,b0,ea,bb 对应的 GBK 字符
http://www.qqxiuzi.cn/zh/hanzi-gbk-bianma.php
c0,ee