Проблема русского оформления

[AnrDaemon]

Нет Вернее, не обязательно.
Параметры подключения имеют приоритет над конфигами. А уж откуда подключение берёт параметры, это вопрос отдельный.

[vboxer]

В общем это проблема "заложенная" изначально (собственный косяк- не пользовался раньше хостингами, работал только с живыми серверами), первые конфиги мускула были в CP 1251. Таблицы создавались в utf. Теперь видимо через кучу преобразований идет неправильная выгрузка, копаю мускул в консоли в попытках привести таблицы и базу в норму, к единной так сказать кодировке. Преобразование БД из консоли отображает результат выполнения и базу выдает уже как utf8, при этом в ПХП админке и при выгрузке все равно часть таблиц в cp1251 или изначально крякозябренно. Думаю, что это уже песня для другой темы и не зависящая от Ubuntu.
Спасибо за помощь, хотя бы нашел куда, что и где копать.

[AnrDaemon]

В принципе верно, но специфичная кодировка отдельных таблиц не должна создавать проблем вообще.
Особенно если дамп в уникоде.

[vboxer]

В принципе верно, но специфичная кодировка отдельных таблиц не должна создавать проблем вообще.
Особенно если дамп в уникоде.

Однако почему то создало, воюю не по детски. Часть таблиц невзирая на принудительные задания utf8 выгружает себя с cp1251, при этом часть текста оставляет в utf8, ну или наоборот.Хотя на запросы с консоли база утверждает, что с ней все в порядке и она вся такая юникодная
Вообщем не знаю пока точно, где , как и почему вкрался такой вот косяк, но дамп разворачивается нормально только на том хосте где сделан.
Продолжаю пока консолить мускул.

[AnrDaemon]

Дело в том, что в MySQL нет никакой проблемы задать COLLATION хоть поколоночно.
В одной таблице разные колонки будут иметь разный COLLATION.
Вопрос в том, как именно ты выгружаешь И как загружаешь?
mysqldump --default-character-set=utf8
? А при загрузке? База с какой дефолтной кодировкой создана?

[vboxer]

например так, после всяких преобразований

Код: [Выделить]

mysqldump --user=****** --password=****** db > /path/to/file_dump.SQLи так же обратно

Код: [Выделить]

mysql --user=****** --password=****** db_name < /path/to/file_dump.SQL
причем на родном хостинге как я и говорю работает.

База с какой дефолтной кодировкой создана?

utf8 подразумевалось - потому, и вызвало большое недоумение встретить latin и cp1251.

[arrecck]

если с таблицами все норм, то в самих php скриптах может SET_NAMES вызываться
лог мускуля посмотри

[vboxer]

если с таблицами все норм, то в самих php скриптах может SET_NAMES вызываться
лог мускуля посмотри

как раз несколько таблиц оказываются ненормальные, не помогла даже выгрузка -

Код: [Выделить]

mysqldump --user=******* --password=****** *****_forum --allow-keywords --create-options --complete-insert --default-character-set=latin1 --add-drop-table > latindump.sql
Всё равно часть таблиц в вопросиках с ромбиками. а таблиц 191 

[AnrDaemon]

как раз несколько таблиц оказываются ненормальные, не помогла даже выгрузка -

Код: [Выделить]

mysqldump --user=******* --password=****** *****_forum --allow-keywords --create-options --complete-insert --default-character-set=latin1 --add-drop-table > latindump.sql
Всё равно часть таблиц в вопросиках с ромбиками. а таблиц 191 

Шутишь? Конечно будут вопросики и ромбики, когда ты кодировку угробил при выгрузке...

[vboxer]

Шутишь? Конечно будут вопросики и ромбики, когда ты кодировку угробил при выгрузке...

да это был не шаг угробления, выгрузка без параметров или выгрузка с параметров utf8 ничего не меняет, абсолютна такая же.
А преобразование в latin делал в надежде на то что, возможно что когда то были сделанны изминения в БД которые привели к разношерстным кодировкам таблиц, были у меня на хостинге пару сбоев каких то, один раз в результате DDoS, а второй сбой был даже не знаю по какой причине.
из FAQ сайта linux.by:

(Нажмите, чтобы показать/скрыть)

# Узнаём кодировку таблиц (show create table `table`).
# Делаем дамп БД с помощью mysqldump
Допустим, мы выяснили, что таблицы были созданы по умолчанию в кодировке latin1, а фактически в них содержатся данные в utf8. В этом случае используем команду:
mysqldump -uUSERNAME -pPASSWORD DB_NAME --allow-keywords --create-options --complete-insert --default-character-set=latin1 --add-drop-table > dump.sql
Распространненая ошибка в таких случаях - когда в --default-character-set указывают фактическую кодировку данных, в данном случае - utf8. В дампе будет мусор. Указывать надо ту, которая установлена в таблицах. В результате MySQL не будет пытаться данные перекодировать, и отдаст как есть.
# Просматриваем файл с дампом, чтобы убедиться, что в файле нормальные данные в кодировке utf8, а не мусор.

у меня мусор получился.

[AnrDaemon]

Кто такое пишет вообще. Брр, убить мало.
Кодировка таблиц исправляется совсем не так.
Если у тебя (например) таблицы в latin1, а данные в них в cp1251, то...
Заходишь в phpMyAdmin
Открываешь структуру таблички на редактирование.
Меняешь формат строк с VARCHAR/TEXT(сколько-то) на BINARY или BLOB
Сохраняешь.
Меняешь обратно на VARCHAR/TEXT и ставишь реальную кодировку.
ТАК он не будет пытаться конвертировать.

[vboxer]

Спасибо, сейчас опробую.

[AnrDaemon]

Хотя как такое возможно на минимально современной версии MySQL - ума не приложу. Пытался симулировать твою ситуацию - мне сервер не даёт вставить данные в неправильной кодировке...
"Incorrect string format \xF2..."

[vboxer]

Иногда думаю не связано ли это с подъемом версий Мускула и Пхп на хостинге, с полгода назад или даже поболее. Хотя кажется маловероятным.

[AnrDaemon]

Получилось симулировать. Немного через зад, пришлось использовать SET NAMES вместо нормальных переменных.
Совет, который ты цитировал, действительно работоспособен с одной оговоркой - если вся база в одной неправильной кодировке. (Довольно частое событие при многочисленных апгрейдах сервера без должного обслуживания таблиц.)
Но лучше всё таки один раз пройтись и поменять COLLATION ручками, пусть даже и в сотне таблиц...
Не забудь в скриптах, которые тянут информацию, выставить character_set_client=кодировка_страниц (скорее всего cp1251, даже если база в utf8 будет).