Список наборов символов CJK может варьироваться в зависимости от версии MySQL. Например, набор символов gb18030 не поддерживается в версиях MySQL до 5.7.4. Однако, поскольку имя соответствующего языка указано в столбце DESCRIPTION для каждой записи в таблице INFORMATION_SCHEMA.CHARACTER_SETS, вы можете получить текущий список всех наборов символов CJK, не являющихся Unicode, используя этот запрос:

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. Но в конечном итоге они пытаются вставить более редкий китайский символ, и это не работает. (Для примера см. баг #16072).

Здесь мы пытаемся уточнить, какие именно символы являются допустимыми в gb2312 или gbk, ссылаясь на официальные документы. Пожалуйста, проверьте эти ссылки перед сообщением о багах gb2312 или gbk:

Также возможно хранить символы CJK в наборах символов Unicode, хотя доступные сортировки могут не сортировать символы так, как вы ожидаете:

Используемая сортировка для набора символов Unicode определяет возможность сортировки (т. е. различения) символов в наборе:

Кроме того, различение символов не равнозначно их упорядочению в соответствии с обычаями данного языка CJK. В настоящее время MySQL имеет только одну сортировку UCA, специфичную для CJK, gb18030_unicode_520_ci (которая требует использования набора символов не-Unicode gb18030).

Сведения о сортировках Unicode и их различительных свойствах, включая свойства сортировки дополнительных символов, см. в Разделе 12.10.1, «Наборы символов Unicode».

Эта проблема обычно связана с настройкой MySQL, которая не соответствует настройкам приложения или операционной системы. Вот некоторые распространённые шаги для исправления таких проблем:

MySQL поддерживает кодировку символов Big5, которая распространена в Гонконге и Тайване (Китайская Республика). Кодировка символов MySQL big5 фактически представляет собой кодовую страницу Microsoft 950, которая очень похожа на исходную big5 кодировку.

Заявка на добавление расширений HKSCS была подана. Пользователи, которым нужно это расширение, могут найти предложенное исправление для ошибки #13577.

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 — это знак вопроса (“?”. Он всегда используется, когда преобразование выполнить невозможно.)

Наш ответ: “?”. Это имеет недостатки, и многие предпочли бы «мягкое» преобразование, так что 81CA (NOT SIGN) в sjis станет 81CA (FULLWIDTH NOT SIGN) в cp932.

Возникает проблема, потому что некоторые версии японских кодировок (как sjis, так и euc) рассматривают 5C как обратный слэш (обратный слэш — \), в то время как другие рассматривают его как знак иены (¥).

MySQL следует только одному варианту описания стандарта JIS (Японские промышленные стандарты). В MySQL, 5C всегда представляет собой обратный слэш (\).

Теоретически, хотя было несколько версий кодировки euckr (Расширенный кодовый стандарт Unix для Кореи), была отмечена только одна проблема. Мы используем вариант EUC-KR «ASCII», в котором кодовый символ 0x5c равен ОБРАТНОМУ СЛЕШУ, то есть \, а не вариант 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       |
+-------+----------+

Чтобы увидеть проблему, создайте таблицу с одним столбцом Unicode (ucs2) и одним столбцом китайских символов (gb2312).

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

В режиме SQL без ограничений (nonstrict) попробуйте поместить редкий символ 汌 в оба столбца.

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      |
+-------+--------------+--------+-------------+

Здесь нужно объяснить несколько моментов:

Получите прямое подключение к серверу с помощью клиента mysql и попробуйте тот же запрос там. Если mysql отвечает правильно, проблема может быть в том, что интерфейсу вашего приложения требуется инициализация. Используйте mysql, чтобы узнать, какой набор символов или наборы символов он использует с помощью оператора SHOW VARIABLES LIKE 'char%';. Если вы используете Access, вы, скорее всего, подключаетесь с помощью 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
%>

Аналогичным образом, если вы используете любой другой набор символов, кроме 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, включите <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> в секцию <head> HTML-страницы.

Если вы используете Connector/J, см. .

В MySQL версии 4.0 существовал единый “глобальный” набор символов для сервера и клиента, и решение о том, какой набор символов использовать, принималось администратором сервера. Это изменилось, начиная с MySQL версии 4.1. Теперь происходит «рукопожатие», как описано в Разделе 12.4, «Наборы символов и наборы сопоставлений соединений»:

Это означает, что вы не можете управлять набором символов клиента, запуская mysqld с --character-set-server=utf8. Однако некоторые азиатские клиенты предпочитают поведение MySQL 4.0. Для сохранения этого поведения мы добавили переключатель mysqld, , который можно отключить с помощью . Если вы запустите mysqld с , то при подключении клиента он отправляет серверу имя набора символов, который он хочет использовать. Однако сервер игнорирует этот запрос от клиента.

Например, предположим, что ваш любимый набор символов сервера — 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, сервер игнорирует начальные настройки клиента, если используется опция .

Для поисков 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 поисков мы должны знать, где начинаются и заканчиваются слова. В западных языках это редко проблема, поскольку большинство (если не все) из них используют легко определяемый разделитель слов: пробел. Однако это обычно не так в азиатских системах письма. Мы могли бы использовать произвольные временные решения, например, предполагая, что все иероглифы представляют слова, или (для японского) полагаться на изменения от катаканы к хирагане из-за грамматических окончаний. Однако единственное надёжное решение требует полного списка слов, что означает, что нам пришлось бы включить словарь в сервер для каждого азиатского языка, поддерживаемого. Это просто нецелесообразно.

Большинство упрощенных китайских и основных японских символов катакана без полных знаков появляются во всех наборах символов CJK. Следующая хранимая процедура принимает символ Unicode UCS-2, преобразует его в другие наборы символов и отображает результаты в шестнадцатеричном формате.

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 (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt) мы знаем, что символ катаканы Пе появляется во всех наборах символов 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 (то есть символу вопроса, ?), мы знаем, что каждое преобразование прошло успешно.

Проблемы сортировки 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+FFFF. Дополнительные символы имеют значения кодовых точек между U+10000 и U+10FFFF.

Для хранения дополнительных символов необходимо использовать кодировку символов, которая их поддерживает:

Нет. Термин “CJKV” (Китайский Японский Корейский Вьетнамский) относится к вьетнамским наборам символов, которые содержат иероглифы (первоначально китайские). MySQL поддерживает современный вьетнамский алфавит с латинскими символами, но не поддерживает старый вьетнамский алфавит, использующий иероглифы.

Начиная с MySQL 5.6, существуют вьетнамские наборы правил для наборов символов Unicode, как описано в Разделе 12.10.1, “Наборы символов Unicode”.

Да.

Японский перевод руководства MySQL 5.6 можно загрузить с https://dev.mysql.com/doc/.

Доступны следующие ресурсы: