The OpenNET Project: Как в MySQL обеспечить правильную сортировку данных в кодировке cp1251.

MySQL должен быть собран с ключами: ./configure --with-charset=koi8_ru --with-extra-charsets=all Далее, сразу после каждого соединения с базой нужно использовать оператор: SET CHARACTER SET cp1251_koi8 Если данные в 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 юзеров.

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 документах прекрасно представляются в "&...;" нотации.

Как в 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, (найти похожие документы)
Раздел: Корень / Программисту и web-разработчику / SQL и базы данных / MySQL специфика / Оптимизация и администрирование MySQL