Сoncrete5 Russia

хостинг то хостинг, но клиент сам должен грамотно настраивать сопоставления для конкретного соединения. И исходя из того ,что хостер прописал $conn -> exec("set names utf8"); можно сделать вывод, что не везде стоит utf8 или где-то есть ошибка в классе. Прямые руки у разработчиков никто не отменял!

Согласен, приямые руки никто не отменял. Однако, вот такая строчка $conn -> exec("set names utf8") требуется когда сопоставление кодировки клиента и сервера не сделано. Мы такую фигню проходили много лет назад с Joomla на том же мастерхосте, тоже ручками изменения в класс Database вносили. Потом они научились настраивать и надобность пропала, а тогда замечу ни о каком utf-8 речи не шло.

night_terror писал(а):хостинг то хостинг, но клиент сам должен грамотно настраивать сопоставления для конкретного соединения. И исходя из того ,что хостер прописал $conn -> exec("set names utf8"); можно сделать вывод, что не везде стоит utf8 или где-то есть ошибка в классе. Прямые руки у разработчиков никто не отменял!

Сам факт возникновения данной ошибки говорит об "особенностях" хостинга.
Почему то у других хостингов (российских и зарубежных) все нормально ставиться без подобных костылей.

P.S. Сомневаюсь что разрабы доктрин и с5 наговнокодили. Ведь в настройках БД указана кодировка, но почему то его не хватило.

guyasyou писал(а):P.S. Сомневаюсь что разрабы доктрин и с5 наговнокодили. Ведь в настройках БД указана кодировка, но почему то его не хватило.

Во во. Вообще у mysql есть такие параметры:

• character_set_client — указывает, в какой кодировке будут поступать данные от клиента;
• character_set_connection — указывает, в какую кодировку следует преобразовать данные полученные от клиента перед выполнением запроса;
• collation_connection — указывает, каким образом сравнивать между собой строки в запросах;
• character_set_results — указывает серверу не необходимость перекодировать результаты запроса в определенную кодировку перед выдачей их клиенту.

Правильное их выставление дает необходимый результат, а когда руки кривые у админа, то приходится их выпрямлять костылями в виде SET NAMES которые принудительно говорят в каком виде клиент данные будет отправлять и получать.

set names выставляет character_set_client, character_set_connection, character_set_results - как-то так -

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

. И если бы cms их правильно выставляла, то все было бы ок.
И начиная с версии mysql 4 с появлением всей этой фигни считалось правильным указывать кодировку клиента через set names и создавать таблицы с указанием правильной кодировки. Вопрос в том, что разработчик должен это предусмотреть. Это, например, часто касается буржуйских разработчиков, которые кроме ASCII ничего не знают.

Еще один хостинг с этой проблемой:

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

guyasyou писал(а):Еще один хостинг с этой проблемой:

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

Там у меня есть один сайтик, никаких проблем не наблюдается. Всё нормально вроде.

На 5.7? Такие вещи, по-моему, именно на 5.7 наблюдаются.

guyasyou писал(а):На 5.7? Такие вещи, по-моему, именно на 5.7 наблюдаются.

Ааа, ну да, там же на 5.6.

Столкнулся с этой же проблемой у этого хостинга:

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

guyasyou писал(а):Столкнулся с этой же проблемой у этого хостинга:

Пожалуйста зарегистрируйтесь, чтобы увидеть ссылку

С этими связываться не советую, у них раньше были проблемы с безопасностью.

да и подороже среднего по рынку у них тарифы