win10系统CMD窗口MySQL5.6中文乱码问题

win10系统CMD窗口MySQL中文乱码

【问题描述：】
       软件、系统环境：
       操作系统：Windows10（64位）
       MySQL软件及版本：mysql-5.6.37-winx64.zip（免安装绿色版）
       IT小白，刚开始自学MySQL数据库，结果就卡住了，于是打算写下这篇日记（可能称不上文章，就日记吧），第一次在博客中写文章，又是非专业人士，文章逻辑、观念理解等肯定有错漏。Windows10系统下通过cmd窗口，输入命令行，向MySQL数据库表中插入数据的时候出现了问题，出入带中文字符的数据就会乱码。经过几番挣扎，看了N多博客文章，按照他们介绍的方法（有在MySQL里面通过手动设置字符集编码的，有通过修改my.ini配置文件的），我都尝试了，但最初我都没修改成功。
       直到最后我解决了中文乱码问题的时候，发现并不是他们的解决方案的问题，而是我缺少的一步，这一步是我在安装MySQL，配置my.ini文件时忽略的（为了解决中文乱码这个问题，我重装了3次MySQL，最后发现也不是软件的问题，而是配置过程的问题），那就是忘记手动设置MySQL默认的配置文件为my.ini。
       【以下是我的理解，如有纰漏，欢迎指正】
       【简单说，cmd窗口下mysql中文乱码主要是cmd客户端、mysql客户端和这两个客户端之间传输信息的连接层，三者的字符集编码方式出问题】
       虽然网上说mysql会默认使用后缀.ini的配置文件，但是在MySQL解压目录下有 my.ini 和my-default.ini 两个配置文件，如果不在安装配置MySQL服务器的时候手动设置谁作为配置文件来使用，那么在启动或者是命令行修改字符集编码配置信息的时候，会报错或者配置在服务器重启之后没有生效（我遇到的问题，当mysql解压目录根目录下同时存放 my.ini 和 my-default.ini 两个配置文件，用命令行启动mysql服务时提示系统发生意外，服务无法启动，删掉两者之一，停止任务进程，重启服务有可以正常启动）

【注意】：如果按照网友问提出的解决乱码的方法（基本上就是下面两种，暂时留到后面细讲，这里主要介绍如果这两种方法都没效果的最后一个尝试方法—手动选定mysql默认的配置文件）：
-（1）cmd窗口连接进入mysql服务器之后，通过命令行手动mysql字符集。【这种方式只能临时有效，下次重新启用mysql服务，上次手动命令行修改的配置会失效】

-例：使用命令行设置字符集
set character_set_(client、connection、database等) = (gbk、utf8);

-（2）找到MySQL解压目录根目录，修改配置文件my.ini。【修改配置文件的方式会永久有效。这里我的mysql解压路径是 D:\SoftWare\mysql-5.6.37-winx64 】

如果上面这两种方法都没效果，那就试试下面的方案！！！

针对Windows10系统中免安装版mysql-5.6.37-winx64在cmd窗口出现中文乱码最终尝试解决方案：

关闭MySQL服务，手动设置MySQL服务采用 my.ini 作为默认配置文件

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- 首先关闭MySQL服务（管理员运行cmd窗口，以免权限不足，无法执行命令）

-找到MySQL解压目录（安装目录—因为我用的是免安装的MySQL，找到解压目录即可）

-查看 my.ini 文件里面的配置信息【如果没有 my.ini 文件，可以把 my-default.ini 复制一份重命名为 my.ini，再手动写入配置信息就好了。】

[client]
port=3306
default-character-set=gbk[mysqld]
port=3306
character_set_server=utf8#安装路径
basedir=D:\SoftWare\mysql-5.6.37-winx64
#数据路径
datadir=D:\SoftWare\mysql-5.6.37-winx64\data[WinMySQLAdmin]
D:\SoftWare\mysql-5.6.37-winx64\bin\mysql.exe

从cmd控制台窗口进入MySQL解压目录下面的 bin 目录

切换盘符到安装目录所在的盘符（我的解压目录在 d 盘）
d: 回车（"盘符名" + ":"   英文状态下的  ）
cd D:\SoftWare\mysql-5.6.37-winx64
( cd  后面有个空格)

在mysql的 bin 目录下输入命令：

mysqld install MySQL --defaults-file="D:\SoftWare\mysql-5.6.37-winx64\my.ini"

-这里提示服务已存在，因为我在这之前就已经把 my.ini 文件设置成默认的了，现在再次输入这个默认文件配置命令就提示该服务已经存在了！

-然后打开MySQL服务，连接进去查看新旧数据库表是否能够正常插入和显示中文字符。

===========================================================================================================

【下面是我还原配置，重现cmd中mysql中文乱码到再配置解决中文乱码的记录，小白一枚，理解和表达还有很多问题，写的乱、不好，只作为一次记录（不敢断定正误），但毕竟第一次写，希望以后有进步！】

-由于我原来MySQL中 my.ini 配置文件已经配置好，我现在还原配置，使其出现中文乱码的问题，最后再通过修改配置，解决中文乱码问题，顺带附图

【这里斜体字部分是将我原来配置好的mysql通过移除服务，再次使用命令行安装和配置的过程】
- 关闭mysql服务器：

net stop mysql

- 移除mysql服务

mysqld remove

- 找到mysql解压目录根目录，将原来的 my.ini 文件删除

       -通过cmd窗口命令行重新安装mysql
       -首先进入到mysql解压目录下的 bin 目录，我的在D盘，所以先切换盘符，输入 d:
       -然后输入

cd D:\SoftWare\mysql-5.6.37-winx64\bin

【你也可以一级一级进入到该目录，直接把mysql解压目录下的 bin 目录路径复制过来比较快】

成功进入mysql解压目录下的 bin 目录
输入mysql服务安装命令：

mysqld install MySQL

-启动mysql服务

net start mysql

-mysql服务启动成功

- 连接数据库，输入命令行：

mysql -uroot -p

-这里连接数据库的命令不一定是在mysql解压目录下面的 bin 目录，也可以是在其他目录下，前提是你的mysql做好了Windows系统的环境变量配置（因为我都是同一个解压目录—可以说这次的安装路径和注册表信息和以前的一样，所以不再做mysql系统环境变量的配置截图了）。

-查看此时mysql的字符集编码，输入命令：

show variables like '%character%';

-是不是很眼熟，三种字符集编码格式。

-接下来测试到底能不能通过 cmd 命令控制台向mysql数据库表中插入带中文字符的数据。

-查看此时mysql里面的所有数据库【注意不要漏掉 s 和分号，英文状态的哦】

show databases;

-查看 wrj 这个数据库【我在这个还原操作之前已经设置字符集为utf8】的字符集编码

不管上面这个 wrj 以前的数据库
【接下来我们新建数据库和表来测试中文乱码问题】
-新建数据库：test_chinese

create database test_chinese;

使用刚才新建的 test_chinese 数据库，并且在里面新建数据表 day

use test_chinese;
create table day(did int primary key,dname varchar(15) not null);

查看当前数据库和数据表的字符集编码

show create database test_chinese;
show create table day;

此时，test_chinese数据库和day数据表的默认字符集编码格式都是 latinl。
向表里面插入一条数据：

insert into day(did,dname) value(1,'monday');

插入成功。
测试中文字符能否插入：

这次中文字符数据居然成功了！！！神奇了。

再看看刚才插入的中文字符数据能否正常显示：

select * from day;

数据出现乱码了！！！

【简单说明一下我根据部分网络博客理解的中文乱码的原因】：
       其他客户端与MySQL客户端、MySQL服务、数据库和表的字符集之间的转换出现问题，这里可以了解到mysql的字符集和校对规则有4个级别的默认设置：服务器级、数据库级、表级和连接级。（【文章：mysql字符集设置】https://www.2cto.com/database/201407/314602.html）
       --这里我查看我的电脑Windows10系统中cmd命令控制台的字符集，可以看到CMD的编码方式默认 gbk ，可以通过在 cmd 里输入 CHCP查看操作系统的cmd的编码方式。

       这个活动代码页：936，指的就是使用 gbk 编码。原来我也试着修改cmd的编码格式为utf8（活动代码页：65001），因为mysql本身默认的编码是utf8，我以为这样就可以了，然后发现不行。因为如果我将cmd的编码方式设置为utf8，当我在cmd创窗口想向数据库表里面插入带中文的字符时，发现中文输入法没法调用了，所以我放弃了。（修改cmd的默认编码方式可以自行度娘，这里不详细记录。【可参考文章：windows 控制台cmd乱码（及永久修改编码）的解决办法https://blog.csdn.net/qq_35038153/article/details/78430359】）

说明上面的字符集代表的意思：【资料来源：MySQL字符集和字符集的转化过程】

character_set_client: 客户端来源数据使用的字符集
character_set_connection: 数据通信链路的字符集，当MySQL客户机向服务器发送请求时，数据以该字符集进行编码。
character_set_database: 数据库字符集。
character_set_filesystem: MySQL服务器文件系统的字符集，该值是固定的binary。
character_set_results: 结果集的字符集，MySQL服务器向MySQL客户机返回执行结果时，执行结果以该字符集进行编码。
character_set_server: 内部操作字符集(MySQL服务实例字符集)
character_set_system: 元数据(字段名、表名、数据库名等)的字符集默认为utf8

字符集的转换过程：
    （1）在命令提示符窗口输入MySQL命令或sql语句，回车后，这些命令将会被转化为character_set_client定义的字符集使用命令提示符窗口成功连接MySQL服务器后，就建立了一条”数据通信链路”。
    （2）MySQL命令或者sql语句沿着这条”数据通信链路”传向MySQL服务器，由character_set_client定义的字符集转化为character_set_connection定义的字符集 MySQL服务实例收到数据通信链路中的命令，将语句从character_set_connection定义的字符集转换为character_set_server定义的字符集。
    （3）若MySQL命令或sql语句针对某个数据库进行操作，此时将命令由character_set_server定义的字符集转换为character_set_database定义的字符集。 MySQL命令或sql语句执行结束后，将执行结果设置为character_set_result定义的字符集。执行结果沿着打开的数据链路原路返回，将执行结果转换为character_set_client定义的字符集，最终转换为命令提示符窗口字符集显示在命令提示符窗口。

下面这篇文章对MySQL字符集及其转换做了比较详细的介绍，附上文章链接，推荐看！！！

字符集&字符编码方式

【那么如何根据字符集转换规则，理解我刚才能够插入中文数据，查询显示却乱码了呢？】
看看我们现在的MySQL、数据库、数据表的字符集设置：

【根据上文字符集的转换规则，以下是我的分析理解，不一定正确，因为我是小白，刚开始学MySQL，还没入门。但是这个乱码问题困扰我很长时间了，特此记录】
先用杯子和水来比喻（不一定恰当，我自己认为的）：

假设：
latinl 字符集是一个容量为250毫升只能装可乐的杯子（不支持中文—这里假设中文数据是水，英文数据是可乐，而水或者可乐或是其他液体，可能是自然界的，也可能是人造的—这里说同种液体是人造的或是自然界的，我就想表达的是同一个数据会有多种进制的表现方式。不支持中文如果要放入中文数据，就相当于这个250毫升容量的只能装可乐的杯子要放200毫升的水（经过转换了），显然不行。这里更严格来说还涉及到不同字符集转换之间的进制值，因为我不是专业的，没法深入的记录说明，用杯子和不同性质的液体来表达，只是我按自己的想法记录表达的东西，也不一定对，这样比喻只是表达我是这样来理解的）
gbk 字符集是一个容量为500毫升的既能装水也能装可乐的杯子（支持中文）
utf8 字符集是一个容量为1000毫升的不论是什么液体都能装的杯子（支持中文）
插入或是查询数据库表的数据相当于液体，这个液体是多少毫升（体积）就看数据有多大。
不同字符集之间的转换是不同杯子之间倒入液体的一个魔法作用（举例说明，液体由400毫升水经过一个魔法作用，变成500毫升可乐，要倒入目标杯子，但要倒入的目标杯子容量只有250毫升，那么最后我们在目标杯子里看到的只有250毫升的可乐，但实际上溢出目标杯子的可乐也是存在的，只是我们看不到）
假设魔法转换过程 1毫升水=3毫升可乐（中文字符通过进制转换成其他字符，字节会发生变化）。等量的可乐变成水，体积变小，等量的水变成可乐，体积变大，具体变多大多小这里也不量化考虑，变化前后的数据大小可以看出就行。（不详细考虑计算机实际中同一个数据传递存储的不同进制的字节大小，物理化学什么的，便于我的理解）
经过魔法作用（字符集转换），可能会出现液体体积变化，而杯子容量是不变的，液体在倒入杯子后，可能会溢出，（液体溢出说明该字符集无法表现传递过来的字符值，而我们只能看到杯子里的液体，但实际上杯子外还有液体，他们本来是一个杯子里的一体，液体溢出杯子，导致最初和最后两个杯子里，前后液体体积不一样–即使液体性质改变，我理解这样就是出现乱码了）
关于液体溢出杯子制定如下规则：将自己本身杯子里已经装的液体全部倒入下一个杯子，而原来自己本身杯子外面溢出的液体不再倒入下一个杯子，只能告诉下一个杯子，他的外面还有液体----最终能呈现我们在我们眼里的（你在屏幕上能看到的）只有杯子里的液体。
假设我们只能看到杯子里最后有多少液体（屏幕上显示的字符集样式），溢出的我们看不到，但溢出杯子的液体是存在的。

分析理解：【我非专业人士，下面只是我自己的记录，比喻不一定恰当，分析不一定对，我理解起来也有点晕。只是希望如果以后自己在遇到CMD窗口出现MySQL中文乱码的问题，再看到这里自己写的分析的话，还能够想起来】
       （1）我在cmd窗口（gbk字符集，500毫升的杯子）输入命令行‘insert into day(dia,dname) value(2,‘周二’)’回车，这相当于发送一个请求：往mysql数据库表 day（latinl 字符集）这个杯子里面倒入 100毫升的水（gbk字符集，因为这时水还是在 cmd（gbk）这个杯子里）
       （2）名为client（gbk字符集）的杯子（只要是gbk字符集这一类的杯子，容量都是500毫升，名字不一样嘛）看到这个请求，发现两者装液体的属性都是一样的—既能装水也能装可乐，client（gbk）杯子就先接收了这100毫升的水，但是这100毫升水是要放到数据库表 day（latinl 字符集）那个杯子里面，这期间要 依次经过名为 client、connection、server、database、results的这几个杯子之后，我们最后才能在results这个杯子里查看最终的液体。然后client（gbk，容量500毫升）杯子找到下一个名为 connection（gbk）的杯子。
       （3）connection（gbk）这个杯子发现自己和client（gbk）两者装液体的属性都是一样的—既能装水也能装可乐，所以直接接受了这100毫升的水。接着去找下一个名为server的杯子。
       （4）server（latinl，容量250毫升，只能装可乐）这个杯子发现自己和connection（gbk）这个杯子装液体的属性不一样，所以要借助一个魔法作用（不同字符集之间的转换）。这里connection（gbk）这个杯子里100毫升的水经过一个魔法作用变换成了300毫升的可乐（前面假设了魔法作用规则–字符集转换规则–等量的水变成可乐，体积变大），但是serve（latinl）这个杯子容量只有250毫升，所以serve（latinl）杯子里有250毫升的可乐，也有溢出杯子外的50毫升可乐，但是不管杯子里的还是溢出杯子外的可乐他都要传递给下一个杯子【魔法作用液体溢出规则：将自己本身杯子里已经装的液体全部倒入下一个杯子，而原来自己本身杯子外面溢出的液体不再倒入下一个杯子，只能告诉下一个杯子，他的外面还有液体----但最终能呈现我们在我们眼里的（你在屏幕上能看到的）只有杯子里的液体】**。接着serve（latinl）这个杯子去找到下一个名为 database（latinl）的杯子。
       （5）database（latinl，容量250毫升，只能装可乐）这个杯子发现自己和serve（latinl）这个杯子装液体的属性一样，可以直接接收可乐。database（latinl）接收250毫升server杯子里的可乐，（到这里我理解就是mysql已经在 day 这张表里存下了数据，但因为database（latinl）杯子能装而且只能装250毫升—回想我之前能插入中文字符；查询显示却乱码我想就是因为上一个杯子把液体传递到database杯子上，上一个杯子传递了有溢出的液体，但是我们能看到的只有results这个杯子里的液体–回想杯子间液体传递的规则，上一个杯子外溢出的液体不倒入下一个杯子，但下一个杯子直到它外面还有属于它的液体，但限于规则不能倒入自身杯子里–不管自身能不能全部装得下上一个杯子传递过来的液体）还要把之前溢出的50毫升可乐（server之前装不下的可乐）一起传往下一个名为results（gbk）的杯子。
       （6）results（gbk，容量500毫升）杯子发现自己和serve（latinl）这个杯子装液体的属性不完一样，但是可以results（gbk）杯子兼容serve（latinl）这个杯子的液体属性，所以可以直接接收液体。所以此时results（gbk）杯子里存在250毫升可乐，杯子外存在50毫升可乐，但是我们只能看到杯子里的液体（250毫升可乐）。
       （7）最初cmd杯子（gbk）里的是100毫升水，最后一个杯子results（gbk）里的是250毫升可乐，这里进行体积换算，100毫升水=300毫升可乐，明显最初cmd（gbk）杯子里100毫升水（相当于300毫升可乐）与最后一个杯子results里的250毫升可乐体积不等（不算杯子results外还有的50毫升可乐，因为我们假设了人眼只能看到杯子里的液体），所以我们看到的就是乱码了。但实际上，计算机内存中存储的数据包含了杯子内外的液体，我们读取数据就相当于用不同容量（250、500或1000）不同属性（只能装可乐latinl、既能装水也能装可乐gbk，什么液体都能装utf8）的杯子去取出液体时，我们看到的杯子里的液体的多少和你最初放进去的液体总体积可能是不一样的，只是看到的可能不一样，但实际存储的大小没变（这个含杯子内外的液体）。

【写完上面这段话，我自己都还是感觉很乱，很奇怪，小杯子里的水为什么不能倒到大杯子里去装-，自己都懵了----存在某种规则，我想到有点像java里面的数据类型转换，大变小不可以（超出数据类型范围就不行了），小变大可以，是不是有点类似，文科生，我的逻辑思维乱乱乱！！！！】

【下面尝试修改 database 和 server 字符集，再次查询结果】

【方法1：在cmd里通过命令行修改MySQL字符集编码方式】
-将 day 表的字符集改成 gbk：

alter table day character set gbk;

将 test_chinese 数据库的字符集改成 gbk：

alter database test_chinese character set gbk;

查询 day 表数据：

还是乱码，修改mysql数据库库服务的字符集为gbk：

set character_set_database=gbk;
set character_set_server=gbk;

-还是乱码。

-看图，同种颜色部分的字符集应该一致，所以我把 database 、server 的字符集改成和 system一样的 utf8 ，再试一次。

set character_set_database=utf8;
set character_set_server=utf8;

-还是乱码，那如果新建一个数据库，新建一个表呢？？？
-新建数据库：create database test_new;

-可以看到新建数据库默认字符集utf8
-在数据库test_new下新建数据表 news

create table news(nid int primary key,title varchar(50),content varchar(50));

-插入一条英文数据：

insert into news(nid,title,content) value(2,'china','chongqing');

-显示正常，测试插入带中文字符的数据：

insert into news(nid,title,content) value(5,'天气预报','今天天气不错');

-这里中文显示正常。
-我们回到数据库 test_chinese 中的 day 表,之前我们把这个库表的字符集设置成gbk

-我们现在test_chinese和day的字符集设置成utf8，然后再次查看查询数据信息是否乱码。

alter database test_chinese character set utf8;
alter table day character set utf8;

-utf8字符集设置成功，再次查询该表数据：select * from day;

-还是中文乱码，设置没生效？？？
我们重新启动MySQL试试：

-可能是没有管理员权限，重新以管理员运行cmd，关闭mysql服务：

-mysql 重启成功
-连接mysql数据库，查看上次修改的mysql字符集配置是否更改：

-上次通过cmd窗口修改的mysql字符集配置，重启MySQL服务之后失效了。

-查看上次对具体数据库和数据表的字符集设置是否还是生效的：

-上次在cmd窗口对具体数据库、表的字符集修改的设置任然是生效的。

【小结】
-在cmd窗口通过命令行设置MySQL字符集之后，新建的数据库和表的字符集都变成当前cmd窗口修改的MySQL字符集。但是这时我们原来（修改字符集前就已经存在的库、表）的数据库表在查询数据的时候还是出现中文乱码的，通过手动修改原来库表的字符集，中文乱码还是没有解决。但是只要是新建的数据库表都没有出现中文乱码。在重启MySQL服务之后，上次通过cmd窗口命令行手动设置MySQL字符集的配置失效了，但原来对具体某个数据库、表的字符集修改是生效的。

【方法2：找到MySQL解压目录（安装目录）修改 my.ini】
【如果修改my.ini配置文件还是没法生效的话，就需要关闭mysql服务，通过cmd窗口，手动安装配置mysql及其默认的配置文件，详看前文】

-首先要关闭 mysql 服务，再进行下面的操作。

- 我的mysql解压目录是 D:\SoftWare\mysql-5.6.37-winx64

-找到 my-default.ini 文件，复制一份，重命名为 my.ini

打开 my.ini 文件进行配置信息编辑，输入如下信息：

【注意：因为MySQL数据库版本不一样，my.ini 配置文件里面的命令行可能会有细微的差异，这里我的MySQL版本是：mysql-5.6.37-winx64】
- 具体的安装路径因人而异啦

[client]
port=3306
default-character-set=gbk[mysqld]
port=3306
character_set_server=utf8#安装路径
basedir=D:\SoftWare\mysql-5.6.37-winx64
#数据路径
datadir=D:\SoftWare\mysql-5.6.37-winx64\data[WinMySQLAdmin]
D:\SoftWare\mysql-5.6.37-winx64\bin\mysql.exe

- 保存 my.ini 文件，启动 MySQL服务。

- 连接MySQL数据库，查看此时默认的字符集配置信息：

- my.ini 配置文件生效，接下来测试原来的数据库表信息能否正常显示。
- 打开数据库 test_chinese 里面的 day 表，查询

- 原来最先的数据库表的还是乱码，即便数据库表的字符集是utf8
- 【这里我非常不明白，即使配置信息都一样，但为什么对原来的表不生效，新建的都可以，待了解】

- 那如果在这里插入带中文数据的信息，再查询会不会乱码呢？---测试一下

- 插入带中文的数据就提示字符乱码了。
- 那我们换个上次新建的 test_new 数据库，当时在 news 表里，能够正常插入和显示中文字符，测试这次能不能正常显示：

- 首先 news 表里面的数据能够正常显示，下面插入一条带中文字符的数据进行测试：

- 这上次通过命令行配置字符集新建的 news 表可以正常插入和显示中文数据。

- 这次我们是通过修改 my.ini 配置文件的方式修改默认字符集，下面测试新建的数据库表的字符集编码，以及能否正常插入和显示中文字符数据:
- 新建数据库 test_my 和数据表 mine

create database test_my;

create table mine(id int primary key,name varchar(10),sex varchar(10),age int);

-mine 表创建成功，测试插入一条带中文字符的记录：

insert into mine value(1,'江江','boy',23);

-可以看到，此时my.ini配置文件的设置生效。

【文末小结】

第一次写博文，写的好乱啊，而且自己是个小白，非专业人士，理解上，表述上还有很多问题。本来只是想自学MySQL数据库，快速入门，因为win10系统CMD窗口下MySQL中文乱码这个问题，自己弄了两三天了，现在脑海了就一句话：还没入门，已经入坟！
不过大致也了解了CMD命令控制台MySQL出现中文乱码的原因，简单来说就是其他客户端与MySQL客户端、MySQL服务、数据库和表的字符集之间的转换出现问题。
写下这篇记录的时候，真心感慨和佩服那些博客前辈，乐于分享那么多疑难杂症的解决方案。以后有新的思绪再重新记录，修正，这次就写到这里吧！