A.11.1. | MySQL 中有哪些 CJK 字符集可用？ |
| CJK 字符集列表可能因 MySQL 版本而异。例如，gb18030 字符集在 MySQL 5.7.4 之前不受支持。但是，由于在 INFORMATION_SCHEMA.CHARACTER_SETS 表的每个条目中，适用的语言名称都显示在 DESCRIPTION 列中，您可以使用以下查询获取所有非 Unicode CJK 字符集的当前列表 mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION
FROM INFORMATION_SCHEMA.CHARACTER_SETS
WHERE 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 |
+--------------------+---------------------------------+
(有关更多信息，请参阅 第 28.3.4 节，“INFORMATION_SCHEMA CHARACTER_SETS 表”。) MySQL 支持在中国人民共和国官方使用的三种 GB (Guojia Biaozhun，或 国家标准，或 简体中文) 字符集变体：gb2312、gbk 和 (从 MySQL 5.7.4 开始) gb18030。 有时人们尝试将 gbk 字符插入 gb2312 中，大多数情况下它都能工作，因为 gbk 是 gb2312 的超集。但最终他们会尝试插入一个较罕见的汉字，这时它就无法工作了。(例如，请参阅 Bug #16072)。 在此，我们尝试根据官方文件明确说明 gb2312 或 gbk 中哪些字符是合法的。在报告 gb2312 或 gbk 错误之前，请检查这些参考资料
也可以在 Unicode 字符集中存储 CJK 字符，尽管可用的排序规则可能不会按照您的预期对字符进行排序
用于 Unicode 字符集的排序规则决定了对该字符集中字符进行排序 (即区分) 的能力
基于 Unicode 排序算法 (UCA) 4.0.0 的排序规则只区分 BMP 字符。 基于 UCA 5.2.0 或 9.0.0 的排序规则区分 BMP 和补充字符。 非 UCA 排序规则可能无法区分所有 Unicode 字符。例如，utf8mb4 的默认排序规则为 utf8mb4_general_ci，它只区分 BMP 字符。
此外，区分字符与按照给定 CJK 语言的约定对其进行排序并不相同。目前，MySQL 只有一个 CJK 特定的 UCA 排序规则，gb18030_unicode_520_ci (这需要使用非 Unicode gb18030 字符集)。 有关 Unicode 排序规则及其区分属性的信息，包括补充字符的排序规则属性，请参阅 第 12.10.1 节，“Unicode 字符集”。 |
A.11.2. | 我已将 CJK 字符插入到我的表中。为什么 SELECT 显示它们为 “?” 字符？ |
| 此问题通常是由于 MySQL 中的一个设置与应用程序程序或操作系统的设置不匹配。以下是纠正这些类型问题的常见步骤
确定您使用的 MySQL 版本.
使用语句 SELECT VERSION(); 确定这一点。
确保数据库实际使用的是所需的字符集.
人们经常认为客户端字符集始终与服务器字符集或用于显示目的的字符集相同。但是，这两个假设都是错误的。您可以通过检查 SHOW CREATE TABLE tablename 的结果来确保，或者更好的是，使用以下语句 SELECT character_set_name, collation_name
FROM information_schema.columns
WHERE table_schema = your_database_name
AND table_name = your_table_name
AND column_name = your_column_name;
确定未正确显示的字符或字符的十六进制值.
您可以使用以下查询获取表 table_name 中的列 column_name 的此信息 SELECT HEX(column_name)
FROM table_name;
3F 是 ? 字符的编码；这意味着 ? 是实际存储在列中的字符。这通常发生是因为将特定字符从您的客户端字符集转换为目标字符集时出现问题。
确保往返转换是可能的。当您选择 literal (或 _introducer hexadecimal-value) 时，您是否获得了 literal 作为结果?
例如，日语片假名字符 Pe (ペ') 存在于所有 CJK 字符集中，其代码点值为 (十六进制编码) 0x30da。要测试此字符的往返转换，请使用以下查询 SELECT 'ペ' AS `ペ`; /* or SELECT _ucs2 0x30da; */
如果结果也不是 ペ，则往返转换失败。 对于有关此类失败的错误报告，我们可能会要求您使用 SELECT HEX('ペ'); 进行后续操作。然后我们可以确定客户端编码是否正确。
确保问题不在于浏览器或其他应用程序，而在于 MySQL.
使用 mysql 客户端程序来完成此任务。如果 mysql 正确显示字符，但您的应用程序没有，则问题可能是由于系统设置造成的。 要确定您的设置，请使用 SHOW VARIABLES 语句，其输出应类似于此处显示的输出。 mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
这些是面向国际的客户端的典型字符集设置（注意使用了 utf8 Unicode），该客户端连接到西方的服务器（latin1 是西欧字符集）。 虽然 Unicode（通常是 Unix 上的 utf8 变体，Windows 上的 ucs2 变体）优于拉丁语，但它通常不是您的操作系统实用程序最支持的。许多 Windows 用户发现 Microsoft 字符集，例如 cp932（适用于日语 Windows），是合适的。 如果您无法控制服务器设置，并且您不知道您的底层计算机使用什么设置，请尝试更改为您所在国家/地区的通用字符集（euckr = 韩国；gb18030、gb2312 或 gbk = 中华人民共和国；big5 = 台湾；sjis、ujis、cp932 或 eucjpms = 日本；ucs2 或 utf8 = 任何地方）。通常，只需要更改客户端、连接和结果设置。 SET NAMES 语句会同时更改所有这三项设置。例如 SET NAMES 'big5';
设置正确后，您可以通过编辑 my.cnf 或 my.ini 来使其永久生效。例如，您可能需要添加如下所示的行 [mysqld]
character-set-server=big5
[client]
default-character-set=big5
您的应用程序中使用的 API 配置设置也可能存在问题；有关更多信息，请参阅 为什么我的 GUI 前端或浏览器无法正确显示 CJK 字符...?。
|
A.11.3. | 在使用 Big5 中文字符集时，我应该注意什么问题？ |
| MySQL 支持 Big5 字符集，该字符集在香港和台湾（中华民国）很常见。MySQL big5 字符集实际上是 Microsoft 代码页 950，它与原始的 big5 字符集非常相似。 已提交了添加 HKSCS 扩展的特性请求。需要此扩展的人员可能会发现错误 #13577 的建议补丁很有用。 |
A.11.4. | 为什么日语字符集转换失败？ |
| MySQL 支持 sjis、ujis、cp932 和 eucjpms 字符集，以及 Unicode。一个常见的需求是在字符集之间进行转换。例如，可能存在一个 Unix 服务器（通常使用 sjis 或 ujis）和一个 Windows 客户端（通常使用 cp932）。 在以下转换表中，ucs2 列表示源，sjis、cp932、ujis 和 eucjpms 列表示目标；也就是说，最后 4 列提供了使用 CONVERT(ucs2) 或将包含该值的 ucs2 列分配给 sjis、cp932、ujis 或 eucjpms 列时得到的十六进制结果。
现在考虑表的以下部分。
这意味着 MySQL 将 NOT SIGN（Unicode U+00AC）转换为 sjis 代码点 0x81CA 和 cp932 代码点 3F。（3F 是问号（“?”。当无法执行转换时，始终使用此符号）。 |
A.11.5. | 如果我想将 SJIS 81CA 转换为 cp932，该怎么办？ |
| 我们的答案是：““?””。这样做有一些弊端，许多人更喜欢““松散””转换，以便 sjis 中的 81CA (NOT SIGN) 成为 cp932 中的 81CA (FULLWIDTH NOT SIGN)。 |
A.11.6. | MySQL 如何表示日元（¥）符号？ |
| 出现问题是因为某些版本的日语字符集（sjis 和 euc）都将 5C 视为反斜杠（\，也称为反斜杠），而其他字符集则将其视为日元符号（¥）。 MySQL 仅遵循 JIS（日本工业标准）标准描述的一个版本。在 MySQL 中，5C 始终是反斜杠（\）. |
A.11.7. | 在 MySQL 中使用韩语字符集时，我应该注意什么问题？ |
| 从理论上讲，虽然 euckr（扩展 Unix 代码韩国）字符集有多个版本，但只注意到一个问题。我们使用 EUC-KR 的““ASCII””变体，其中代码点 0x5c 是 REVERSE SOLIDUS，即 \，而不是 EUC-KR 的““KS-Roman””变体，其中代码点 0x5c 是 WON SIGN（₩）。这意味着您无法将 Unicode U+20A9 转换为 euckr mysql> SELECT
CONVERT('₩' USING euckr) AS euckr,
HEX(CONVERT('₩' USING euckr)) AS hexeuckr;
+-------+----------+
| euckr | hexeuckr |
+-------+----------+
| ? | 3F |
+-------+----------+
|
A.11.8. | 为什么我会收到 Incorrect string value 错误消息？ |
| 要查看问题，请创建一个包含一个 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> INSERT INTO ch VALUES ('A汌B','A汌B');
Query OK, 1 row affected, 1 warning (0.00 sec)
INSERT 会产生警告。使用以下语句查看它是哪一个
mysql> SHOW WARNINGS\G
*************************** 1. row ***************************
Level: Warning
Code: 1366
Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 1
因此，它仅针对 gb2312 列发出警告。 mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;
+-------+--------------+--------+-------------+
| ucs2 | HEX(ucs2) | gb2312 | HEX(gb2312) |
+-------+--------------+--------+-------------+
| A汌B | 00416C4C0042 | A?B | 413F42 |
+-------+--------------+--------+-------------+
这里需要解释几件事
汌 字符不在 gb2312 字符集中，如前所述。
如果您使用的是旧版本的 MySQL，您可能会看到不同的消息。 出现警告而不是错误是因为 MySQL 未设置为使用严格的 SQL 模式。在非严格模式下，MySQL 会尽力做到最好，而不是放弃。在严格的 SQL 模式下，Incorrect string value 消息将作为错误而不是警告出现，并且 INSERT 失败。
|
A.11.9. | 为什么我的 GUI 前端或浏览器在我的应用程序中使用 Access、PHP 或其他 API 时无法正确显示 CJK 字符？ |
| 使用 mysql 客户端直接连接到服务器，并在那里尝试相同的查询。如果 mysql 响应正确，则问题可能是您的应用程序界面需要初始化。使用 mysql 来告知您它使用什么字符集，并使用语句 SHOW VARIABLES LIKE 'char%';。如果您使用的是 Access，则很可能使用 Connector/ODBC 连接。在这种情况下，您应该检查 配置 Connector/ODBC。例如，如果您使用 big5，则应输入 SET NAMES 'big5'。（在这种情况下，不需要 ; 字符。）如果您使用的是 ASP，则可能需要在代码中添加 SET NAMES。以下是一个在过去有效的示例 <%
Session.CodePage=0
Dim strConnection
Dim Conn
strConnection="driver={MySQL ODBC 3.51 Driver};server=server;uid=username;" \
& "pwd=password;database=database;stmt=SET NAMES 'big5';"
Set Conn = Server.CreateObject("ADODB.Connection")
Conn.Open strConnection
%>
同样，如果您使用的是 Connector/NET，并且使用的是 latin1 以外的任何字符集，则必须在连接字符串中指定字符集。有关更多信息，请参阅 Connector/NET 连接。 如果您使用的是 PHP，请尝试以下操作 <?php
$link = new mysqli($host, $usr, $pwd, $db);
if( mysqli_connect_errno() )
{
printf("Connect failed: %s\n", mysqli_connect_error());
exit();
}
$link->query("SET NAMES 'utf8'");
?>
在这种情况下，我们使用 SET NAMES 来更改 character_set_client、character_set_connection 和 character_set_results 系统变量。 在 PHP 应用程序中经常遇到的另一个问题与浏览器所做的假设有关。有时添加或更改 <meta> 标记足以解决问题：例如，为了确保用户代理将页面内容解释为 UTF-8，请在 HTML 页面的 <head> 部分中包含 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">。 如果您使用的是 Connector/J，请参阅 使用字符集和 Unicode。 |
A.11.10. | 我已经升级到 MySQL 9.0。如何恢复到 MySQL 4.0 中与字符集相关的行为？ |
| 在 MySQL 4.0 版中，服务器和客户端都使用一个““全局””字符集，并且服务器管理员决定使用哪个字符集。从 MySQL 4.1 版开始，这种情况发生了变化。现在发生的是““握手””，如 第 12.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。进一步假设客户端使用 utf8，因为这是客户端操作系统支持的。使用 latin1 作为默认字符集启动服务器 mysqld --character-set-server=latin1
然后使用默认字符集 utf8 启动客户端 mysql --default-character-set=utf8
可以通过查看 SHOW VARIABLES 的输出结果来查看最终设置 mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+----------------------------------------+
| Variable_name | Value |
+--------------------------+----------------------------------------+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| 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
再次使用 utf8 作为默认字符集启动客户端，然后显示最终设置 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/local/mysql/share/mysql/charsets/ |
+--------------------------+----------------------------------------+
正如您通过比较 SHOW VARIABLES 中的不同结果所看到的那样，如果使用 --skip-character-set-client-handshake 选项，服务器会忽略客户端的初始设置。 |
A.11.11. | 为什么有些使用 CJK 字符的 LIKE 和 FULLTEXT 搜索会失败？ |
| 对于 LIKE 搜索，二进制字符串列类型（如 BINARY 和 BLOB）存在一个非常简单的问题：我们必须知道字符在哪里结束。对于多字节字符集，不同的字符可能具有不同的字节长度。例如，在 utf8 中，A 需要一个字节，但 ペ 需要三个字节，如下所示 +-------------------------+---------------------------+
| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |
+-------------------------+---------------------------+
| 1 | 3 |
+-------------------------+---------------------------+
如果我们不知道字符串中第一个字符在哪里结束，我们就不知道第二个字符从哪里开始，在这种情况下，即使是非常简单的搜索（如 LIKE '_A%'）也会失败。解决方案是使用非二进制字符串列类型，该类型定义为具有正确的 CJK 字符集。例如：mycol TEXT CHARACTER SET sjis。或者，在比较之前转换为 CJK 字符集。 这就是 MySQL 无法允许对不存在的字符进行编码的原因之一。如果它对拒绝错误输入不严格，它就无法知道字符在哪里结束。 对于 FULLTEXT 搜索，我们必须知道单词从哪里开始和结束。对于西方语言，这很少是一个问题，因为大多数（如果不是全部）这些语言使用易于识别的词边界：空格字符。然而，对于亚洲文字来说，情况通常并非如此。我们可以使用任意的一半措施，比如假设所有汉字都代表单词，或者（对于日语）取决于由于语法结尾而从片假名到平假名的变化。但是，唯一可靠的解决方案需要一个全面的词表，这意味着我们必须在服务器中为支持的每种亚洲语言包含一个字典。这根本不可行。 |
A.11.12. | 我怎么知道字符 X 是否在所有字符集中都可用？ |
| 大多数简体中文和基本非半角日语片假名字符出现在所有 CJK 字符集中。以下存储过程接受一个 UCS-2 Unicode 字符，将其转换为其他字符集，并以十六进制显示结果。 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;
/* If there are conversion problems, UPDATE produces warnings. */
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;
DROP TABLE tj;
END//
DELIMITER ;
输入可以是任何单个 ucs2 字符，也可以是该字符的代码值（十六进制表示）。例如，从 Unicode 的 ucs2 编码和名称列表 (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt) 中，我们知道片假名字符 Pe 出现在所有 CJK 字符集中，其代码值为 X'30DA'。如果我们将此值用作 p_convert() 的参数，则结果如下所示 mysql> CALL p_convert(X'30DA');
+------+--------+------+-------+---------+-------+--------+------+------+------+
| ucs2 | utf8 | big5 | cp932 | eucjpms | euckr | gb2312 | gbk | sjis | ujis |
+------+--------+------+-------+---------+-------+--------+------+------+------+
| 30DA | E3839A | C772 | 8379 | A5DA | ABDA | A5DA | A5DA | 8379 | A5DA |
+------+--------+------+-------+---------+-------+--------+------+------+------+
由于所有列值都不是 3F（即问号字符，?），因此我们知道每个转换都成功了。 |
A.11.13. | 为什么 CJK 字符串在 Unicode 中排序不正确？(I) |
| 从 MySQL 8.0 开始，可以使用 utf8mb4 字符集和 utf8mb4_ja_0900_as_cs 排序规则来解决旧版 MySQL 版本中出现的 CJK 排序问题。 |
A.11.14. | 为什么 CJK 字符串在 Unicode 中排序不正确？(II) |
| 从 MySQL 8.0 开始，可以使用 utf8mb4 字符集和 utf8mb4_ja_0900_as_cs 排序规则来解决旧版 MySQL 版本中出现的 CJK 排序问题。 |
A.11.15. | 为什么我的辅助字符被 MySQL 拒绝？ |
| 辅助字符位于 Unicode 基本多语言平面 / 平面 0 之外。BMP 字符的代码点值介于 U+0000 和 U+FFFF 之间。辅助字符的代码点值介于 U+10000 和 U+10FFFF 之间。 要存储辅助字符，您必须使用允许它们的字符集
utf8 和 ucs2 字符集仅支持 BMP 字符。
utf8 字符集仅允许占用最多三个字节的 UTF-8 字符。这导致了诸如 Bug #12600 中发现的报告，我们将其拒绝为 “不是错误”。对于 utf8，当 MySQL 遇到它不理解的字节时，它必须截断输入字符串。否则，就不知道错误的多字节字符有多长。
一种可能的解决方法是使用 ucs2 而不是 utf8，在这种情况下，“错误” 字符将被更改为问号。但是，不会发生截断。您还可以将数据类型更改为 BLOB 或 BINARY，它们不执行有效性检查。 utf8mb4、utf16、utf16le 和 utf32 字符集支持 BMP 字符，以及 BMP 之外的辅助字符。
|
A.11.16. | “CJK” 应该改成 “CJKV” 吗？ |
| 不。术语 “CJKV” (中日韩越) 指的是包含汉字（最初为汉字）的越南字符集。MySQL 支持使用西文字符的现代越南语脚本，但不支持使用汉字的旧越南语脚本。 从 MySQL 5.6 开始，Unicode 字符集有越南语排序规则，如 第 12.10.1 节，“Unicode 字符集” 中所述。 |
A.11.17. | MySQL 是否允许在数据库和表名中使用 CJK 字符？ |
| 是的。 |
A.11.18. | 在哪里可以找到 MySQL 手册的中文、日语和韩语翻译？ |
| 可以在 https://dev.mysqlserver.cn/doc/ 下载 MySQL 5.6 手册的日语翻译。 |
A.11.19. | 在哪里可以获得有关 MySQL 中的 CJK 及相关问题的帮助？ |
| 以下资源可用
|