Этот набор Часто Задаваемых Вопросов получает из опыта групп Поддержки и Разработки MySQL в обработке многих запросов о CJK (китайско-японско-корейские) проблемы.

Вопросы

Вопросы и Ответы

B.11.1: Какие наборы символов CJK доступны в MySQL?

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

mysql> SELECT CHARACTER_SET_NAME, DESCRIPTION    -> FROM INFORMATION_SCHEMA.CHARACTER_SETS    -> WHERE DESCRIPTION LIKE '%Chinese%'    -> 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             || gb2312             | GB2312 Simplified Chinese || gbk                | GBK Simplified Chinese    || sjis               | Shift-JIS Japanese        || ujis               | EUC-JP Japanese           |+--------------------+---------------------------+8 rows in set (0.01 sec)

(См. Раздел 19.1," INFORMATION_SCHEMA CHARACTER_SETS Таблица", для получения дополнительной информации.)

MySQL поддерживает две общих разновидности Гбайт (Guojia Biaozhun, или Национальный Стандарт, или Упрощенный китайский) наборы символов, которые официальны в Китайской Народной Республике: gb2312 и gbk. Иногда люди пытаются вставить gbk символы в gb2312, и это работает большую часть времени потому что gbk надмножество gb2312— но в конечном счете они пытаются вставить более редкий китайский символ, и он не работает. (См. Ошибку #16072 для примера).

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

B.11.2: Я вставил символы CJK в свою таблицу. Почему делает SELECT выведите на экран их как"?" символы?

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

B.11.3: О каких проблемах я должен знать, работая с китайским набором символов Big5?

MySQL поддерживает набор символов Big5, который распространен в Гонконге и Тайване (республика Китая). MySQL big5 в действительности кодовая страница 950 Microsoft, которая очень подобна оригиналу big5 набор символов. Мы изменились на этот набор символов, запускающийся с версии 4.1.16 / 5.0.16 MySQL (в результате Ошибки #12476). Например, следующие операторы работают в текущих версиях MySQL, но не в старых версиях:

mysql> CREATE TABLE big5 (BIG5 CHAR(1) CHARACTER SET
        BIG5);Query OK, 0 rows affected (0.13 sec)mysql> INSERT INTO
        big5 VALUES (0xf9dc);Query OK, 1 row affected (0.00 sec)mysql> SELECT * FROM big5;+------+| big5 |+------+| 嫺  |+------+1 row in set (0.02 sec)

Запрос новых функций для того, чтобы добавить HKSCS расширения были зарегистрированы. Люди, которые нуждаются в этом расширении, могут найти, что предложенный патч для Ошибки #13577 представляет интерес.

B.11.4: Почему японские преобразования набора символов перестали работать?

MySQL поддерживает sjis, ujis, cp932, и eucjpms наборы символов, так же как Unicode. Общая потребность состоит в том, чтобы преобразовать между наборами символов. Например, мог бы быть сервер Unix (обычно с sjis или ujis) и клиент Windows (обычно с cp932).

В следующей таблице преобразования, ucs2 столбец представляет источник, и sjis, cp932, ujis, и eucjpms столбцы представляют места назначения — то есть, последние 4 столбца обеспечивают шестнадцатеричный результат, когда мы используем CONVERT(ucs2) или мы присваиваем a ucs2 столбец, содержащий значение к sjis, cp932, ujis, или eucjpms столбец.

Теперь рассмотрите следующую часть таблицы.

Это означает, что MySQL преобразовывает NOT SIGN (Unicode U+00AC) к sjis кодовая точка 0x81CA и к cp932 кодовая точка 3F. (3F вопросительный знак ("?") — это - то, что всегда используется, когда преобразование не может быть выполнено.

B.11.5: Что должно я делать, если я хочу преобразовать SJIS 81CA к cp932?

Наш ответ:"?". Есть серьезные жалобы об этом: много людей предпочли бы "свободное" преобразование, так, чтобы 81CA (NOT SIGN) в sjis становится 81CA (FULLWIDTH NOT SIGN) в cp932. Мы рассматриваем изменение к этому поведению.

B.11.6: Как делает MySQL, представляют Иену (¥) знак?

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

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

B.11.7: MySQL Does планирует сделать отдельный набор символов где 5C знак Иены, как по крайней мере один другой главный DBMS делает?

Это - одно возможное решение проблемы знака Иены; однако, это не будет происходить в MySQL 5.1 или 6.0.

B.11.8: Из каких проблем я должен знать, работая с корейскими наборами символов в MySQL?

В теории, в то время как было несколько версий euckr (Расширенный Код Unix Корея) набор символов, только одна проблема была отмечена.

Мы используем разновидность "ASCII" EUC-КРИПТОНА, в который кодовая точка 0x5c ОБРАТНЫЙ SOLIDUS, который является \, вместо того "KS-римской", разновидности EUC-КРИПТОНА, в который кодовая точка 0x5c WON SIGN(₩). Это означает, что невозможно преобразовать Unicode U+20A9 к euckr:

mysql> SELECT    ->     CONVERT('₩' USING euckr) AS euckr,    ->     HEX(CONVERT('₩' USING euckr)) AS hexeuckr;+-------+----------+| euckr | hexeuckr |+-------+----------+| ?     | 3F       |+-------+----------+1 row in set (0.00 sec)

Графическая корейская диаграмма MySQL здесь: euckr.

B.11.9: Почему я получаю Неправильные строковые сообщения об ошибках значения?

Для иллюстрации мы составим таблицу с одним Unicode (ucs2) столбец и один китаец (gb2312) столбец.

mysql> CREATE TABLE
        ch    -> (ucs2 CHAR(3) CHARACTER SET ucs2,    -> gb2312 CHAR(3) CHARACTER SET gb2312);Query OK, 0 rows affected (0.05 sec)

Мы попытаемся поместить редкий символ 汌 в обоих столбцах.

mysql> INSERT INTO ch VALUES
        ('A汌B','A汌B');Query OK, 1 row affected, 1 warning (0.00 sec)

А-ч, есть предупреждение. Используйте следующий оператор, чтобы видеть, каково это:

mysql> SHOW WARNINGS\G*************************** 1. row ***************************  Level: Warning   Code: 1366Message: Incorrect string value: '\xE6\xB1\x8CB' for column 'gb2312' at row 11 row in set (0.00 sec)

Таким образом, это - предупреждение о gb2312 столбец только.

mysql> SELECT ucs2,HEX(ucs2),gb2312,HEX(gb2312) FROM ch;+-------+--------------+--------+-------------+| ucs2  | HEX(ucs2)    | gb2312 | HEX(gb2312) |+-------+--------------+--------+-------------+| A汌B | 00416C4C0042 | A?B    | 413F42      |+-------+--------------+--------+-------------+1 row in set (0.00 sec)

Несколько вещей нуждаются в объяснении здесь:

B.11.10: Почему делает мой фронтэнд GUI, или браузер не выводят на экран символы CJK правильно в моем приложении, используя Доступ, PHP, или другой API?

Получите прямую связь с сервером, используя mysql клиент (Windows: mysql.exe), и попытка тот же самый запрос там. Если mysql отвечает правильно, то проблема может состоять в том, что Ваш интерфейс приложения требует инициализации. Используйте mysql, чтобы сказать Вам, какой набор символов или устанавливает это использование с оператором SHOW VARIABLES LIKE 'char%';. Если Вы используете Доступ, то Вы наиболее вероятно соединяетесь с Соединителем/ODBC. В этом случае следует проверить Раздел 21.1.4, "Конфигурируя Соединитель/ODBC". Если, например, Вы используете big5, Вы вошли бы SET NAMES 'big5'. (Отметьте что нет ; требуется в этом случае). Если Вы используете ASP, Вы, возможно, должны были бы добавить SET NAMES в коде. Вот пример, который работал в прошлом:

<%Session.CodePage=0Dim strConnectionDim ConnstrConnection="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 с Соединителем/Сетью тогда следует определить набор символов в строке подключения. См. Раздел 21.2.5.1, "Соединяясь с MySQL Используя Соединитель/Сеть", для получения дополнительной информации.

Если Вы используете PHP, попробуйте это:

<?php  $link = mysql_connect($host, $usr, $pwd);  mysql_select_db($db);  if( mysql_error() ) { print "Database ERROR: " . mysql_error(); }  mysql_query("SET NAMES 'utf8'", $link);?>

В этом случае мы использовали SET NAMES измениться character_set_client и character_set_connection и character_set_results.

Мы поощряем использование более нового mysqli расширение, а не mysql. Используя mysqli, предыдущий пример мог быть переписан как показано здесь:

<?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'");?>

Другая проблема, с которой часто встречаются в приложениях PHP, имеет отношение к предположениям, сделанным браузером. Иногда добавляя или изменяясь a <meta> тег достаточен, чтобы исправить проблему: например, чтобы обеспечить, чтобы агент пользователя интерпретировал контент страницы как UTF-8, следует включать <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> в <head> из страницы HTML.

Если Вы используете Connector/J, см. Раздел 21.3.5.4, "Используя Наборы символов и Unicode".

B.11.11: я обновил до MySQL 5.7. Как я могу вернуться к поведению как этот в MySQL 4.0 относительно наборов символов?

В MySQL Version 4.0, был единственный "глобальный" набор символов и для сервера и для клиента, и решения, относительно которого символ использовать был сделан администратором сервера. Этот измененный запуск с MySQL Version 4.1. Что происходит, теперь "квитирование", как описано в Разделе 10.1.4, "Наборы символов соединения и Сопоставления":

Посредством примера предположите, что Ваш любимый набор символов сервера latin1 (вряд ли в области CJK, но это - значение по умолчанию). Предположите далее, что клиент использует 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/ |+--------------------------+----------------------------------------+8 rows in set (0.01 sec)

Теперь остановите клиент, и затем остановите сервер, используя 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/ |+--------------------------+----------------------------------------+8 rows in set (0.01 sec)

Поскольку можно видеть, сравнивая отличающиеся следствия SHOW VARIABLES, сервер игнорирует начальные установки клиента если --skip-character-set-client-handshake используется.

B.11.12: Почему делают некоторых LIKE и FULLTEXT поискы со сбоем символов CJK?

Есть очень простая проблема с LIKE поискы на BINARY и BLOB столбцы: мы должны знать конец символа. С многобайтовыми наборами символов у различных символов могли бы быть различные длины октета. Например, в utf8, A требует одного байта, но ペ требует трех байтов, как показано здесь:

+-------------------------+---------------------------+| OCTET_LENGTH(_utf8 'A') | OCTET_LENGTH(_utf8 'ペ') |+-------------------------+---------------------------+|                       1 |                         3 |+-------------------------+---------------------------+1 row in set (0.00 sec)

Если мы не знаем, где первый символ заканчивается, то мы не знаем, где второй символ начинается, когда даже очень простые поискы такой как LIKE '_A%' сбой. Решение состоит в том, чтобы использовать регулярный набор символов CJK во-первых, или преобразовать в набор символов CJK перед сравнением.

Это - одна причина, почему MySQL не может позволить кодировки несуществующих символов. Если это не строго об отклонении плохого ввода, то у этого нет никакого способа знать, где символы заканчиваются.

Для FULLTEXT поискы, мы должны знать, где слова начинаются и заканчиваются. С Западными языками это редко - проблема, потому что большинство (если не все) их использует границу слова, "легкую идентифицировать" — пробел. Однако, это обычно не случай с азиатской записью. Мы могли использовать произвольные лежащие на полпути меры, как принятие, что все символы Ханьшуй представляют слова, или (для японского языка) в зависимости от изменений от Katakana до Hiragana из-за грамматических окончаний. Однако, единственное верное решение требует всестороннего списка слов, что означает, что мы должны были бы включать словарь в сервер для каждого азиатского поддерживаемого языка. Это просто не выполнимо.

B.11.13: Как делают я знаю ли символ X доступно во всех наборах символов?

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

DELIMITER //CREATE PROCEDURE p_convert(ucs2_char CHAR(1) CHARACTER SET ucs2)BEGINCREATE 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 is a conversion problem, UPDATE will produce a warning. */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 ujisFROM tj;DROP TABLE tj;END//

Ввод может быть любым синглом ucs2 символ, или это может быть значение кодовой точки (шестнадцатеричное представление) того символа. Например, от списка Unicode ucs2 кодировки и имена (http://www.unicode.org/Public/UNIDATA/UnicodeData.txt), мы знаем, что символ Katakana, Pe появляется во всех наборах символов CJK, и что его значение кодовой точки 0x30da. Если мы используем это значение в качестве параметра p_convert(), результат как показано здесь:

mysql> CALL p_convert(0x30da)//+------+--------+------+-------+---------+-------+--------+------+------+------+| ucs2 | utf8   | big5 | cp932 | eucjpms | euckr | gb2312 | gbk  | sjis | ujis |+------+--------+------+-------+---------+-------+--------+------+------+------+| 30DA | E3839A | C772 | 8379  | A5DA    | ABDA  | A5DA   | A5DA | 8379 | A5DA |+------+--------+------+-------+---------+-------+--------+------+------+------+1 row in set (0.04 sec)

Так как ни одно из значений столбцов не 3F— то есть, символ вопросительного знака (?) — мы знаем что каждое работавшее преобразование.

B.11.14: Почему делают CJK представляет вид в виде строки неправильно в Unicode? (I)

Иногда люди замечают что результат a utf8_unicode_ci или ucs2_unicode_ci поиск, или ORDER BY вид не то, что они думают, что собственное ожидало бы. Хотя мы никогда не исключаем возможность, что есть ошибка, мы нашли в прошлом, что много людей не читают правильно стандартную таблицу весов для Алгоритма сопоставления Unicode. MySQL использует таблицу, найденную в http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. Это не первая таблица, которую Вы найдете, перемещаясь от unicode.org домашняя страница, потому что MySQL использует более старые 4.0.0" allkeys" таблица, а не более свежие 4.1.0 таблицы. (Более новое '520' сопоставления в MySQL 5.6 используют 5.2" allkeys" таблица.) Это - то, потому что мы очень осторожны об изменении упорядочивания, которое влияет, индексирует, чтобы мы не вызываем ситуации, такие как это, сообщил в Ошибке #16526, иллюстрированный следующим образом:

mysql< CREATE TABLE tj (s1 CHAR(1) CHARACTER SET utf8
        COLLATE utf8_unicode_ci);Query OK, 0 rows affected (0.05 sec)mysql> INSERT INTO tj VALUES ('が'),('か');Query OK, 2 rows affected (0.00 sec)Records: 2  Duplicates: 0  Warnings: 0mysql> SELECT * FROM tj WHERE s1 = 'か';+------+| s1   |+------+| が  || か  |+------+2 rows in set (0.00 sec)

Символ в первой строке результата не является тем, который мы искали. Почему MySQL получал это? Сначала мы ищем значение кодовой точки Unicode, которое возможно, читая шестнадцатеричное число для ucs2 версия символов:

mysql> SELECT s1, HEX(CONVERT(s1 USING ucs2)) FROM
        tj;+------+-----------------------------+| s1   | HEX(CONVERT(s1 USING ucs2)) |+------+-----------------------------+| が  | 304C                        || か  | 304B                        |+------+-----------------------------+2 rows in set (0.03 sec)

Теперь мы ищем 304B и 304C в 4.0.0 allkeys таблица, и находит эти строки:

304B  ; [.1E57.0020.000E.304B] # HIRAGANA LETTER KA304C  ; [.1E57.0020.000E.304B][.0000.0140.0002.3099] # HIRAGANA LETTER GA; QQCM

Официальные имена Unicode (после "#" метка) говорят нам японскую слоговую азбуку (Hiragana), неофициальная классификация (буква, цифра, или знак препинания), и Западный идентификатор (KA или GA, которые, оказывается, озвучиваются и неречевые компоненты той же самой пары буквы). Что еще более важно основной вес (первое шестнадцатеричное число в квадратных скобках) 1E57 на обеих строках. Для сравнений и в поиске и в сортировке, MySQL обращает внимание на основной вес только, игнорируя все другие числа. Это означает, что мы сортируем が и か правильно согласно спецификации Unicode. Если бы мы хотели отличить их, то мы должны были бы использовать non-UCA (Алгоритм сопоставления Unicode) сопоставление (utf8_bin или utf8_general_ci), или сравниться HEX() значения, или использование ORDER BY CONVERT(s1 USING sjis). Быть корректным "согласно Unicode" не достаточно, конечно: человек, который представил ошибку, был одинаково корректен. Мы планируем добавить другое сопоставление для японского языка согласно JIS X 4061 стандарт, в который речевые/неречевые пары буквы как KA/GA различимы для того, чтобы упорядочить цели.

B.11.15: Почему делают CJK представляет вид в виде строки неправильно в Unicode? (II)

Если Вы используете Unicode (ucs2 или utf8), и Вы знаете то, что порядок сортировки Unicode (см. Раздел B.11, "FAQ MySQL 5.7: MySQL Chinese, японский язык, и корейские Наборы символов"), но MySQL все еще, кажется, сортирует Вашу таблицу неправильно, тогда следует сначала проверить табличный набор символов:

mysql> SHOW CREATE TABLE t\G******************** 1. row ******************Table: tCreate Table: CREATE TABLE `t` (`s1` char(1) CHARACTER SET ucs2 DEFAULT NULL) ENGINE=MyISAM DEFAULT CHARSET=latin11 row in set (0.00 sec)

Так как набор символов, кажется, корректен, давайте видеть что информация INFORMATION_SCHEMA.COLUMNS таблица может обеспечить об этом столбце:

mysql> SELECT COLUMN_NAME, CHARACTER_SET_NAME,
        COLLATION_NAME    -> FROM
        INFORMATION_SCHEMA.COLUMNS    -> WHERE COLUMN_NAME =
        's1'    -> AND TABLE_NAME = 't';+-------------+--------------------+-----------------+| COLUMN_NAME | CHARACTER_SET_NAME | COLLATION_NAME  |+-------------+--------------------+-----------------+| s1          | ucs2               | ucs2_general_ci |+-------------+--------------------+-----------------+1 row in set (0.01 sec)

(См. Раздел 19.4," INFORMATION_SCHEMA COLUMNS Таблица", для получения дополнительной информации.)

Можно видеть, что сопоставление ucs2_general_ci вместо ucs2_unicode_ci. Причина, почему это так, может быть найдена, используя SHOW CHARSET, как показано здесь:

mysql> SHOW CHARSET LIKE 'ucs2%';+---------+---------------+-------------------+--------+| Charset | Description   | Default collation | Maxlen |+---------+---------------+-------------------+--------+| ucs2    | UCS-2 Unicode | ucs2_general_ci   |      2 |+---------+---------------+-------------------+--------+1 row in set (0.00 sec)

Для ucs2 и utf8, сопоставление значения по умолчанию является "общим". Чтобы определить сопоставление Unicode, использовать COLLATE ucs2_unicode_ci.

B.11.16: Почему мои дополнительные символы отклоняются MySQL?

Перед MySQL 5.5.3 MySQL не поддерживает дополнительные символы — то есть, символы, которые нуждаются больше чем в 3 байтах — для UTF-8. Мы поддерживаем только, какой Unicode вызывает Основную Многоязычную Плоскость / Плоскость 0. Только несколько очень редких символов Ханьшуй дополнительны; поддержка их является редкой. Это привело к отчетам, таким как это, нашел в Ошибке #12600, который мы отклонили как "не ошибка". С utf8, мы должны усечь строку ввода, когда мы встречаемся с байтами, которые мы не понимаем. Иначе, мы не знали бы, какой длины плохой многобайтовый символ.

Одно возможное обходное решение должно использовать ucs2 вместо utf8, когда "плохие" символы изменяются на вопросительные знаки; однако, никакое усечение не имеет место. Можно также изменить тип данных на BLOB или BINARY, которые не выполняют проверки законности.

С MySQL 5.5.3 поддержка Unicode расширяется, чтобы включать дополнительные символы посредством дополнительных наборов символов Unicode: utf16, utf32, и 4 байта utf8mb4. Эти наборы символов поддерживают дополнительные символы Unicode вне Основной Многоязычной Плоскости (BMP).

B.11.17: разве это не должен быть "CJKV"?

Нет. Термин "CJKV" (китайские японские корейские вьетнамцы) относится к вьетнамским наборам символов, которые содержат Ханьшуй (первоначально китайский) символы. У MySQL нет никакого плана поддерживать старый вьетнамский сценарий, используя символы Ханьшуй. MySQL действительно, конечно, поддерживает современный вьетнамский сценарий с Западными символами.

С MySQL 5.6 есть вьетнамские сопоставления для наборов символов Unicode, как описано в Разделе 10.1.14.1, "Наборы символов Unicode".

B.11.18: MySQL Does позволяет символам CJK использоваться на имена базы данных и имена таблиц?

Эта проблема устраняется в MySQL 5.1, автоматически переписывая имена соответствующих каталогов и файлов.

Например, если Вы создаете названную базу данных 楮 на сервере, операционная система которого не поддерживает CJK в именах каталогов, MySQL создает названный каталог @0w@00a5@00ae. который является только необычным способом закодировать E6A5AE— то есть, Unicode шестнадцатеричное представление для 楮 символ. Однако, если Вы выполняете a SHOW DATABASES оператор, можно видеть, что база данных перечисляется как 楮.

B.11.19: Где я могу найти преобразования MySQL Manual into Chinese, японского языка, и корейского языка?

Версия Упрощенного китайского Руководства, тока для MySQL 5.1.12, может быть найдена в http://dev.mysql.com/doc/. Японское преобразование руководства MySQL 4.1 может быть загружено с http://dev.mysql.com/doc/.

B.11.20: Где я могу получить справку с CJK и связанными проблемами в MySQL?

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