Как решить проблему с кодировками mysql/php на новом хостинге?
Есть один проект, на локалке и старом хостинге все работает замечательно. Так как ресурсов старого хостинга не хватало, и более высокого тарифа уже не было, перенёс на новый хостинг. Работаю с utf8, на сайте информация отображается с помощью jquery ajax.
Начались проблемы с кодировками. Изначально, база данных mysql с кодировкой utf8mb4_general_ci, таблица utf8_bin - всё это отлично работало на старом хостинге и какое-то время на новом. Потом смотрю в БД каша:
На сайте некоторые слова выводятся так �?нформация, в базе данных отображены так полной информации (и в таком же виде приходит ajax-ответ от скрипта).
Хотя на локалке всё чётенько, на локалке в phpmyadmin вижу русские слова, а не полной информации.
header('Content-Type: text/html; charset=UTF-8'), <meta charset="utf-8"> всё это есть.
Jean-Claude, встречались и отображались ли правильно аналогичные строки до переезда? Вносились ли изменения в код после переезда? Откуда в базу попадают подобные строки — ручной ввод, форма на сайте, внешний скрипт?
Я не настоящий сварщик, если что,) Но должна же быть логика.
Александр, нет, до переезда все было хорошо, изменения в код не вносились. Единственно что заметил сейчас, на страром хостинге были таблицы innodb, а на новом после заливки дампа почему-то myisam стали.
Jean-Claude, по идее, client, connection и results устанавливается при подключении клиентом, тогда следует обратить внимание на остальные. Различие и подозрительная cp1251 видны в двух переменных, но на локалке там тоже не юникод…
Если старые записи в БД выводятся без кракозябр, а новые с ними, тогда проблема где-то при записи новых значений в БД, а не при чтении. Это основная гипотеза, наверно. Значения в БД из php-скриптов попадают? Везде при подключении кодировка указана?
Рандомные идеи: можно попробовать переписать в новом конфиге cp1251 на latin1, сравнить параметры кодировки таблиц в новой и старой БД, провести сравнительное испытание — добавить "кракозяброгенные" данные в новой и старой БД и проследить, как изменяются данные на разных этапах.
да, проверил, старые записи выводятся без кракозябр. Значения в бд попадают из 1 скрипта, да там указано в new PDO(dsn ... charset=utf8).
к конфигу доступа у меня нет, это же виртуальный хостинг, в общем задал вопрос хостеру, посмотрим что ответит.
может можно phpstorm'ом дебажить скрипты запущенные на хостинге? тогда бы бяку найти проще было, но я не знаю как.
Jean-Claude, подозреваю, что для удалённой отладки надо XDebug на удалёнке и что-то вроде ssh-туннеля с перенаправлением портов, но, опять же, я не сварщик.
Можно версии PHP и MySQL посравнивать ещё. А то, говорят, до PHP 5.3.6 PDO игнорирует charset. А то ещё всякие --skip-character-set-client-handshake на сервере бывают… Полагаю, этот момент можно выяснить, если запросить SHOW VARIABLES LIKE 'char%';изнутри тестового скрипта, в котором предварительно инициализировать PDO как в основном скрипте.
версия последняя 5,6,40
уже имитировал на локалке конфиг как у хостера character_set_server=cp1251
и все работает хорошо.
хостер ничего внятного сообщить не смог, то предлагает подключаться с cp1251, то изменить везде collation, запросил у него информацию о флаге skip-character-set-client-handshake
Средний
