MySQL的一万个细节之被忽略的命令串儿：--default-character-set=utf8

一.背景概述

上周接到数据迁移的任务后，截止周末来临前，终于完成了数据迁移的工作。我本以为此事就此了结了，却没想到在周一刚上班就被一个问题糊上了脸。

导入的数据，只要涉及到中文的，全是乱码。

二.过程

既然同事反应问题，我立马自己亲自验证了，结果当然是否认三连啦。奇怪的是，两人把各自的结果拿到一块对比，同一张表，同样的查询SQL，我这边执行查询显示正常，同事那边显示乱码。为了解决问题，两人一起一一排查。

由于操作数据库是通过secureCRT远程连接服务器，通过命令行操作，所以首先检查secureCR的窗口显示编码方式，如图：

结果双方secureCRT的编码格式一致。

      接下来同事又提议检查我代码中涉及写文件的代码编码格式：

 /**
     * 文件内容追加，以换行符结尾
     *
     * @param fileName 文件名（绝对文件路径名）
     * @param content 文件内容
     */
    public static void appendInfoToFile(String fileName, String content) {
        File file = new File(fileName);
        try {
            // 如果文件不存在，新建一个文件
            if (!file.exists()) {
                file.createNewFile();
            }
            FileWriter fileWriter = new FileWriter(file, true);
            content = content + "\r\n";
            fileWriter.write(content);
            fileWriter.flush();
            fileWriter.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

其实这个方法是经过检验的，很多次调用都没问题，而且我的idea设置编码格式就是utf8。不过，

            FileWriter fileWriter = new FileWriter(file, true);

FileWriter默认采用系统编码格式，在IO类库和Stream流日益强壮的当下，是不推荐使用的。当然了，既然同事指出问题，我也就顺手改了，代码如下：

/**
     * 文件内容追加，以换行符结尾
     *
     * @param fileName 文件名（绝对文件路径名）
     * @param content 文件内容
     */
    public static void appendInfoToFile(String fileName, String content) {
        File file = new File(fileName);
        try {
            // 如果文件不存在，新建一个文件
            if (!file.exists()) {
                file.createNewFile();
            }
//            FileWriter fileWriter = new FileWriter(file, true);
            OutputStreamWriter fileWriter = new OutputStreamWriter(new FileOutputStream(file, true), "UTF-8");
            content = content + "\r\n";
            fileWriter.write(content);
            fileWriter.flush();
            fileWriter.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

经测试，查询显示还是会产生乱码。

       然后我这边又断开服务器连接，重新登录以后，发现我无论查询哪张表，只要涉及中文，也是产生乱码问题。

       无意间，我了登录数据库的命令行，才恍然大悟。（下面命令行是模拟，真实命令与这个相差无几，也就是改写参数而已）

mysql -uroot -pxxxxxxx -hm3036c.xxxx.xxx.xxx.com.cn -P3036 LBS

-hm，表明我登录的MySQL数据库的主库。最近一周一直用主库做数据迁移，迁移结束后，测试也没啥问题。然后我又看了一下之前使用的从库命令串，如下：

mysql -uroot -pxxxxxxx -hs3036c.xxxx.xxx.xxx.com.cn --default-character-set=utf8 -P3036 LBS

对比命令行，发现命令中不一样的地方主要就是：

--default-character-set=utf8

于是我在主库和分库运行同样的SQL去测试，对比结果如下：

 

退出主库，将登录命令添加--default-character-set=utf8后再测试，结果显示正常，没有出现乱码。

三.总结

       这是一个很简单的问题，也没用什么高深的技巧。其实，不论是之前的学习还是工作中，在命令行登录数据库中，”--default-character-set=utf8“一直是被认为可有可无的，被忽略的。确实在此之前没有遇到过像本次这样，登录后查询显示中文乱码问题。

      ”--default-character-set=utf8“有什么用吗？仅仅是查询显示编码问题吗？不，就目前为止，还有另一个场景经常用到,比如使用如下命令拉取数据：

mysql -uroot -pxxxxxxx -hs3036c.xxxx.xxx.xxx.com.cn --default-character-set=utf8 -P3036 database -s -e "select rgc_id, astext(wkt) as wkt from lbs_rgc_wkt;" > wkt.txt

如果不加”--default-character-set=utf8“，得到的数据下载到本地很可能会出现乱码问题。