За последние 24 часа нас посетили 18859 программистов и 1615 роботов. Сейчас ищут 659 программистов ...

не работает LOWER() UPPER() для русских букв в utf8

Тема в разделе "MySQL", создана пользователем chabapok, 23 сен 2009.

  1. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    У меня не работает регистронезависимый поиск. Для русских он работает как регистрозависимый.

    таблицы созданы в utf8, сравнение utf8_general_ci

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

    ИМХО, это одно поля ягоды. Если заставить работать функции LOWER() и UPPER() -- заработает и LIKE.

    как быть? Помогите плыз.
     
  2. neverlose

    neverlose Активный пользователь

    С нами с:
    27 авг 2008
    Сообщения:
    1.112
    Симпатии:
    20
    _ci - case-insensetive.
    Если для русских букв не работает, используйте LOWER(`field`) = LOWER("value")
     
  3. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    написано же --- LOWER() не срабатывает для русских.
    Понимаете?
    и UPPER() тоже не срабатывает.
     
  4. Koc

    Koc Активный пользователь

    С нами с:
    3 мар 2008
    Сообщения:
    2.253
    Симпатии:
    0
    Адрес:
    \Ukraine\Dnepropetrovsk
    а какая версия мускла?
    еще одна хрень, которая тормозит переход меня на utf-8
     
  5. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    версия виднозная
    mysql> select version();
    +---------------+
    | version() |
    +---------------+
    | 5.0.16-nt-log |
    +---------------+
    1 row in set (0.03 sec)
     
  6. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    Неожиданный поворот дела такой.

    все записи в таблицу вносятся через мой php-скрипт. И назад отдаются через него.
    Я подозреваю, что проблема в нем - он как-то транскодит запись перед тем, как засунуть ее в БД, и декодирует, после того, как извлек.

    вобщем в БД кодировка получается четырехбайтовая - я сохранил результат запроса в файл и смотрел его.
    но на выходе из php-скрипта опять двухбайтовая и правильная -- все работает -- я открыл в браузере результат вывода php и сохранил в файл и посмотрел в hex

    тоже самое, кстати, получатся если добавлять записи через phpmyadmin -- в БД тоже кодировка 4х байтовая оказывается. и тот же phpmyadmin ее потом неверно показывает - почему-то в "обратную сторону" не конвертит.

    теперь осталось понять что не так с php
     
  7. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
  8. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    нет. Все-таки php тут не при чем. я полез в файл ibdata1, нашел в нем "первичные" данные. Они в utf8
     
  9. chabapok

    chabapok Активный пользователь

    С нами с:
    23 сен 2009
    Сообщения:
    7
    Симпатии:
    0
    проблема частично решена.

    помогло переконфигурировать так:

    [mysqld]
    default-character-set=utf8
    character-set-server=utf8
    collation-server=utf8_general_ci
    init-connect="SET NAMES utf8"
    skip-character-set-client-handshake

    [mysqldump]
    default-character-set=utf8

    [client]
    default-character-set = utf8

    самое интересное, что когда я аналогичные этим команды давал из моего скрипта, то ничего не работало.