MySQL字符集不同，GB2312与UTF8解决MySQL中国混乱的代码的问题
MySQL中涉及的几个字符集字符集服务器默认字符集：默认使用的服务器字符集。
字符集数据库：数据库字符集。
字符集表：数据库表字符集。
一般来说，我们只需要设置字符集服务器，但在创建数据库和表时不指定字符集，因此我们使用字符集服务器字符集进行统一设置。
字符集客户机：客户端的字符集。客户端的默认字符集。当客户端向服务器发送请求时，请求用字符集进行编码。
字符集结果：结果字符集。当服务器返回结果或信息给客户机时，结果用字符集进行编码。
在客户端，如果没有定义字符集结果，则使用字符集客户端字符集作为默认字符集，因此只需要设置字符集客户端字符集。
在过程中，你可以设置服务器和客户端字符集字符集为GB2312，如果你想同时处理多种语言，它被设置为utf8。
关于mysql的中文问题
解决乱码的方法是把三个MySQL参数下面的SQL设置为服务器字符集的字符相同的字符设置服务器在执行该语句。
character_set_client：设置客户端的字符。
character_set_results：结果字符集。
character_set_connection：连接字符集。
通过发送语句MySQL设置三系统参数：设置名称GB2312
在GB2312，GBK，UTF8
UTF-8：Unicode转换format-8bit，它允许包含BOM，但通常不包含BOM。它是用来解决多字节字符编码的国际。编码8位（一个字节）在英国和中国的24（三字节）。UTF-8包含所有的国家都需要使用在世界上的角色。这是国际通用的编码，UTF-8编码的文字可以显示在浏览器支持集各国UTF8字符。例如，如果是UTF8编码，中国也可以显示在一个外国人的英文IE，他们不需要下载IE支持包。
GBK是基于国家标准GB2312兼容GB2312的扩展标准。编码GBK字符用两个字节，这是代表，中文和英文字符用双字节表示。为了区分中国最高级别设置为1.gbk包含所有的汉字，是国家代码，一般比UTF8，但占比更大的数据库为GBD。
GB2312，GBK，UTF8编码和其他必须的Unicode码相互转换：
GBK，gb2312unicodeutf8
utf8unicodegbk，GB2312
一个网站和一个论坛，如果有更多的英文字符，建议使用utf - 8节省空间。但现在很多在论坛的插件一般只支持GBK。
GB2312是GBK的子集，和GBK是GB18030的子集
GBK是大字符集，包括中国、日本和韩国的特点
如果中国网站推荐GB2312 GBK，有时候这是个问题
为了避免所有的随机编码UTF-8的问题，应采用和它在未来支持国际化非常方便。
UTF-8可以看作是大字符集，其中包含了大部分的文本编码。
使用UTF-8的一个好处是，用户在其他地区，如香港台湾，可以看你的文字没有弄乱没有安装简体中文支持。
GB2312是简体中文编码
GBK支持简体中文和繁体中文
big5支持繁体中文
UTF-8支持几乎所有的字符
首先，分析了混沌码的现状。
1。将数据库作为随机代码写入数据库。
2。查询结果以随机代码返回。
代码正在发生什么情况
让我们先输入MySQL命令行
显示变量如% char %；
查看MySQL字符集设置：
显示诸如% char %之类的变量；
-------------------------- ---------------------------------------- + + +
| variable_name |价值|
-------------------------- ---------------------------------------- + + +
| character_set_client | GBK |
| character_set_connection | GBK |
| character_set_database | GBK |
| character_set_filesystem |二进制|
| character_set_results | GBK |
| character_set_server | GBK |
| character_set_system | UTF8 |
| character_sets_dir | / usr /局部/ MySQL /分享/ / / | MySQL字符集
-------------------------- ---------------------------------------- + + +
在查询结果中，您可以看到MySQL数据库系统中的客户机、数据库连接、数据库、文件系统、查询。
结果、服务器和系统的字符集设置
这里，文件系统的字符集是固定的，系统和服务器的字符集是在安装时确定的，与混沌码的问题无关。
混沌码的问题与客户机字符集、数据库连接、数据库和查询结果的设置有关。
*注意：客户端正在查看访问MySQL数据库的方式，通过命令行访问，命令行窗口是客户端，
在访问JDBC和其他连接之后，程序就是客户机。
当我们将中文数据写入MySQL时，我们必须为客户机、数据库连接和数据库将代码编码到数据库中。
改变
执行查询时，对结果、数据库连接和客户机的转换进行编码。
现在我们应该知道代码发生在一个或多个数据库、客户机、查询结果和数据库连接中。
一个链接
然后我们要解决这个问题。
当我们登录数据库时，我们使用MySQL——默认字符集=字符集- U - P连接，此时我们
使用显示变量如% char %，命令查看字符集设置，然后您可以找到客户端、数据库连接，
查询结果的字符集已在登录时设置为选定的字符集。
如果已经登录，则可以使用set字符集；该命令将执行相同的效果，相当于以下命令：
character_set_client =字符集设置
character_set_connection =字符集设置
character_set_results =字符集设置
如果通过JDBC连接到数据库，就可以用这种方式编写URL：
MySQL JDBC URL = / /：：本地：3306 / absuseunicode = truecharacterencoding =字符集
JSP页面和其他终端也应该设置相应的字符集。
数据库的字符集可以修改MySQL的启动配置来指定字符集，或者将其添加到创建数据库中。
默认字符集字符集，用于强制数据库字符集的设置。
通过这种设置，整个数据被写入读出过程，以统一字符集，并且代码不会出现。
你为什么不直接从命令行写中文，而不设置代码呢
很明显，客户机的字符集设置、数据库连接和查询结果不会从命令行更改。
输入中文经过一系列的代码转换，然后返回到初始字符集，我们可以看到它不是一个随机代码。
但这并不意味着中文被正确地存储在数据库中作为汉字库。
例如，现在有一个UTF8编码数据库，客户端的连接采用GBK编码，并使用默认的连接
上（即latin1 MySQL），我们将在客户端的中文字符串，客户端
GBK格式的字符串将被发送到连接层和连接层在iso8859-1格式。
The binary code is sent to the database, which is stored in utf8 format, and we use this field as utf8
读取格式，确定随机码，也就是说，当数据写入数据库时，中文数据以随机代码的形式存储。
当一个查询操作是在同一个客户进行的，一组是相反的写作行为，和错误的utf8格式是二进制。
代码转换成GBK编码正确，正确显示。