Список наборов символов 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 символом или его кодовым значением (шестнадцатеричным представлением). Например, из списка ucs2 кодировок и имён Unicode (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 (то есть, вопросительный знак, ?), мы знаем, что каждое преобразование прошло успешно.

Проблемы сортировки 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/.

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