MySQL and UTF-8

[sims]

MySQL and UTF-8

Рискну завести топик на эту тему. Уже были, но решения там я так и не нашел. К тому же, было это давно, может что-нибудь изменилось.

--

При хранении данных в MySQL в кодировке UTF-8 результаты выборки типа: WHERE name LIKE '%абв%' не корректны, т.е. находятся строки, в которых данных сочитаний нет.
Строгий поиск вроде WHERE name = 'Иван' - вроде работает, сортировка с помощью функции binary() (ORDER BY BINARY(name)) - тоже вроде работает, а вот LIKE - ни в какую. Можно ли с этим что-нибудь сделать, может в какой-нибудь версии MySQL это уже пофиксили?

Пробовал установить default-character-set=UTF-8 - ошибка. Да и не смогу я у провайдера на сервере так поменять, перекомпилировать (если понадобится) тоже не смогу.

В общем, очень хотелось бы получить помощь.

-~{}~ 06.06.04 20:29:

Да, и ещё такой вопрос. Небольшой офф-топик, но не хотелось бы создавать лишний топик в другом форуме.
Как с этим дела обстоят у Postgress?

-~{}~ 06.06.04 20:42:

И ещё, народ говорит, что вроде как в 4.1 UTF-8 поддерживается. Отсюда несколько вопросов.

1. Давно ли он находится в состоянии альфы, и есть ли какая-нибудь информация о том когда он станет релизом? Ибо, пока он им не станет - на своём хостинге я его не увижу -/
2. Действительно ли оно там работает нормально?
3. Что нужно сделать для того чтобы оно там работало, нежно ли его как-нибудь при установке или в конфиге настраивать? Так как если у него в настройках будет default-character-set=KOI8-R - то толку мне от того что он Юникод поддерживает. Или я ошибаюсь?

 

[Profic]

sims
По последним вопросам
1. Давно он в коме, давно Когда из нее выйдет никто не знает
2. В 4.1.0 были некоторые проблемы. В 4.1.1 вроде уже никаких.
3. Вообще-то про мускуль версии 4.1 с его кодировками тебе прямая дорога в раздел мануала про кодировки, где написано, что кодировку можно указать не только для всего сервера, но и базы, таблицы и даже столбца

 

[sims]

Profic
Спасибо.

Если есть желающие ответить на остальные вопросы, милости прошу


Так же интересуют методы "как выкрутиться"

Вообще, вся эта затея с UTF-8 - для того чтобы потом небыло проблем с XML/XSLT.
Первое что приходит в голову при таком раскладе - работмать с UTF-8, при сохранении переводить в windows-1251 - при получении из базы - обратно в UTF. но
1. это глупо
2. это лишняя работа
3. как же не-кирилические символы, и символы "чисто unicode"

В общем, по прежнему жду помощи

 

[Sad Spirit]

Re: MySQL and UTF-8

Автор оригинала: sims
Да, и ещё такой вопрос. Небольшой офф-топик, но не хотелось бы создавать лишний топик в другом форуме.
Как с этим дела обстоят у Postgress?

Нормально обстоят. Есть проблемы с работой upper()/lower() (в смысле, не работают они), но это пофиксят в версии 7.5.

По поводу сроков: у PostgreSQL 7.5 все шансы стать стабильной версией раньше MySQL 4.1.x

 

[sims]

Sad Spirit
Хех, спасибо. Жаль, только, что он на хостингах не так распространён.

-~{}~ 06.06.04 22:12:

Я тут подумал, может PHP5 со встроенной поддержкой SQLite выйдет раньше чем MySQL 4.1, и если там всё нормально будет, то на MySQL можно будет благополучно забить?

Что там в SQLite с UTF-8, кто знает?
Как вы считаете?

-~{}~ 06.06.04 22:12:

нет в жЫзни счастья.

 

[Sad Spirit]

Автор оригинала: sims
Хех, спасибо. Жаль, только, что он на хостингах не так распространён.

меня вот всё время мучает вопрос: люди выбирают хостинг под определённые требования или подгоняют требования под имеющийся хостинг?

-~{}~ 06.06.04 23:51:

На самом деле, если рассматривается возможность забить на MySQL в пользу SQLite, то PostgreSQL для такого проекта будет явным перебором.

 

[Кром]

>меня вот всё время мучает вопрос: люди выбирают хостинг под определённые требования...

Скорее люди выбирают популярные решения.

 

[.des.]

2Кром.. угу. Это и огорчает. Давайте представим, что sqlite стал популярным.

 

[Sad Spirit]

Во-во. Представляешь, Кром, везде SQLite, во всех объявлениях о работе SQLite, потому что про него "все знают", и тут ты, посвятивший несколько лучших лет жизни устаревшей технологии.

 

[sims]

ы.... вообще-то не понятно куда свёлся разговор

про хостинг скажу:
Я работаю в конторе, которая занимается разработкой сайтов, и большинство из них хостится на одном определённом хостинге на котором не очень радостная ситуация :/ Сделать с эти я ничего не могу, как ни стараюсь.

Ну, так а что бы вы посоветовали чтобы всё работало?

как варианты

1. Поставить пхп4 с поддержкой SQLite (так чем он плох, я так и не понял)
2. Уговорить хостера поставить ещё и Postgress
3 .......... ваш вариант )

 

[Sad Spirit]

Автор оригинала: sims
1. Поставить пхп4 с поддержкой SQLite (так чем он плох, я так и не понял)

Хорош. Если в базу практически не пишут.

2. Уговорить хостера поставить ещё и Postgress

Уговори, это небось будет легче чем уговорить поставить альфа-версию MySQL.

 

[Balancer]

Не было (почти ) проблем с 4.1.1alpha, а вот после переползания на 4.1.2alpha вылез хитрый баг. Теперь при "общеMySql'ном" UTF-8 у клиентов (в частности, phpMyAdmin) по дефолту стоит character set client latin1, character set connection latin1 и character set results. При этом character set database utf8, character set server utf8, character set system utf8. Для глобальных значений - всё показывается utf8.

Компилилось с
./configure \
--with-charset=utf8 \
--with-extra-charsets=all

В my.cnf во всех секциях прописано default-character-set = utf8

Не пойму уже, куда копать :-/
Оно, конечно, если после коннекта SET CHARACTER SET utf8 прописываешь, всё как надо работает, но, во-первых, лениво в каждый скрипт такое совать, во-вторых - неправильно. 4.1.1 же работал

 

[sims]

Sad Spirit
а что происходит когда много пишут в базу, тормозит? Сильно?

 

[Profic]

Balancer
Я не знаю как это побороть т.к. не знаю всей системы, но опишу причины. Может поймешь как побороть.
Клиент при соединении говорит серверу: Привет
Сервер говорит: Привет, моя текущая кодировка utf-8
Клиент пытается поставить эту кодировку, но не находит ее в нужном месте и делает откат на latin1 и говорит серверу: Моя кодировка latin1
...
Дальше сам знаешь что произодит.
Вариант - проверь пути к кодировкам Но может это и глюк альфы

-~{}~ 07.06.04 21:54:

sims
Некоторые мои выкладки (ИМХО в общем): Судя по всему при записи лочится весь файл, следовательно происходит не более 1 записи одновременно. Это как минимум. А вот насколько реально медленно происходят эти операции - не знаю.

Я бы если бы и использовал SQLite то для хранения каких-нить конфигурационных данных До того как вступит в действие какая-нить нормальная СУБД Читает он шустро

 

[Balancer]

Profic
Не похоже. Когда клиент ставит свою кодировку явно - всё ок. Если же её не указывает (в phpMyAdmin вообще нет нигде блока "SET CHARACTER SET"), то тогда MySQL оказывается в latin1. Боюсь, действительно, глюк альфы. Ну да, вроде, хоть таблицы с FULLTEXT индексом перестали падать при апдейтах в UTF-8.

Правда, для 500мб базы FULLTEXT создаётся уже 16352 секунды "Repair by sorting | ALTER TABLE `ib_bodies2` ADD FULLTEXT (
`post`) "

 

[Апельсин]

> Когда клиент ставит свою кодировку явно - всё ок.

если кодировка отлична от latin1, то ее и надо явно задавать.

 

[sims]

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

 

[Balancer]

>если кодировка отлична от latin1, то ее и надо явно задавать.

Почему тогда в 4.1.1 и в 4.0.x по умлчанию ставилась не latin1, а дефолтовая кодировка из my.cnf? И какой тогда вообще смысл в дефолтовой кодировке my.cnf?

-~{}~ 11.06.04 11:49:

Проблема совсем интересная.

По SHOW VARIABLES; из mysql всё показывается как положено:

| character_set_client            | utf8                             |
| character_set_connection        | utf8                             |
| character_set_database          | utf8                             |
| character_set_results           | utf8                             |
| character_set_server            | utf8                             |
| character_set_system            | utf8                             |
| character_sets_dir              | /usr/local/share/mysql/charsets/ |
| collation_connection            | utf8_general_ci                  |
| collation_database              | utf8_general_ci                  |
| collation_server                | utf8_general_ci                  |

Если же подключиться из PHP:
Переменная Значение сессии Глобальное значение
сharacter set client latin1 utf8
character set connection latin1 utf8
character set database utf8 utf8
character set results latin1 utf8
character set server utf8 utf8
character set system utf8 utf8
character sets dir /usr/local/share/mysql/charsets/ /usr/local/share/mysql/charsets/
collation connection latin1_swedish_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci

Аналогично имеются проблемы кодировок при работе mnoGoSearch. При чём если для PHP проблема решается легко вставкой дополнительного SET CHARACTER SET, то в mnoGoSearch для этого придётся рыться в мегабайтах исходников, что не есть гут.

Есть у кого-нить мысли, что с этим делать, кроме как ждать MySQL 4.1.3alpha и надеяться, что там всё исправят?

-~{}~ 04.07.04 15:55:

Если тема кому ещё интересна - это, действительно, был баг и в 4.1.3beta его уже исправили.