MySQL: руководство профессионала

Паутов Алексей В.

Для поисков FULLTEXT мы должны знать, где слова начинаются и заканчиваются. С западными языками это редко проблема, потому что большинство (если не все) они используют пробел, чтобы идентифицировать конец слова. Однако, это не так с азиатской записью.

10.11.13: Какие наборы символов 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)

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

Большинство упрощеннных китайских и японских символов Kana появляются во всех 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's 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 ujis FROM 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, то есть символ вопросительного знака (?), мы знаем, что каждое преобразование сработало.

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

Иногда люди наблюдают, что результат поиска 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. Это потому, что разработчики очень осторожны относительно изменения упорядочения, которое воздействует на индексы, чтобы не вызывать ситуации типа сообщенной в Глюке #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: 0

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

+-----+-----------------------------+