mysql导入dbf乱码的跳坑经历

    遇到了一个奇葩的问题,之前也碰到过,不过要么时曲线救国,要么是经过一番尝试后放弃了。 

    经过如下,因为实践需要,必须用别人的dbf文件导入数据,可是导入乱码。  查看导入的编码选择:

    

    选择的是utf-8,没有毛病啊。  而且Utf-8是一个国际通用的编码,支持所有的字符。可是就是不行。

    后面灵机一动,去看看dbf文件的编码吧。   果不其然,其编码为 ansi,也就是gbk编码。   

    于是洋洋洒洒,大笔一挥。  问题解决。   然而,非也。、

    再次导入的时候,目标列不能识别,所有的数据都变为了空的数据,自然插入的时候会报主键冲突,然后就失败了。

    会不会是自带的记事本对编码转换存在局限呢?   

        于是采用站长工具,直接将原文本文件全部转为utf-8编码,再调用的时候可好,cpu直接飙到30%,各种提示错误。  再修改文本文件的时候直接提示说有程序占用。   心情有点烦躁的情况下直接注销了。 、

        于是采用第二套方案,直接将原文本导入sublime中,存为utf-8编码,导入, 同样的问题。

        正在我将要采用第三套方案,也就是通过Java 写一个工具类,将所有的dbf文件转换为规则的txt文件导入时,我尼玛突然发现了一个十分尴尬的问题:

        

    苍天啊,大地啊。。。。这里有一个下拉框啊!!!

    枉我中途还去查了查57006 到 57011各自代表的编码含义。 55555

    顺藤摸瓜,果断找到gbk,ok问题解决。 

    经验教训: 

               1. 很多时候源文件并不能乱改编码,但是理论上来说只要编码与解码采用的方式相同,应该是能够成功完成对接的。   具体什么原因会在今后的基础学习中解决并得到答案。 

               2.那就是思维惯性。 就像原来高中做一道数学题,很多时候会从我们脑海中搜索此类型题的解法。应该算是演绎和类推的方法吧。    但是一旦出现了一个有一定变通的题目,但是外形上看出来很相似的时候,我们总会绕许多弯路或者直接做错。

要克服这类问题,要求我们对基础掌握必须牢靠,对里面的关键点必须明确。     这里而言,就是在于:它的下拉框是同样的色调不易引起注意。 而最根本的是:它的下拉框默认就是最底部,跟我们平常所见的下拉框不同,操作方式也就不同。 自然注意到下拉框的几率也就减小了  。

                3.嘿嘿不管怎样,需要自己细心,思考,探索,提问,总结。 

阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页