заметки на полях » mysql

MySQL различные UTF – utf8_bin и utf8_general_ci

Дерябин Сергей — Wed, 19 May 2010 07:42:14 +0000

Чем же отличаются эти два collate для таблиц?
utf8_bin – использует сравнения по двоичным значениям каждого символа
utf8_general_ci – использует сравнения на основе языковых особенностей и игнорирует регистр символов.

Для наглядности приведем небольшой эксперимент.

CREATE TABLE peoples (
id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
first_name VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL ,
last_name VARCHAR( 255 ) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL
) ENGINE = INNODB CHARACTER SET utf8;

INSERT INTO peoples (first_name, last_name) VALUES ('Петя', 'Иванов'), ('андрей', 'иванов'), ('Иван', 'Петров'), ('Андрей', 'Сидоров');
INSERT INTO peoples (first_name, last_name) VALUES ('Петр', 'Большой'), ('Пётр', 'Большои');

Получаем такую вот табличку:

Из-за разности сопоставления символов получаются различия в сортировке, если делать её по полю с utf8_general_ci получаем следующее:

И не совсем ожидаемым образом отрабатывает запрос с сортировкой по полю utf8_bin

Помимо всего прочего в utf8_general_ci некоторые буквы считаются идентичными, например ё = е:

mysql> SELECT * FROM peoples WHERE first_name='Петр';
+----+------------+----------------+
| id | first_name | last_name |
+----+------------+----------------+
| 5 | Петр | Большой |
| 6 | Пётр | Большои |
+----+------------+----------------+

Отсюда же может появиться и проблема с уникальными ключами. В приведенной структуре уникальный ключ по полю first_name создать не получится, т. к. дублируются значения «Андрей» и «андрей», а так же не совсем ожидаемые «Пётр» и «Петр».

mysql> CREATE UNIQUE INDEX uq_peoples_first_name ON peoples (first_name);
ERROR 1062 (23000): Duplicate entry 'Пётр' FOR KEY 3

Зато по полю last_name создастся без проблем, в нем все значения различающиеся:

mysql> CREATE UNIQUE INDEX uq_peoples_last_name ON peoples (last_name);
Query OK, 6 rows affected (0.06 sec)
Records: 6 Duplicates: 0 Warnings: 0

С проблемой уникальности я столкнулся при переводе старой таблички с пользователями из cp1251_general_ci в utf8_general_ci – логины «Ёлка» и «елка» перестали быть уникальными. Можно было создать эталонное поле utf8_bin (используемое только при авторизации) со значением приведенным к скажем нижнему регистру.

Ну и мануал: Unicode Character Sets

mysqldump и проблемы с кодировкой

Дерябин Сергей — Mon, 11 May 2009 01:21:07 +0000

Делая дамп совершенно обычным способом

1	mysqldump ads -u <user> -p > dump.sql

Заметил маленькую неприятность, что дамп получается со сбитыми кодировками. Добавление к параметра

--default-character-set=utf8

облегчения не принесло и не возымело надо сказать вообще никакого эффекта. После небольшого периода гугления выяснилось, что дело не в утилите mysqldump, а в настройках кодировок на сервере. Посмотрев текущие значения:

1	mysql> show variables;

Понял что нужно лезть в конфиг сервера. В раздел глобальных параметров файла

/etc/mysql/my.cnf

необходимо добавить что то вроде:

1
2
3
4
5
6
7

[mysqld]

default-character-set = utf8
character_set_server = utf8
character_set_client = utf8
collation_server = utf8_general_ci
skip-character-set-client-handshake

Параметры которые могут понадобиться при этом:

character_set_client
– кодировка, в которой данные будут поступать от клиента
character_set_connection
– кодировка по умолчанию для всего, что в рамках соединения не имеет кодировки
character_set_database
– кодировка по умолчанию для баз
character_set_filesystem
– кодировка для работы с файловой системой (LOAD DATA INFILE, SELECT … INTO OUTFILE, и т.д.)
character_set_results
– кодировка, в которой будет выбран результат
character_set_server
– кодировка, в которой работает сервер
character_set_system
– кодировка, в которой задаются идентификаторы MySQL, всегда UTF8
character_sets_dir
– папка с кодировками
skip-character-set-client-handshake
– игнорировать клиентские настройки кодировки

Но не смотря на правильную установку кодировок и сравнения для таблиц и строк данные писались в latin1. Это можно было определить по битому дампу. Решить можно довольно просто и в лоб – делаем дамп в latin1:

1	mysqldump --default-character-set=latin1 --skip-set-charset -u <user> -p > b.sql

Таким образом мы получаем правильный дамп, т.к. кодировка полученного sql будет UTF, с помощью параметра

--default-character-set=latin1

мы сдампили данные в той кодировке в которой они и была добавлены (когда сервер брал кодировки по умолчанию) и убрали упоминания об этом с помощью аттрибута

--skip-set-charset

Осталось развернуть базу и можно пользоваться уже с новой кодировкой.

Интересные материалы по теме

MySQL + кодировки

MySQL 5.1 Reference Manual – Server System Variables

Как правильно делать backup базы данных сайта