Добрый всем вечерок!

Пытаюсь решить с хостером одну проблему.
Дело в том, что при закачке старой базы на хост возникла проблема с кодировками - страницы идут крякозябрами. Налицо проблема несоотвествия локали мускула и базы.

Хостер по всем данным просто отменный, но к сожалению, никак не достигнем консенсу - кто из нас чего должен делать - то ли я код портала должен править, то ли хостер должен локаль корректировать.

Прошу нас объективно рассудить. Что касается моего мнения - правка кода программного продукта ради приспособления к особенностям сервера - недопустима.
Ведь есть софт, лицензия которого запрещает вмешательство в его код.

Mimino,
В mysql 4.x выставление кодировки скриптом на самом деле обязательно если скрипт правильный.
Если лицензия какого-то софта запрещает менять его код, то разработчики должны озаботится возможностью выставлять кодировку правильно не меняя код.
Насколько мы понимаем, какую бы кодировку хостер не установил для БД, все равно всем пользователям виртуального хостинга придется ее использовать.
Возможно, альтернативным выходом может быть исходная заливка sql дампа в базу хостера в кодировке дефолтной для сервера. Хотя тут можем ошибаться.

В идеале это так, но если разработчик не озаботился? И вообще, если каждый клиент при переездах вынужден занятся малопонятными правками, то они на это не пойдут - зачем им лишние проблемы?


Так-то оно так, но как это осуществить? Предложил хостеру озаботиться автокодировщиком для таких случаев, но ответа пока нет.
И дефолтная кодировка у него неудачная - латиница, хоть бы какая-то кирилица была, и то легче.

И еще - не знаю как , но на прежнем хосте на одном и том же физическом сервере у меня одновремено вертелись базы с 1251 и utf.

Теоретически разработчик может много чем не озаботится. Например безопасностью своих скриптов, но при рассылке спама из-за дыр в них - отвечать будете Вы, а виноват будет скрипт. Нам кажется здесь та же аналогия.

1) какая версия хоть MySQL? Без знания версии как то все бесполезно советовать
2) Считается что хостер должен заботится о ВСЕХ клиентах. Следовательно можно принять за основу что если у него стоит кодировка latin1 это объясняется какими то вескими причинами. Конечно, хостеры бывают разные, но, скажем получить ответ а правильно заданый вопрос, вполне даже можно. Нужно только не наезжать сразу, а просто поинтересоваться.

А куда ссылка на тикет пропала из первого поста? Там была инфа по вопросу. Да и вроде сам тикет прибит

1) MySQL 4.1.18-standard-log
2) Никакого наезда - целый день дружелюбно общаемся с поодержкой, пытаясь решить проблему. Но к сожалению, до сих результатата нет, поэтому и обратился на форум.
Единственный совет по правке кода портала я никак не могу принять, поскольку:
- С одной стороны, этими правками бужут вынуждены занятся все мои клиенты, и у всех будут разные системы у одного один портал, у другого другой, у третьего блог, и т.д.
Ни они, не я не знают все многообразие систем и их версий, и готового рецепта для них никто не сумеет дать. В результате все плюнут на эту проблему, и проголосуют ногами.
- С другой - ни один разработчик CMS не обрадуется такой "правке кода" ради совместимости с сервером. Я их знаю - стоит мне заикнуться, они тут же забросают помидорами и меня, и моего хостера.

Но вот, ближе к ночи хостер выдал новую идею, которая мне очень понравилась:

Запрос выполнился, но к сожалению, результатов не дал.

На очереди следующая идея - "Универсальный конвертор кодировок баз".
Кто-нибудь встречал такое?


PS. А тикет прикрыл хостер, потому что в нем стала хамить заблудившаяся малолетка.
Поэтому лучше общаемся здесь.

Найти mysql_connect, поставить после него mysql_query который посоветовал хостер.
Если из по помидоров вылезете, то огребете благодарности Ибо приколы с кодировками это приколы не одного хостера.

Если верить http://phpclub.ru/faq/wakka.php?wakka=Mysql41Rus (и если мы правильно там поняли), то возможно не дал результата этот запрос постольку, поскольку юзер которым коннектитесь имеет привелегии ALL (1-ый случай, решение 2).
А Ваши пользователи не проголосуют ногами кода поймут что им надо конвертить свои базы? Как вариант можем предложить попробовать следующий способ. Делаете дамп с помощью http://zapimir.net , после этого заливаете дамп в новую базу. Мы так плавно переходили с 3.х на 4.х где-то, как раз не пришлось заморачиваться с кодировками. Только в самом скрипте дампера не забывайте кодировку выставлять правильно. При слитии - нужную для слития, при залитии - нужную для последующей работы.

тут немножко другое тогда. вообще для 4.1 и 5.0 говорить о том что хостер там чего то выстваил не так, не совсем правильно если честно. ибо эти ветки мускуля работают внутри себя в utf8.
следовательно все остальное получается преобразованием из этого треклятого utf8 в другие кодировки. засим необходимо сконвертировать базы так чтобы они легли так как вам надо. все это делается подбором charset & collation. честно скажу что сам в этом плаваю и каждый раз приходится мучительно вспоминать куда и что втыкать, но, к сожалению, других вариантов нет, как это осваивать. оказываться от этого mysql Gmbh не собирается.
самый тупой и надежный способ, если у вас в phpmyadmin русские текста в базе читаются по русски нормально - это сразу после строчки соединения с базой где нибудь в коде скрипта прописать скажем sql_query("SET NAMES CP1251"); Это надо сделать один раз в том месте где скрипт коннектится к серверу баз данных. То есть этот запрос должен идти самым первым, впереди всех остальных.
Также можно попинать хостера чтобы он включил на сервере в целом дефолтную кодировку cp1251. Но, на самом деле это не совсем правильный подход, потому что получится как раз навязывание настроек сервера юзеру. Если ничего не назначать то любой юзер может работать в любой кодировке и с любым языком каким захочет.

> А Ваши пользователи не проголосуют ногами кода поймут что им надо конвертить свои базы?

Конвертить базы, если есть готовый конвертор - вряд ли, а вот править код портала - это точно!

> Делаете дамп с помощью http://zapimir.net
Дампер? Так в основном ним только и заливал, и когда уперся в тупик, снова вернулся на майадмин

> sql_query("SET NAMES CP1251"); Это надо сделать один раз

Ага! На этом портале - раз, на другом - два, и понеслась...
Что скажут мне клиенты, которые будут вынуждены менять свои коды?

А в чем тупик был? Мы так делали. Сдампили. Создали базу в дефолтовой/нужной кодировке. Подправили в дампере кодировку на дефолтовую. Залили.

О боже. Прочёл - чуть не помер (толи от смеха, толи от ужаса).
На 97% уверен что просто коряво залили нормальную базу на нормальный сервак. Править никаких кодов никому не надо.
Вопрос решается в 15 минут, на самом деле.

По порядку:
В какой кодировке работает сайт от которого база?
Какой размер базы?
SSH-доступ есть?
phpMyAdmin есть?
  В phpMyAdmin залитая база отображается крокозяблами или знаками вопроса?
В phpMyAdmin смена кодировки браузера работает или игнорится?
В phpMyAdmin смена кодировки базы работает или игнорится?

з.ы. При наличии SSH как правило вообще ничего не приходится конвертить, так как базу можно заливать в указанной кодировке.
з.ы.ы. Вот из-за таких проблем мы всегда предлагаем самим перенести базы клиентам, а то напортачат и разгребай потом неделю не имея доступа к старой, уже удалённой, базе.