打开第三方的数据库管理软件，找到需要查看编码信息数据库，右键点击选中【更改数据库】
㈡ 怎么设置mysql数据库编码，如何查看mysql编码
MySQL中，数据库的编码是一个相当重要的问题，有时候我们需要查看一下当前数据库的编码，甚至需要修改一下数据库编码。
查看好橡当前数据库编码的SQL语句为：
mysql> use xxx
Database changed
mysql> show variables like
'character_set_database';
+------------------------+--------+
|
Variable_name | Value |
+------------------------+--------+
|
character_set_database | latin1 |
+------------------------+--------+
1
row in set (0.00 sec)
上面，我们先切换到xxx数据库下面来，然后使用SQL语句：show variables like 'character_set_database';
来查看了xxx数据库的祥袜基编码。查询得到的结果是latin1编码。
下面，我们来修改xxx数据库的编码，把它谨谨修改为gb2312。
mysql> alter database xxx CHARACTER SET
gb2312;
Query OK, 1 row affected (0.00 sec)
mysql> show variables like
'character_set_database';
+------------------------+--------+
|
Variable_name | Value |
+------------------------+--------+
|
character_set_database | gb2312 |
+------------------------+--------+
1
row in set (0.00 sec)
㈢ 如何查看mysql数据库的编码字符集
基本上现在的字符集 MySQL 都支持，查看 MySQL 支持的字符集列表， 有两种方法：
1. SQL 语句
2. 查看元数据字典表
查询结果：
1）第一列代表字符集名字；
2）第二列表示字符集排序规则；
3）第三列表示字符集描述；
4）第四列表示字符集编码的最大字节数。
㈣ 怎么看mysql备份数据库的编码
我觉得有可能是你在安装的时候没有设置正确。
当你安装mysql到如下图所示的步骤的时候，如果你原先曾今有一个数据库，并且要用原来数据库的数据，最好能确定原来数据库用的是什么编码，如果这里设置的编码和原来数据库数据的编码不一致，在使用的时候可能会出现乱码。
如果你没有数据库，这一步就是对mysql默认数据库语言编码进行设置，第一个是西文编码，第二个是多字节的通用utf8编码，都不是我们通用的编码，这里要选择第三个，然后在Character
Set
那里选择或填入“gbk”。如果你安装时没有在这里进行修改，使用的默认设置，那么以后你向数据库里插入除了你设置的意外的字符编码都会乱码。
P.S.
用“gb2312”也是可以的，区别就是gbk的字库容量大，它包括了gb2312的所有汉字，并且加上了繁体字、和其它各种特殊字符。通常我们在写入数据库的时候都会对数据进行限制，但这样做也可以在你需要写入这些“火星文”的时候进行支持。
然后在使用mysql
的时候，在执行数据操作命令之前运行一次"set
names
gbk;”（运行一次就行了，GBK可以替换为其它值，视你的设置而定），就可以正常的使用汉字（或其它文字）了，否则不能正常显示汉字。会出现乱码。
㈤ 关于mysql数据库字符编码的问题、中文乱码！
一、转码失败
在数据写入到表的过程中转码失败，数据库端也没有进行恰当的处理，导致存放在表里的数据乱码。
针对这种情况，前几篇文章介绍过客户端发送请求到服务端。
其中任意一个编码不一致，都会导致表里的数据存入不正确的编码而产生乱码。
比如下面简单一条语句：
set @a = "文本字符串";
insert into t1 values(@a);
1. 变量 @a 的字符编码是由参数 CHARACTER_SET_CLIENT 决定的，假设此时编码为 A，也就是变量 @a 的编码。
2. 写入语句在发送到 MySQL 服务端之前的编码由 CHARACTER_SET_CONNECTION 决定，假设此时编码为 B。
3. 经过 MySQL 一系列词法，语法解析等处理后，写入到表 t1，表 t1 的编码为 C。
那这里编码 A、编码 B、编码 C 如果不兼容，写入的数据就直接乱码。
二、客户端乱码
表数据正常，但是客户端展示后出现乱码。
这一类场景，指的是从 MySQL 表里拿数据出来返回到客户端，MySQL 里的数据本身没有问题。客户端发送请求到 MySQL，表的编码为 D，从 MySQL 拿到记录结果传输到客户端，此时记录编码为 E（CHARACTER_SET_RESULTS）。
那以上编码 E 和 D 如果不兼容，检索出来的数据就看起来乱码了。但是由于数据本身没有被破坏，所以换个兼容的编码就可以获取正确的结果。
这一类又分为以下三个不同的小类：
1)字段编码和表一致，客户端是不同的编码
比如下面例子， 表数据的编码是 utf8mb4，而 SESSION 1 发起的连接编码为 gbk。那由于编码不兼容，检索出来的数据肯定为乱码。
2）表编码和客户端的编码一致，但是记录之间编码存在不一致的情形
比如表编码是 utf8mb4，应用端编码也是 utf8mb4，但是表里的数据可能一半编码是 utf8mb4，另外一半是 gbk。那么此时表的数据也是正常的，不过此时采用哪种编码都读不到所有完整的数据。这样数据产生的原因很多，比如其中一种可能性就是表编码多次变更而且每次变更不彻底导致（变更不彻底，我之前的篇章里有介绍）。举个例子，表 t3 的编码之前是 utf8mb4，现在是 gbk，而且两次编码期间都被写入了正常的数据。
3）每个字段的编码不一致，导致乱码
和第二点一样的场景。不同的是：非记录间的编码不统一，而是每个字段编码不统一。举个例子，表 c1 字段 a1,a2。a1 编码 gbk，a2 编码是 utf8mb4。那每个字段单独读出来数据是完整的，但是所有字段一起读出来，数据总会有一部分乱码。
三、LATIN1
还有一种情形就是以 LATIN1 的编码存储数据
估计大家都知道字符集 LATIN1，LATIN1 对所有字符都是单字节流处理，遇到不能处理的字节流，保持原样，那么在以上两种存入和检索的过程中都能保证数据一致，所以 MySQL 长期以来默认的编码都是 LATIN1。这种情形，看起来也没啥不对的点，数据也没乱码，那为什么还有选用其他的编码呢？原因就是对字符存储的字节数不一样，比如 emoji 字符 "❤"，如果用 utf8mb4 存储，占用 3 个字节，那 varchar(12) 就能存放 12 个字符，但是换成 LATIN1，只能存 4 个字符。
㈥ 怎样查看mysql的数据库的编码
mysql查看数据库编码,mysql编码
打开数据库运行：show variables like 'char%';
根据自己需要改的编码进行，set names （*）编码 ；
㈦ 怎么设置mysql数据库编码，如何查看mysql编码
mysql查看数据库编码，郑行亮打开数据库命令行运行：
show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
从以上信息可知数据库的编码为latin1，需要修改为gbk或者是utf8；
其中，character_set_client为客户端编码方式；
character_set_connection为建立连接使用的编码；
character_set_database数据库的编码；
character_set_results结喊宽果集的编码；
character_set_server数据库服务器的编码；
只要保证以上四个采用的编码方式一样，就不会出现乱带橘码问题。