Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?
Залил сайт на McHost. Импортировал базу данных, все прошло успешно. При создании таблицы указал, что кодировка - utf8_general_ci. Но когда я ввожу данные и отправляю - выходит что-то непонятное. В тех. поддержку обращался - они заявили, что не знают. Можете помочь?
SHOW VARIABLES LIKE 'char%';
SHOW VARIABLES LIKE 'coll%';
и сравнить. Несинхронно? перенастроить.
Далее - проверить, нормализовалось ли, но не из PHP, а строго из CLI, причём при одинаковом CHCP. Неровно? Скорее всего криво залил, при неровных настройках, перезалей.
Ну а дальше уже настройки PHP и браузера - тут я пас.
При подключении к базе данных нужно тоже кодировку указывать
Ну скорее можно, чем нужно. А вот что действительно нужно - так это правильно настроить. Как клиентскую секцию INI-файла сервера, так так и параметры соединения в приложении. И тогда дополнительно указывать ничего не нужно.
Конечно, всё это при условии, что есть административный доступ к управлению сервером. Ну а если нет - тогда да, костыли, куда деваться.
Akina, я бы сказал - нужно, ибо мы заранее не знаем, какая на сервере MySQL кодировка по умолчанию стоит, полагаться на дефолтную опасно (в старых версиях MySQL там latin1 по дефолту была).
Разве что скрипт запускается на сервере, который мы целиком и полностью настраивали и переопределяли в настройках MySQL кодировку по умолчанию (и уверены, что никто в будущем не перенастроит её).
Но вот то, что не настраиваем свойства соединения, а даём дополнительные команды (причём даже не опять-таки в свойствах соединения - там есть место для доп. команд при установлении связи,- а из клиентского кода) - вот это совсем даже не логично.
Особенно если учесть такую мелочь, что результат выполнения команды SET NAMES локален для соединения. Так что если используется пул соединений, или если посередь процесса соединение порвётся и будет автоматически восстановлено, то результат выполнения команды останется "где-то там"...
