gpload中乱码问题解析---从"珅"字说起

从“珅”字说起

在做某个表数据的gpload之后，查询error表，发现有10多行的数据被reject了，并保存在了error表中，err_msg中的信息为”无法对’0xab2f’做从gb18030到utf8的转码”。

根据业务主键找到了源文件中对应的记录，并找到了有问题的字符

“佛山？宝”

查看16进制，其中的“？”为AB 2F

百度‘佛山宝某公司’，得到了正确的字符应该为“珅”

查看“珅”的码值，得到 AB 7C

并在后续的几个error表中相继发现了一些乱码字符‘億瓅磡韡珅弢梶’等

它们都有一个共同点，就是码值的低位都是7C

那么7C是什么，7C单独看来其实就是我们常用的分隔符‘|’，而2F恰恰是‘/’

那么很明显了，源头文件经过某些转换，导致分隔符变成了转义符‘/’

找到原因，我们的解决方法是否就很简单呢？

首先，采取查找替换是否能解决这一问题，就是把2F替换成7C，看上去是可行的，然后在经过实际操作之后，发现是不行的。

在查找的过程中，发现出现了‘某全/某’这样的字符串，在16进制下可以看到被转成了‘C8 AB 2F’，也就是‘全’字是C8 AB，而后面跟的‘/’是2F，于是产生了这种将前面字符的低位截断到后面的问题，一旦替换，就变成了‘C8’‘珅’，不但产生了新的乱码，而且数据完整性也被破坏了。

另外,我们无法肯定2F肯定是由7C变化来的,比如A3 2F,当转换成A3 7C的时候,这个字符就是个空,这显然是错误的,只能说明A3 2F并非由A3 7C转来,而是由另外的什么字符转来的

既然清洗无法做到，那么是否能完全根据oracle的方式来入数？就是把无法转换的乱码转换为一些可以入数的乱码，比如转成“？”。

经过了解，Utf8方式可以完成这一转换，即把要gpload的文件转换为utf8格式，然后在gpload的配置中也采用utf8，经过测试，这的确是可行的入数方式，虽然入库的数据是乱码，但毕竟入库了。

那么如何把DS输出的文件转成utf8格式呢？

用UE，没问题，用p