CJK字符集的列表可能会根据您的MySQL版本有所不同。例如,gb18030MySQL 5.7.4之前不支持字符集。但是，由于适用语言的名称出现在描述的每个条目INFORMATION_SCHEMA。CHARACTER_SETS表，您可以使用此查询获得所有非unicode CJK字符集的当前列表:

SELECT CHARACTER_SET_NAME, DESCRIPTION FROM INFORMATION_SCHEMACHARACTER_SETSWHERE DESCRIPTION LIKE '%Chin%' OR DESCRIPTION LIKE '%Japanese%' OR DESCRIPTION LIKE '%Korean%' ORDER BY CHARACTER_SET_NAME; +--------------------+---------------------------------+ | CHARACTER_SET_NAME | DESCRIPTION | +--------------------+---------------------------------+ | big5 | Big5 Traditional Chinese | | cp932 | SJIS for Windows Japanese | | 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.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-specific UCA collation，gb18030_unicode_520_ci(这需要使用非unicodegb18030字符集)。

有关Unicode排序规则及其区别属性(包括补充字符的排序规则属性)的信息，请参见第10.10.1节，" Unicode字符集"．

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

MySQL支持在香港和台湾(中华民国)常见的Big5字符集。MySQL繁体字符集是在现实中的微软代码页950，这是非常相似的原始繁体字符集。

添加的特性请求HKSCS已申请延期。需要这个扩展的人可能会发现Bug #13577的建议补丁感兴趣。

MySQL支持sjis，里头，cp932,eucjpms字符集，以及Unicode。常见的需要是在字符集之间进行转换。例如，可能有一个Unix服务器(通常使用sjis或里头)和Windows客户端(通常使用cp932)．

在下面的转换表中ucs2列表示源，而sjis，cp932，里头,eucjpms列表示目的地;也就是说，当我们使用时，最后4列提供十六进制结果转换(ucs2)或者我们分配一个ucs2的值的列sjis，cp932，里头,或eucjpms列。

现在考虑表的下面部分。

这意味着MySQL转换没有信号(UnicodeU + 00交流)sjis代码点0 x81ca和cp932代码点3 f．（3 f是问号(”?”．当转换无法执行时，总是使用此选项。)

我们的回答是:”?”．这样做也有缺点，许多人宁愿选择a”宽松的”转换,因此81 ca(不签)在sjis就变成了81ca(全宽无符号)在cp932．

出现了一个问题，因为一些版本的日文字符集(都是sjis而且euc)治疗5度作为一个反斜线（＼，也被称为反斜杠)，而其他人将其视为日元符号(¥)．

MySQL只遵循一个版本的JIS(日本工业标准)标准描述。在MySQL中,5度总是反向的solidus (＼）．

理论上，虽然有几个版本的euckr（扩展Unix代码韩国)字符集，只有一个问题被注意到。我们使用”美国信息交换标准代码”变体eu - kr，其中代码点0 x5c是REVERSE SOLIDUS，是吗＼，而不是”KS-Roman”变体eu - kr，其中代码点0 x5c是赢得了标志（₩)．这意味着您不能转换UnicodeU + 20 a9来euckr：

mysql> SELECT CONVERT(‘创作支援体’USING euckr) AS euckr, HEX(CONVERT(创作支援体))AS hexeuckr;+-------+----------+ | euckr | hexeuckr  | +-------+----------+ | ?| 3f | +-------+----------+

要查看问题，请创建一个只有一个Unicode (ucs2)栏及一篇中文(gb2312)列。

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

在非严格SQL模式下，尝试放置罕见字符汌在这两个列。

设置sql_mode = ";INSERT INTO ch VALUES ('A汌B'，'A汌B');查询OK, 1行受影响，1警告(0.00秒)

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

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

所以这是一个关于gb2312只列。

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

这里有几点需要解释:

获取到服务器的直接连接mysql客户机，并在那里尝试相同的查询。如果mysql响应正确，问题可能是您的应用程序接口需要初始化。使用mysql告诉您在语句中使用了哪些字符集显示变量'char%';．如果您使用的是Access，那么您很可能使用Connector/ODBC进行连接。在这种情况下，您应该检查配置连接器/ ODBC．例如，你使用繁体，你会进入设置名称“繁体”．(在这种情况下，没有；字符是必需的。)如果您正在使用ASP，您可能需要添加组名称在代码中。下面是一个在过去行之有效的例子:

< %会话。CodePage=0 Dim Conn strConnection Dim Conn strConnection="driver={MySQL ODBC 3.51 driver}服务器; uid =用户名" \ & "pwd=密码;数据库=数据库=;支撑集的名字“繁体”;“设置Conn = Server.CreateObject("ADODB.Connection") Conn. open strConnection %>

同样，如果您使用任何字符集，而不是latin1使用Connector/NET时，必须在连接字符串中指定字符集。看到连接器/网络连接，以获取更多信息。

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

<？mysqli($host， $usr， $pwd， $db);如果(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,包括< meta http-equiv = " - type”内容= " text / html;charset = utf - 8”>在< >头部分的HTML页面。

如果您使用Connector/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>显示变量: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>显示变量:char%;+--------------------------+----------------------------------------+ | Variable_name |值  | +--------------------------+----------------------------------------+ | character_set_client | latin1 |中的一个| character_set_connection | latin1 |中的一个| character_set_database | latin1 |中的一个| character_set_filesystem二进制| | | 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字符集的非二进制字符串列类型。例如:文本字符集sjis．或者，在比较之前转换为CJK字符集。

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

为全文搜索，我们必须知道单词的开始和结束。在西方语言中，这几乎不是个问题，因为大多数(如果不是全部的话)都使用一个容易识别的词边界:空格字符。然而，这种情况在亚洲写作中并不常见。我们可以使用任意的折中措施，比如假设所有的汉字都代表单词，或者(对于日语)根据语法结尾从片假名到平假名的变化。然而，唯一可靠的解决方案需要一个全面的单词列表，这意味着我们必须在服务器中为支持的每种亚洲语言包括一个字典。这根本不可行。

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

DELIMITER // 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) CHARACTER SET gbk, sjis CHAR(1) CHARACTER SET sjis, ujis CHAR(1) CHARACTER SET 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)，我们知道片假名的角色体育出现在所有CJK字符集中，其代码值为30 X ' da”．如果我们使用这个值作为参数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  | +------+--------+------+-------+---------+-------+--------+------+------+------+

因为没有一个列值是3 f(即问号字符，?)，我们知道每次转换都有效。

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

CJK排序问题发生在旧的MySQL版本可以解决MySQL 8.0使用utf8mb4字符集和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网址 ．

可获得的资源如下: