| |
| 2.6, _ (??), 15:42, 23/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
Почини себе руки и поставь нормальную кодировку на базу/коннект/сервер.
| | |
| 2.7, нео (?), 16:05, 23/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
 SET NAMES UTF8/CP1251/....(ненужное убрать) не пробовал?
| | |
| |
| 3.10, GateKeeper (??), 01:04, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
База UTF8, set names в кодировку исходного текста делал. при селекте данных вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_* на pgsql_*) - всё отлично.
| | |
| |
| 4.12, Аноним (-), 01:22, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
set names делать надо не в "исходную", а в ту кодировку, в которой хочешь получать ответы.
| | |
| |
| 5.16, GateKeeper (??), 13:57, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>set names делать надо не в "исходную", а в ту кодировку, в
>которой хочешь получать ответы.
Ответы на что, на INSERT INTO ... ?
Ниже писал уже: исходные данные в csv (экспорт из епселя), кодировка 1251, это парсится и пихается в базу. База UTF8, таблицы каждая в отдельности тоже UTF8 (приятный гемор, чОткий ход разработчиков, в этом месте было уже весело), скрипт-парсер выставляет set names в 1251, при селекте - вопросы. Повторяю, проблема с перекодировками, она у них генетическая, похоже. Выставлять кодировку на всю СУБД (о ужас) не предлагать, случай как раз из серии тех, когда это не подходит.
Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы, но эти особенности не могут мне позволить этого сделать.
| | |
| |
| 6.21, Аноним (-), 18:17, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Ответы на что, на INSERT INTO ... ?
Ответы на селекты. Если база utf8, скрипт вставки выставил set names cp1251 и передает данные в cp1251 - то в базу всё попадает правильно (т. е. конвертится в ту кодировку, в которой таблицы - utf8 в данном случае). Скрипт который делает селекты должен выставить set names в ту кодировку, в которой хочет данные получать.
>Почему такого геморроя нет в постгресе? И не надо брызгать слюной, как
>один молодой и неокрепший выше, я _хочу_ использовать mysql, поскольку наши
>девелоперы (которым в дальнейшем сопровождать) с ним хоть немного но знакомы,
>но эти особенности не могут мне позволить этого сделать.
Это не геморрой, просто один раз достаточно понять, как в mysql построена работа с кодировками. На самом-то деле проблема гроша выеденного не стоит. Единственный реальный косяк с их стороны был в миграции с 4.0 на старшие ветки, но это уже в далеком прошлом. Ну и может недостаточно хорошо в мануале все написали.
И кстати возможность контролировать кодировку вплоть до столбцов в одной таблице в некоторых ситуациях очень и очень выручает.
| | |
| 6.25, angra (ok), 09:40, 25/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Повторяю, проблема с перекодировками, она у них генетическая, похоже
Проблема в ДНК тут скорее у того, кто не осилил чтение документации, а вместо себя винит разработчиков. Почему-то у тех, кто затратил хоть немного времени на беглый просмотр доки по этому вопросу, проблем с кодировками в мускуле не возникает. Причем в куда более экзотических случаях. Также не стоит ругаться на фичи, если их не понимаешь. Не нужны тебе, так не используй, никто за уши не тянет. А вот мне приходилось работать с базой, где поля в пределах одной таблицы имели разную кодировку. И представь себе никаких проблем с дампами(как csv так и sql) или приложением, которое кстати и адаптировать пришлось аж в одном месте. Как легко догадаться этим местом был запрос с set names.
Но конечно некоторым балбесам удается указать поле latin1, запихать в него cp1251, а потом ругаться на мускул, который следует дословно их указаниям, вместо чудес телепатии. Кстати для таких в доке мускула тоже есть инструкция по исправлению подобных косяков.
| | |
|
|
| 4.14, нео (?), 01:58, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>База UTF8, set names в кодировку исходного текста делал. при селекте данных
>вопросики. ЧЯДНТ? Тот же скрипт переделан на постгрес (заменены функции mysql_*
>на pgsql_*) - всё отлично.
вот, подсказали - надо не в исходную set names делать
вот проверь свой create table statement:
show create table mytable
там должно быть что то вроде
CREATE TABLE 'stats_global' (
'mailing_id' int(11) NOT NULL default '0',
'sentdate' datetime NOT NULL default '0000-00-00 00:00:00',
'html_sent' int(11) NOT NULL default '0',
'text_sent' int(11) NOT NULL default '0',
'html_read' int(11) NOT NULL default '0',
PRIMARY KEY ('mailing_id')
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
вот у тебя внизу наверняка не utf8, а cp1251, а ты лепишь инсерты с utf8
| | |
| |
| 5.15, GateKeeper (??), 09:44, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да, про то, что кодировку на базу выставить недостаточно, надо на каждую таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные данные в cp1251, табличные данные в базе - в UTF8. Вывод в последующем - в UTF8. Постгрес с задачей справился, но его у нас никто не знает, поддерживать придётся самому. А мускль выдает вопросы вместо букв. В общем, как была проблема с перекодировкой, так со времен древних релизов и осталась.
| | |
| |
| 6.17, нео (?), 14:35, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.
Разве н еочевидно, что база данных не имеет права тратить время на телепатию в виде автодетекта входной кодировки и автопреобразование в нужную?
Думаю, вам было бы полезно почитать man iconv
| | |
| |
| 7.18, GateKeeper (??), 15:38, 24/05/2009 [^] [^^] [^^^] [ответить]
| –1 +/– |
Читаем внимательнее, телепаты могут спать спокойно. Все нужные указания мусклю были даны: что в базе, что в принимаемых данных. Мускль тупо забил на эти указания.
| | |
| |
| 8.19, нео (?), 17:39, 24/05/2009 [^] [^^] [^^^] [ответить] | +/– | Вы же сами сказали - база utf8 включая таблицы а вы совали cp1251 Это нормаль... текст свёрнут, показать | | |
| |
| 9.20, нео (?), 18:13, 24/05/2009 [^] [^^] [^^^] [ответить] | +1 +/– | Вот спецом сейчас проверил, благо сайты переезжают с виртуалки на дедик сегодня ... текст свёрнут, показать | | |
| |
| |
| |
| 12.28, нео (?), 16:53, 25/05/2009 [^] [^^] [^^^] [ответить] | +/– | Очень рад, что вы все же соизволили разобраться в вопросе Потому что из-за таки... текст свёрнут, показать | | |
|
|
|
|
|
|
| 6.22, Аноним (-), 18:22, 24/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Да, про то, что кодировку на базу выставить недостаточно, надо на каждую
>таблицу отдельно (дополнительно к базе), это уже понятно. Собственно, требовалось: исходные
>данные в cp1251, табличные данные в базе - в UTF8. Вывод
>в последующем - в UTF8. Постгрес с задачей справился, но его
>у нас никто не знает, поддерживать придётся самому. А мускль выдает
>вопросы вместо букв. В общем, как была проблема с перекодировкой, так
>со времен древних релизов и осталась.
Да не важно, в какой кодировке данные в базе. Если нужно вставлять в кодировке X, то перед вставкой - set names X. Если нужно получать в кодировке X - то перед селектами set names X.
А кодировку на таблицу можно не выставлять - таблица наследует кодировку от базы, столбцы в таблице - от самой таблицы.
| | |
|
|
|
|
|
| 1.3, vadiml (?), 09:54, 23/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
> включающей в себя два новых движка - Falcon и Maria
Это особенно забавно в свете того, что основные разработчики Maria теперь работают в Monty AB
| | |
| |
| 2.5, User294 (??), 14:36, 23/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
А учтя что если ничего не сорвется то оракл будет хавать санки - очень интересно как это они в бардаке от перетрясок вдруг смогут часто релизить что-то качественное и быстро.Декларации это круто.Ну а что будет на практике - посмотрим...
| | |
|
| 1.9, uldus (ok), 21:48, 23/05/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Сдается мне, что пользуясь суматохой в связи с покупкой Sun'а разработчики MySQL пытаются реформировать процесс разработки. Community версию реанимировали, давно набившие оскомину девелоперские ветки в нормальный вид привели. В sun-е сейчас золотой месяц, старому руководству уже на все наплевать, можно самые смелые идеи протолкнуть.
| | |
| |
| 2.13, Аноним (-), 01:24, 24/05/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ага, плюс влили патчи от гугла в ветку 5.4, в общем очень радует происходящее.
| | |
| 2.26, uZver (ok), 10:39, 25/05/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Inside info:
Sun давно уже пытается реформировать процесс MySQL - сейчас стали видны результаты и для "внешних" потребителей.
| | |
|
|
