MySQL должен быть собран с ключами:
./configure --with-charset=koi8_ru --with-extra-charsets=all
Далее, сразу после каждого соединения с базой нужно использовать оператор:
SET CHARACTER SET cp1251_koi8
Если данные в cp1251 уже в базе, их нужно поместить в базу вновь.
URL:
Обсуждается: http://www.opennet.ru/tips/info/498.shtml
брррр как некрасиво.
а просто запускать демон с default-character-set=cp1251 ???
>брррр как некрасиво.
>а просто запускать демон с default-character-set=cp1251 ???Некрасиво запускать демон с default-character-set=cp1251 под Unix системой.
Пользователям должно быть настоятельно рекомендовано держать базы в koi8-r, не хотят - пусть используют кривые решения.
>Некрасиво запускать демон с default-character-set=cp1251 под Unix системой.
>Пользователям должно быть настоятельно рекомендовано держать базы в koi8-r, не хотят -
>пусть используют кривые решения.
IMHO это Ваше IMHO.
криво - это заставлять пользователей(клиентов). кажется уже прошел период когда в юниксе были проблемы с ср1251... если ср1251 - это кривизна - то пардон, зачем тогда вообще поддержка ср1251?
это всего лишь мое IMHO.
p.s. вот уже года два-три у нас работает несколько mySQL-серверов с ср1251 и никаких проблем...
>криво - это заставлять пользователей(клиентов).Ориентироваться нужно на запросы лузеров, а на пожелания квалифицированных пользователей. К тому же, под юникс родная кодировка - KOI8-R, и уже только поэтому серверные процессы в системе с KOI8-R окружением должны работать под KOI8-R локалью. А перекодирвка дожна быть настраиваемой и прозрачнойдля клиента (пример, PostgreSQL), а не через кривой хак как в MySQL.
>кажется уже прошел период когда в юниксеПод юниксом я никогда не буду запускать скрипт работающий с текстом в cp1251.
>это всего лишь мое IMHO.
>p.s. вот уже года два-три у нас работает несколько mySQL-серверов с ср1251
>и никаких проблем...Пока клиент не появится желающий базу в koi8-r, что тогда ему предложите ? Перекодировки koi8r=>cp1251, в отличие от cp1251=>koi8r в MySQL нет. А вот клиент может оказаться значительнее и важнее всех cp1251 юзеров.
перекодировка cp1251=>koi8r ? а куда же у вас теряются "лапки", беларуские, българские и украинские символы?
>К тому же, под юникс родная кодировка - KOI8-R
Не согласен. Все проблемы решаются раз и навсегда при использовании UTF-8.
>Не согласен. Все проблемы решаются раз и навсегда при использовании UTF-8.UTF-8 не решает все проблемы.
Гланые 2 недостатка unicode:
1. Значительное усложнение. Unicode не "прозрачна", не обладая специальными средствами невозможно уловить содержимое текста, в отличии, например, от koi8-r, которая замечательно подходит для передачи данных в сети. Другая сторона усложнения - необходимость модификации ПО, старые программы так просто с Unicode не заработают.
2. Увеличение объема текста. Если для офисных документов - это почти не заметно, то для текстов передаваемых по сети увеличение объема до 2 раз (для кирилицы UTF-8 - 2 байта, англоязычные пользователи чувствуют себя комфортно используя 1 байтное UTF-8) значительно влияет на трафик и как следствие стоимость и время передачи. Увеличение объема храненимой информации ведет к дополнительным затратам на обработку и чтение данных. Расширенные символы в HTML документах прекрасно представляются в "&...;" нотации.
Кодировка Koi-8 для баз противопоказана по причине падения производительности при сортировках. Она единственная из всех - нелексикографическая. Т.е. бинарная сотрировка с ней не работает. База должна быть либо в cp1251, либо в utf8. Если же вдруг клинету нужно отдавать в koi-8, то проще использовать перекодировку.
"роднистость" кодировки для ОС это все равно, что "если русский, то должен беспробудно пить водку"
>Кодировка Koi-8 для баз противопоказана по причине падения производительности при сортировках.У программистов читавших хотябы Д. Кнута потери производительности не происходит.
А причем тут программисты и кнут, если сортировку выполняет MySQL?
Запусти mysql вот такой строкой:
/bin/sh /usr/local/bin/safe_mysqld --default-character-set=cp1251 &
у меня била таже проблема когда-то и давно уже нет:)
Хелп ! Прблемма с кодировкой в форуме, что уже только не делал, а все равно вместо русских букв знаки вопроса. Я пользуюсь phpmyadmin и сейчас стоит MySQL-кодировка: UTF-8 Unicode (utf8), изменить ее пока у меня невышло. Дело в этом ?
Первый запрос к БД после подключения справится с utf8:
mysql_query("SET NAMES 'cp1251'");
крыша едит от этих кодировок. програмеры из mysql решили подкинуть гемора
у меня похожая проблема,
есть Linux-сервер с локалью koi8-r на нём apache и mysql собран c --with-charset=koi8r --with-extra-charsets=all, в БД храняться фамилии на русском. При обращении через php в БД sql запросом типа "select name from table order by name asc" сортировка по алфавиту не происходит, точнее частично не происходит - имена начинающиеся на З,В,Ч почемуто идут после У. Пробовал делать всё чего здесь в форуме написали - ничего не выходит. Куда копать?