The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Как в MySQL обеспечить правильную сортировку данных в кодировке cp1251.
MySQL должен быть собран с ключами:
   ./configure --with-charset=koi8_ru --with-extra-charsets=all
Далее, сразу после каждого соединения с базой нужно использовать оператор:
    SET CHARACTER SET cp1251_koi8
Если данные в cp1251 уже в базе, их нужно поместить в базу вновь.
 
11.06.2003
Ключи: config, charset, sort, connect, mysql / Лицензия: CC-BY
Раздел:    Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, Nickolay (?), 13:43, 11/06/2003 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    брррр как некрасиво.
    а просто запускать демон с default-character-set=cp1251 ???
     
     
  • 2.2, uldus (?), 14:22, 11/06/2003 [^] [ответить]    [к модератору]
  • +/
    >брррр как некрасиво.
    >а просто запускать демон с default-character-set=cp1251 ???

    Некрасиво запускать демон с default-character-set=cp1251 под Unix системой.
    Пользователям должно быть настоятельно рекомендовано держать базы в koi8-r, не хотят - пусть используют кривые решения.

     
     
  • 3.3, Nickolay (?), 10:24, 12/06/2003 [^] [ответить]    [к модератору]
  • +/
    >Некрасиво запускать демон с default-character-set=cp1251 под Unix системой.
    >Пользователям должно быть настоятельно рекомендовано держать базы в koi8-r, не хотят -
    >пусть используют кривые решения.
    IMHO это Ваше IMHO.
    криво - это заставлять пользователей(клиентов). кажется уже прошел период когда в юниксе были проблемы с ср1251... если ср1251 - это кривизна - то пардон, зачем тогда вообще поддержка ср1251?
    это всего лишь мое IMHO.
    p.s. вот уже года два-три у нас работает несколько mySQL-серверов с ср1251 и никаких проблем...
     
     
  • 4.4, uldus (?), 19:05, 12/06/2003 [^] [ответить]    [к модератору]
  • +/
    >криво - это заставлять пользователей(клиентов).

    Ориентироваться нужно на запросы лузеров, а на пожелания квалифицированных пользователей. К тому же, под юникс родная кодировка - KOI8-R, и уже только поэтому серверные процессы в системе с KOI8-R окружением должны работать под KOI8-R локалью. А перекодирвка дожна быть настраиваемой и прозрачнойдля клиента (пример, PostgreSQL), а не через кривой хак как в MySQL.

    >кажется уже прошел период когда в юниксе

    Под юниксом я никогда не буду запускать скрипт работающий с текстом в cp1251.

    >это всего лишь мое IMHO.
    >p.s. вот уже года два-три у нас работает несколько mySQL-серверов с ср1251
    >и никаких проблем...

    Пока клиент не появится желающий базу в koi8-r, что тогда ему предложите ? Перекодировки koi8r=>cp1251, в отличие от cp1251=>koi8r в MySQL нет. А вот клиент может оказаться значительнее и важнее всех cp1251 юзеров.

     
  • 1.5, Аноним (5), 10:24, 13/06/2003 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    перекодировка cp1251=>koi8r ? а куда же у вас теряются "лапки", беларуские, българские и украинские символы?
     
  • 1.6, Nikolaev D. (?), 09:28, 16/06/2003 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    >К тому же, под юникс родная кодировка - KOI8-R
    Не согласен. Все проблемы решаются раз и навсегда при использовании UTF-8.
     
     
  • 2.10, uldus (?), 10:51, 01/07/2003 [^] [ответить]    [к модератору]  
  • +/
    >Не согласен. Все проблемы решаются раз и навсегда при использовании UTF-8.

    UTF-8 не решает все проблемы.

    Гланые 2 недостатка unicode:

    1. Значительное усложнение. Unicode не "прозрачна", не обладая специальными средствами невозможно уловить содержимое текста, в отличии, например, от koi8-r, которая замечательно подходит для передачи данных в сети. Другая сторона усложнения - необходимость модификации ПО, старые программы так просто с Unicode не заработают.

    2. Увеличение объема текста. Если для офисных документов - это почти не заметно, то для текстов передаваемых по сети увеличение объема до 2 раз (для кирилицы UTF-8 - 2 байта, англоязычные пользователи чувствуют себя комфортно используя 1 байтное UTF-8) значительно влияет на трафик и как следствие стоимость и время передачи. Увеличение объема храненимой информации ведет к дополнительным затратам на обработку и чтение данных. Расширенные символы в HTML документах прекрасно представляются в "&...;" нотации.

     
  • 1.7, OlegI (?), 22:30, 26/06/2003 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Кодировка Koi-8 для баз противопоказана по причине падения производительности при сортировках. Она единственная из всех - нелексикографическая. Т.е. бинарная сотрировка с ней не работает. База должна быть либо в cp1251, либо в utf8. Если же вдруг клинету нужно отдавать в koi-8, то проще использовать перекодировку.
    "роднистость" кодировки для ОС это все равно, что "если русский, то должен беспробудно пить водку"
     
     
  • 2.8, uldus (?), 23:07, 26/06/2003 [^] [ответить]    [к модератору]  
  • +/
    >Кодировка Koi-8 для баз противопоказана по причине падения производительности при сортировках.

    У программистов читавших хотябы Д. Кнута потери производительности не происходит.

     
     
  • 3.15, FractalizeR (??), 18:51, 28/12/2007 [^] [ответить]    [к модератору]  
  • +/
    А причем тут программисты и кнут, если сортировку выполняет MySQL?
     
  • 1.9, kryser (?), 22:47, 28/06/2003 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Запусти mysql вот такой строкой:
    /bin/sh /usr/local/bin/safe_mysqld --default-character-set=cp1251 &
    у меня била таже проблема когда-то и давно уже нет:)
     
  • 1.11, Visual (??), 23:18, 16/02/2006 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Хелп ! Прблемма с кодировкой в форуме, что уже только не делал, а все равно вместо русских букв знаки вопроса. Я пользуюсь phpmyadmin и сейчас стоит MySQL-кодировка: UTF-8 Unicode (utf8), изменить ее пока у меня невышло. Дело в этом ?
     
  • 1.12, Genia (?), 13:25, 02/10/2006 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Первый запрос к БД после подключения справится с utf8:
    mysql_query("SET NAMES 'cp1251'");
     
  • 1.13, vasilich (ok), 20:49, 26/02/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    крыша едит от этих кодировок. програмеры из mysql решили подкинуть гемора
     
  • 1.14, Dmitriy (??), 17:28, 24/12/2007 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    у меня похожая проблема,
    есть Linux-сервер с локалью koi8-r на нём apache и  mysql собран c --with-charset=koi8r --with-extra-charsets=all, в БД храняться фамилии на русском. При обращении через php в БД sql запросом типа "select name from table order by name asc" сортировка по алфавиту не происходит, точнее частично не происходит - имена начинающиеся на З,В,Ч почемуто идут после У. Пробовал делать всё чего здесь в форуме написали - ничего не выходит. Куда копать?
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor