CJK字符集的列表可能会根据你的MySQL版本而有所不同。例如,GB18030MySQL 5.7.4之前不支持字符集。但是，由于适用语言的名称出现在描述中的每个条目Information_schema.Character_sets.表，您可以使用此查询获取所有非Unicode CJK字符集的当前列表：

MySQL>选择字符_set_name，从Information_schema.Character_Sets的描述，其中描述类似于'％chin％'或design等'％日语％'或descriptions'％韩语％'订单）by字符_set_name;+ -------------------------------------------------------- + |character_set_name |描述|+ -------------------------------------------------------- + |big5 |Big5繁体中文||CP932 |SJIS for Windows日语| | eucjpms | UJIS for Windows Japanese | | euckr | EUC-KR Korean | | gb18030 | China National Standard GB18030 | | gb2312 | GB2312 Simplified Chinese | | gbk | GBK Simplified Chinese | | sjis | Shift-JIS Japanese | | ujis | EUC-JP Japanese | +--------------------+---------------------------------+

（有关更多信息，请参阅第26.3.4节“Information_schema character_sets表”．）

MySQL支持三种变体的GB（国家标准， 或者国家标准， 或者简体中文）中华人民共和国官员的人物集：GB2312.，gbk，以及(从MySQL 5.7.4起)GB18030．

有时人们试图插入gbk字符GB2312.，它大部分时间都能奏效，因为gbk是超集吗GB2312.．但最终他们试图插入一个更罕见的汉字，但没有成功。(例如，参见Bug #16072)。

在这里，我们试图澄清究竟是字符是合法的GB2312.或者gbk，参阅官方文件。请在报告前检查这些参考资料GB2312.或者gbk虫子：

也可以将CJK字符存储在Unicode字符集中，尽管可用的排序组可能无法按预期排序字符：

用于Unicode字符集的排序规则决定了对字符集中的字符进行排序(即区分)的能力:

此外，区分字符并不等同于按照给定的CJK语言的约定对它们进行排序。目前，MySQL只有一个特定于cjk的UCA排序，gb18030_unicode_520_ci(这需要使用非unicodeGB18030字符集)。

有关Unicode Collat​​ion的信息及其差异化属性，包括用于补充字符的整理属性，请参阅第10.10.1节，" Unicode字符集"．

此问题通常是由于MySQL中的设置与应用程序或操作系统的设置不匹配。以下是纠正这些类型的问题的一些常见步骤：

MySQL支持在香港和台湾(中华民国)常见的Big5字符集。MySQL繁体字符集实际上是Microsoft代码页950，它与原始类似繁体字符集。

添加功能请求HKSCS已提交扩展名。需要这个扩展的人可能会发现Bug #13577的建议补丁感兴趣。

MySQL支持SJIS.，UJIS.，cp932， 和eucjpms.字符集，以及Unicode。一个常见的需求是在字符集之间进行转换。例如，可能有一个Unix服务器(通常带有SJIS.或者UJIS.)和Windows客户机(通常使用cp932）.

在下面的转换表中ucs2列表示源，而SJIS.，cp932，UJIS.， 和eucjpms.列表示目的地;也就是说，当我们使用时，最后4列提供十六进制结果转换（UCS2）或者我们分配一个ucs2的值所在的列SJIS.，cp932，UJIS.， 或者eucjpms.列。

现在考虑表的下面部分。

这意味着MySQL转换不迹象(Unicode你+00ac.） 至SJIS.代码点0 x81ca并cp932代码点3F.．（3F.是问号吗?”？”．当转换无法执行时，总是使用此方法。)

我们的答案是：”？”．这样做也有缺点，许多人更倾向于”宽松的”转换,因此81 ca(不签)在SJIS.成为81ca(宽非符号)在cp932．

一个问题出现了，因为一些版本的日文字符集(两者SJIS.和euc.)治疗5C作为一个逆转固定（＼，也称为反斜杠)，而其他人将其视为日元符号(¥）.

MySQL仅遵循JIS（日本工业标准）标准描述的一个版本。在mysql，5C总是反向固相线(＼）．

理论上，虽然有几个版本的euckr（扩展Unix代码韩国)字符集，只有一个问题被注意到。我们使用”美国信息交换标准代码”eucl - kr的变体，其中编码点0 x5c是反向固体，即＼，而不是”ks-rooman.”eucl - kr的变体，其中编码点0 x5c是赢得了标志（₩）.这意味着您不能转换UnicodeU + 20A9.至euckr：

mysql> SELECT('₩' USING euckr) AS euckr, HEX(CONVERT('₩' USING euckr)) AS hexeuckr;+-------+----------+ | euckr | hexeuckr  | +-------+----------+ | ?| 3f | +-------+----------+

要查看问题，请创建一个unicode的表（ucs2）列和一个中文（GB2312.)列。

mysql> CREATE TABLE ch (ucs2 CHAR(3) CHARACTER SET ucs2, gb2312 CHAR(3) CHARACTER SET gb2312);

在非推动的SQL模式下，尝试放置稀有性格汌在这两个列。

mysql> SET sql_mode = ";mysql >插入ch值(汌B, A汌B);查询OK, 1行受影响，1个警告(0.00秒)

的插入会产生一个警告。用下面的语句看看它是什么:

mysql > \ G显示警告  *************************** 1。行***************************级别:警告代码:1366消息:错误的字符串值:'gb2312'第1行列'gb2312'的'\xE6\xB1\x8CB'

所以这是对GB2312.只列。

mysql> SELECT ucs2,HEX(ucs2)，gb2312,HEX(gb2312) FROM ch;+-------+--------------+--------+-------------+ | ucs2 |十六进制(ucs2) | gb2312 |十六进制(gb2312 ) | +-------+--------------+--------+-------------+ | A汌| 00416 c4c0042 | ?B | 413 f42  | +-------+--------------+--------+-------------+

这里需要解释几件事:

获取到服务器的直接连接mysql.然后在那里尝试相同的查询。如果mysql.响应正确，问题可能是您的应用程序接口需要初始化。使用mysql.告诉您它在语句中使用的字符集或字符集显示变量'char%';．如果您正在使用Access，则最可能与连接器/ ODBC连接。在这种情况下，您应该检查配置连接器/ ODBC．例如，如果您使用繁体，你就会进入设置名称“繁体”．（在这种情况下，没有；字符是必需的。)如果你正在使用ASP，你可能需要添加设置名称在代码中。这里有一个在过去奏效的例子:

<％session.codepage = 0 dim strconnection dim conn strconnection =“driver = {mysql odbc 3.51驱动程序}; server =服务器; uid =用户名;" \ & "pwd=密码;数据库=数据库; stmt = set名称'big5';“set conn = server.createobject（”adodb.connection“）conn.open strconnection％>

同理，如果你使用的字符集不是latin1使用连接器/网络，您必须在连接字符串中指定设置的字符。看连接器/网络连接，以获取更多信息。

如果你正在使用PHP，试试这个:

<？PHP $link = new mysqli($host， $usr， $pwd， $db);if(mysqli_connect_errno()) {printf("连接失败:%s\n"， mysqli_connect_error());退出();} $link->查询("SET NAMES 'utf8'");? >

在这种情况下，我们使用设置名称改变character_set_client，character_set_connection， 和character_set_results．

PHP应用程序中经常遇到的另一个问题与浏览器做出的假设有关。有时添加或改变a< meta >标记足以纠正这个问题:例如，确保用户代理将页面内容解释为UTF-8.,包括在<头>HTML页面的一部分。

如果您使用的是连接器/ j，请参阅使用字符集和Unicode．

在MySQL版本4.0中，有一个单身”全球的”服务器和客户机的字符集，以及使用哪个字符的决定由服务器管理员决定。从MySQL 4.1版开始，这种情况就改变了。现在发生的是”握手”，如第10.4节，“连接字符集和排序规则”：

这的效果是您无法通过启动来控制客户端字符集mysqld与——character-set-server = utf8．然而，一些亚洲客户更喜欢MySQL 4.0的行为。为了保持这种行为，我们添加了一个mysqld开关,——character-set-client-handshake，可以用——skip-character-set-client-handshake．如果你开始mysqld与——skip-character-set-client-handshake，然后，当客户端连接时，它向服务器发送它想要使用的字符集的名称。然而,服务器将忽略来自客户端的这个请求．

举例来说，假设您最喜欢的服务器字符集是latin1．进一步假设客户使用use utf8因为这是客户端操作系统所支持的。使用以下命令启动服务器latin1默认字符集:

mysqld——character-set-server = latin1。中的一个

然后使用默认字符集启动客户端use utf8：

mysql——default-character-set = utf8

的输出可以看到结果设置显示变量：

mysql> SHOW VARIABLES LIKE 'char%';+--------------------------+----------------------------------------+ | Variable_name |值  | +--------------------------+----------------------------------------+ | character_set_client | utf8 | | character_set_connection | utf8 | | character_set_database | latin1 |中的一个| character_set_filesystem二进制| | | character_set_results | utf8 | |character_set_server | latin1 |中的一个| character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets / | +--------------------------+----------------------------------------+

现在停止客户端，并停止服务器使用mysqladmin．然后再次启动服务器，但这次告诉它跳过握手，如下所示:

mysqld——character-set-server = utf8 skip-character-set-client-handshake

启动客户use utf8再次作为默认字符集，然后显示结果设置:

mysql> SHOW VARIABLES LIKE 'char%';+ -------------------------------------------------------------------------------- + |变量_name |价值|+ -------------------------------------------------------------------------------- + |character_set_client |拉丁文1 ||character_set_connection |拉丁文1 | | character_set_database | latin1 | | character_set_filesystem | binary | | character_set_results | latin1 | | character_set_server | latin1 | | character_set_system | utf8 | | character_sets_dir | /usr/local/mysql/share/mysql/charsets/ | +--------------------------+----------------------------------------+

正如你所看到的，比较不同的结果显示变量，服务器忽略客户端的初始设置如果——skip-character-set-client-handshake选择使用。

为就像对于二进制字符串列类型，有一个非常简单的问题，例如二进制和团我们必须知道字符的尽头在哪里。对于多字节字符集，不同的字符可能有不同的八字节长度。例如,在use utf8，一个需要一个字节，但是ペ需要三个字节，如下所示:

+ ---------------------------------------------- + |Octet_Length（_Utf8'A'）|Octet_Length（_utf8'ペ​​'）|+ ---------------------------------------------- + |1 |3 |+ ---------------------------------------------- +

如果不知道字符串中的第一个字符在哪里结束，就不知道第二个字符在哪里开始，在这种情况下，即使是非常简单的搜索，如像“_A %”失败。解决方案是使用定义为具有合适的CJK字符集的非二进制字符串列类型。例如:mycol文本字符集sjis．或者，在比较之前转换为CJK字符集。

这就是为什么MySQL不允许对不存在的字符进行编码的原因之一。如果它不严格地拒绝错误输入，它就无法知道字符在哪里结束。

为全文搜索，我们必须知道单词开始和结束的地方。用西方语言，这很少是一个问题，因为大多数（如果不是全部）这些都使用易于识别的单词边界：空间字符。但是，这通常不是亚洲写作的情况。我们可以使用任意半行措施，如假设所有汉字代表单词，或（对于日语），根据语言结局由于Katakana到平假名的变化。但是，唯一确定的解决方案需要一个全面的单词列表，这意味着我们必须在支持的每个亚洲语言中包含服务器中的字典。这根本就是不可行的。

大部分简体中文和基本非半宽日文假名出现在所有的CJK字符集中。下面的存储过程接受ucs - 2字符，将其转换为其他字符集，并以十六进制显示结果。

CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2) BEGIN CREATE TABLE tj (ucs2 CHAR(1) CHARACTER SET ucs2, utf8 CHAR(1) CHARACTER SET utf8, big5 CHAR(1) CHARACTER SET big5, cp932 CHAR(1) CHARACTER SET cp932, eucjpms CHAR(1) CHARACTER SET eucjpms, euckr CHAR(1) CHARACTER SET euckr, gb2312 CHAR(1) CHARACTER SET gb2312，gbk CHAR(1)字符集gbk, sjis CHAR(1)字符集sjis, ujis CHAR(1)字符集ujis;INSERT INTO tj (ucs2) VALUES (ucs2_char);UPDATE tj SET utf8=ucs2, big5=ucs2, cp932=ucs2, eucjpms=ucs2, euckr=ucs2, gb2312=ucs2, gbk=ucs2, sjis=ucs2, ujis=ucs2;/*如果有转换问题，UPDATE会产生警告。*/ SELECT hex(ucs2) AS ucs2, hex(utf8) AS utf8, hex(big5) AS big5, hex(cp932) AS cp932, hex(eucjpms) AS eucjpms, hex(euckr) AS euckr, hex(gb2312) AS gb2312, hex(gbk) AS gbk, hex(sjis) AS sjis, hex(ujis) AS ujis FROM tj;删除表tj;/ /分隔符;

输入可以是任何单个ucs2字符，或者它可以是该字符的代码值（十六进制表示）。例如，来自Unicode的列表ucs2编码及名称(http://www.unicode.org/Public/UNIDATA/UnicodeData.txt)，我们知道片假名的角色PE.在所有CJK字符集中出现，其编码值为X'30DA'．如果我们将此值用作参数p_convert（），结果如下所示:

mysql >调用p_convert (X 30 da);+------+--------+------+-------+---------+-------+--------+------+------+------+ | ucs2 | utf8 |繁体| cp932 | eucjpms | euckr | gb2312 | gbk | sjis |里头  | +------+--------+------+-------+---------+-------+--------+------+------+------+ | 30 da | E3839A | C772 | 8379 | A5DA为副| | A5DA | A5DA | 8379 | A5DA |+------+--------+------+-------+---------+-------+--------+------+------+------+

因为没有列值是3F.（即问号角色，？），我们知道每个转换都有工作。

CJK对旧MySQL版本发生的问题可以通过使用MySQL 8.0来解决MySQL 8.0utf8mb4字符集和utf8mb4_ja_0900_as_cs排序。

CJK对旧MySQL版本发生的问题可以通过使用MySQL 8.0来解决MySQL 8.0utf8mb4字符集和utf8mb4_ja_0900_as_cs排序。

补充字符在Unicode之外基本多语言平面/平面0．BMP字符之间有代码点值U + 0000和U +飞行符．补充字符之间有代码点值U + 10000.和U + 10飞行符．

要存储补充字符，必须使用允许它们的字符集：

不。这个术语”CJKV”（中国日本韩国越南语)是指包含汉族字符的越南字符集。MySQL支持西文的现代越南脚本，但不支持使用汉文的旧越南脚本。

在MySQL 5.6中，有针对Unicode字符集的越南排序规则，如第10.10.1节，" Unicode字符集"．

是的。

MySQL 5.6手册的日文翻译可以从10bet网址 ．

可供使用的资源如下: