Re: [sisyphus] странное и некрасивое поведение utf8 в паре rails/mysql

[Michael Bykov <m.bykov@gmail.com>]

28 июня 2009 г. 10:16 пользователь Mikhail Yakshin
(greycat@altlinux.org) написал:
>> MySQL продолжает упорствовать в своих заблуждениях.
>>
> [...]
>
>>  Dict.find_by_word "ᾆδω"
>> => #<Dict id: 2622, parent_id: nil, group_id: nil, variant_id: nil, word: "ἄδω"
>>
>> но  "ᾆδω"  это не "ἄδω" совсем.
>>
>> Интересно, может быть постгрес будет проще настроить?
>
> Это unicode case-insensitive (ci) collation, который вполне себе
> корректно отрабатывает. С точки зрения unicode - это два символа,
> которые равны по sort values - т.к. и "ᾆ", и "ἄ" равны просто "α":
>
> mysql> select 'ᾆ'='α';
> +------------+
> | 'ᾆ'='α'    |
> +------------+
> |          1 |
> +------------+
>
> Это в целом полезный механизм - например, пользователь может написать
> "елка", и оно из-за этого case insensitivity смэтчится со словами
> "ёлка", "Елка" или "Ёлка", которые найдутся в базе.
>
> Более подробно об этом можно почитать в руководстве MySQL:
> http://dev.mysql.com/doc/refman/5.0/en/case-sensitivity.html
>
> Quick solution, если надо просто отключить любые case- и sort-
> sensitivity - использовать тип BINARY (или collation utf8_bin). Их
> можно поставить на БД целиком, на таблицы/поля/переменные или даже
> индивидуальные сравнения:
>
> mysql> select 'ᾆ' COLLATE utf8_bin='α';
> +-----------------------------+
> | 'ᾆ' COLLATE utf8_bin='α'    |
> +-----------------------------+
> |                           0 |
> +-----------------------------+
>
> Postgresql в данном случае будет вести себя точно так же - эти вещи
> (классы эквивалентности по sort value для различных characters)
> прописаны в стандарте unicode.
>
> P.S. Вопрос, видимо, всё-таки не имеет отношения к sisyphus@ -
> предлагаю переместиться в личную почту для дальнейших обсуждений, если
> таковые будут иметь место.
>


Да, спасибо, Михаил, я уже разобрался, всё перевел в utf8 и прописал
collation. Теперь у меня настройки такие:

mysql> show variables like '%collation\_%'
+----------------------+----------+
| Variable_name        | Value    |
+----------------------+----------+
| collation_connection | utf8_bin |
| collation_database   | utf8_bin |
| collation_server     | utf8_bin |
+----------------------+----------+
3 rows in set (0.00 sec)

mysql> show variables like '%character_set\_%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | utf8   |
| character_set_connection | utf8   |
| character_set_database   | utf8   |
| character_set_filesystem | binary |
| character_set_results    | utf8   |
| character_set_server     | utf8   |
| character_set_system     | utf8   |
+--------------------------+--------+
7 rows in set (0.00 sec)

и выполнил после создания базы:

ALTER TABLE dicts MODIFY wo_stress varchar(255) CHARACTER SET utf8
COLLATE utf8_bin;

Всё работает корректно. Вопрос остался скорее теоретический - почему
character_set utf8 мы не используем по-умолчанию, сильно ли это снизит
эффективность? Тут с полгода назад это уже обсуждалось. На глаз
скорость работы не меняется, всё летает.

М.