|
Задавайте вопросы, мы ответим
Вы не зашли.
В начале октября у (Хостинг Центр) был какой-то сбой, сайт не могли подключиться к БД.
Потом все заработало, но кодировка стала не той что была... Русские символы, кириллица из полей БД-вся в виде ?????
У меня 2 сайт на одном домене. использую CMS Textpattern который в БД записывает поля в UTF и так было всегда.
Но видимо после сбоя настройки сервера поменялись.
Как вот мне теперь поступить?
В бд я смотрю все данные в юникоде, но например MyISAM /*!40101 DEFAULT CHARSET=cp1251 */;
В настройках через phpmyadmin я вижу:
character set client utf8
(Глобальное значение) cp1251
character set connection utf8
(Глобальное значение) cp1251
character set database cp1251
character set results utf8
(Глобальное значение) cp1251
character set server cp1251
character set system utf8
character sets dir /usr/local/share/mysql/charsets/
collation connection utf8_unicode_ci
(Глобальное значение) cp1251_general_ci
collation database cp1251_general_ci
collation server cp1251_general_ci
тоесть в основном все настроена на 1251
я пробовал задать Collation/SET NAMES но это не дало ничего, пытался через клиент поменять переменные, но ведь у меня нет прав, хостинг-то виртуальный...
Отредактированно Vlado (05.08.2018 09:25:52)
Неактивен
Попробуйте написать запрос:
SHOW VARIABLES LIKE 'char%'
или
SHOW GLOBAL VARIABLES LIKE 'char%'
Он покажет все системные переменные связанные с кодировками.
А потом попробуйте задать переменную, которую хотите поменять, если конечно в этом проблема, например
SET character_set_client=utf8
или
SET GLOBAL character_set_client=utf8
Отредактированно nightssss (15.10.2009 23:51:40)
Неактивен
Важно не то, что в phpmyadmin, а то, что в настройках подключения
приложения (php, я так понимаю?). SET NAMES utf8 вполне достаточно
при условии, что данные там действительно записаны в utf8.
В phpmyadmin русская информация отображается правильно?
Неактивен
nightssss, хотел попробовать, но...
утром в 8:30 стал пробовать и не смог даже в РМА войти, вместо всего пишет
#2013 - Lost connection to MySQL server during query. Database unavailable.
Вот и платный хостинг называется. Как бы теперь выбрать?
paulus: В РМА поля отображаются не корректно...
Неактивен
Тогда, скорее всего, нужно писать в поддержку хостинга 
По Вашему описанию сложилось такое ощущение:
1. Раньше у них был MySQL версии 4.0 и Вы писали в базу с кодировкой utf8.
2. Потом случилась проблема, и они обновили MySQL до версии 5.0+. Различие версий — в поддержке кодировок.
3. Соответственно, они запустили сервер с default character set = cp1251, наплевав на кодировки, которые реально есть в базе данных.
4. Ну и поэтому у Вас ничего не работает.
Если гипотеза правильная, то «SET NAMES cp1251» после подключения из php-приложения спасет Ваши данные (MySQL увидит одинаковые кодировки со стороны данных и подключения и не станет их перекодировать). При этом они будут приходить в кодировке utf8 (в той, в которой были записаны на диск). Впрочем, phpMyAdmin все равно будет показывать их криво.
Неактивен
paulus написал:
«SET NAMES cp1251» после подключения из php-приложения спасет Ваши данные
увы, я не знаю как это делается. За 2 недели неработающего mysql, понял всего ничего, и единственное умею в РМА "запросы" базе посылать...
хостинг центр едва на днях дал вразумительную рекомендацию, но опять же в общих словах, что не решает вопроса.
сейчас поразмыслив и поискав, нашел для своей CMS (textpattern), куда добавлять
написал:
mysql_query("set names utf8");
mysql_query("set character set client=utf8");
mysql_query("set character set database=utf8");
mysql_query("set character set server=utf8");
mysql_query("set collation database=utf8_unicode_ci");
mysql_query("set collation server=utf8_unicode_ci");
Но по прежнему ничего не изменилось. плюс никак в РМА не могу войти.
кажется наступает полная путаница. назревает или создание БД заново, не знаю есть ли смысл или переход на другого провайдера.
Отредактированно Vlado (16.10.2009 22:34:40)
Неактивен
Вам ведь написали, что нужно указать «SET NAMES cp1251», а вы зачем-то пишите "set names utf8".
Для понимания сути проблемы рекомендую посмотреть статью Обновление сервера 3.23 и 4.0
Неактивен
vasya: Я и mysql_query("set names cp1251"); писал, проблема оставалась. просто незнание и логика говорят что все в UTF надо ставить
Неактивен
Вывод команды SHOW CREATE TABLE tablename (с реальным названием таблицы,
разумеется) покажите, пожалуйста.
Неактивен
Угу, похоже, мои предположения таки правильные. В метаданных у Вас написано, что кодировка
cp1251, а реально там кодировка utf8 (по Вашим словам). Соответственно, нужно делать
SET NAMES cp1251 и ожидать, что данные будут приезжать при этом в utf8. Пробуйте, должно
получиться.
Ну а в хостинг нужно написать, что они были кардинально неправы, когда такое сделали.
Неактивен
paulus: в хостинг я уже писал, они сначала начали отмазываться, но потом признались что ошибка их. пока вот только на этом остановилось все.
сейчас попытался снова к себе зайти, опять Database unavailable и т.д. вчера еще хоть был момент когда работало.
написал трем хостинг-конкурент, все предлагают дешевле и с радостью свои услуги.
вопрос о переносе меня только смущает.
может я не там пишу SET NAMES cp1251 ? может в самой БД есть "инициализующий код" а не в моем PHP приложении?
в CMS я вставляю в файл, который задает параметры доступа к БД. во всей CMS все параметры стоят и стояли UTF...
Отредактированно Vlado (18.10.2009 09:04:54)
Неактивен
Может вы не везде побороли параметры своей CMS. Попробуйте положить отдельный файлик php и посмотрите результат.
Неактивен
Vlado написал:
заполнил поля как надо, загрузил, запустил, но мне выдается:
Да, я протупил малость. Нужно ведь ещё подключиться к базе.
$db_connection = mysql_connect($dbserver, $db_username, $db_password) or die(mysql_error());
$result = mysql_select_db($dbname,$db_connection) or die(mysql_error());
Ну и естественно незабыть указать имя базы данных.
P.S. Обратите внимание, что этот скрипт нужно исполнять без использования вашей CMS.
P.P.S. У вас есть возможность сделать дамп с помощью утилиты mysqldump, а не средствами phpadmin.
Неактивен
Ну что же мы убедились, что в базе данные не пострадали.
Осталось только сделать дамп, указав кодировку соединения cp1251, чтобы сервер не перекодировал данные при создании дампа. Затем руками поправить дамп, указав что данные находятся в utf8. Подробнее см. статью Обновление сервера 3.23 и 4.0
И переезжать на новый хостинг
Неактивен
подождите. не понимаю логики.
судя по всему, средствами php можно настроить вывод данных в нужном виде. вот только как CMS настроить) или я что-то не понимаю?
зачем создавать дамп? зачем менять провайдера?
Неактивен
Из этого
Vlado написал:
сейчас попытался снова к себе зайти, опять Database unavailable и т.д. вчера еще хоть был момент когда работало.
написал трем хостинг-конкурент, все предлагают дешевле и с радостью свои услуги.
вопрос о переносе меня только смущает.
я сделал вывод, что вы хотите сменить хостера, но не знаете как перенести свои данные.
Настроит вывод данных средствами php конечно можно, а что касается настроики вашей CMS ничего сказать не могу.
В любом случае продолжать хранить данные в utf8, когда сервер считает, что они в cp1251 неправильно. Рано или поздно (скорее рано) это приведет к проблемам. Самый простой путь - метод резервных копий (см статью).
Неактивен
мне проще все перенастроить и пользоваться кривой сейчас...
перенос еще и стопориться тем, что конкуренты предлагают услуги по другим ценам, но не все лучше.
итак, если уже дело дошло до того, что нужно теперь все хранить в 1251 (или попробовать испугать хостера?)
я могу дамп перекодировать\поправить не через оболочку а другими средствами и залить все снова? если да, то кроме настроек wvc что из актуальных сейчас надо будет менять?
блин, все на utf переходят а хостер на старье((
в данный момент:
SHOW VARIABLES LIKE 'char%'
Variable_name Value
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_results utf8
character_set_server cp1251
character_set_system utf8
character_sets_dir /usr/local/share/mysql/charsets/
SHOW GLOBAL VARIABLES LIKE 'char%'
Variable_name Value
character_set_client cp1251
character_set_connection cp1251
character_set_database cp1251
character_set_results cp1251
character_set_server cp1251
character_set_system utf8
character_sets_dir /usr/local/share/mysql/charsets/
Неактивен
Vlado написал:
итак, если уже дело дошло до того, что нужно теперь все хранить в 1251 (или попробовать испугать хостера?)
Вы не так поняли. Вы можете хранить данные в utf8, главное, чтобы сервер понимал, что это utf8, а не считал, что данные находятся в иной кодировке (например, cp1251, как сейчас).
Давайте вы все-таки прочитаете статью. Автор думал, слова придумывал и, кстати, очень подробно все расписал
Неактивен
с помощью службы поддержки вроде все наладилось,
надеюсь на долгие годы)),
восстановлением БД с нужными параметрами и ее переконвертацией.
Неактивен
