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.嘿嘿不管怎样，需要自己细心，思考，探索，提问，总结。