| 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 для баз противопоказана по причине падения производительности при сортировках.
У программистов читавших хотябы Д. Кнута потери производительности не происходит.
| | |
|
| 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.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" сортировка по алфавиту не происходит, точнее частично не происходит - имена начинающиеся на З,В,Ч почемуто идут после У. Пробовал делать всё чего здесь в форуме написали - ничего не выходит. Куда копать?
| | |
|