- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
сегодня зашел на один из своих блогов и с ужасом обнаружил, что вместо текста - кракозябры. подозреваю, что хостер пошаманил над своей базой. через phpmyadmin посмотрел - кодировка в таблицах выставлена в latin1_swedish_ci - что я только не пробовал - менял кодировку в таблицах, мнеял кодировку подключения к mysql. на cp1251, на ut8_unicode_ci, на swedish - безрезультанто. сам блог (на вордпрессе), как известно, выдет в unicode (utf8) - текст на русском, что хранится не в базе - отображается нормально. сами посты - крякозябры. менял кодировку и в самом браузере - не помогает, сливал и заливал дамп базы с параметарми set character_set_client='cp1251';
set character_set_results='cp1251';
set collation_connection='cp1251_general_ci'; - как раз в соседней теме проскочило это. безрезультатно. в свое время была похожая пробелма. тогда выставлял set names cp1251 к примеру. сейчас же = не катит. что делать? есть ли возможность восстановить данные в нужной кодировке? iconv использовать не хочется - да и не знаю как весь дамп базы им переконвертить.
Кракозябры тоже разные бывают :)
Поконкректней бы, а лучше ссылку на сайт.
То что ты видешь на сайте отличается от того что в базе или те же самые кракозябры?
Да-да, ссылку нуно. МОжет просто браузер не настроен у кого-то... ;)
Попробуйте так
mysql_query("SET CHARACTER SET cp1251");
mysql_query("SET NAMES cp1251");
Сразу после соединения с бд.
да и не знаю как весь дамп базы им переконвертить.
Переконвертить можно в обычном блокноте от windows :)
Файл -> Сохранить как -> Кодировка
Переконвертить можно в обычном блокноте от windows
Файл -> Сохранить как -> Кодировка
В частности, из win-1251 в юникод конвертит криво. Единственная фришная программа, которую я нашел, которая это делает корректно - AkelPad.
А что за хостер? У меня такая же ситуация была с Нетплейсом.
Тогда я восстановил базу из бекапа...
Revan,
умный, да?
сайт www.pxty-basket.com - проблема с юникодовской кодировкой. движок wordpress. не хочу в нем ковыряться, чтобы подключение к базе менять. хостер левый.
я вообще боюсь, что восстановлению не подложети это дело. когда вместо букв - одни вопросы, то и при конвертации зачастую это в те же вопросы и превращается.
Надо бы для начала определиться со всеми параметрами, установленными в данный момент. То есть, пойти, например, в phpmyadmin, выполнить SQL-запрос
SHOW VARIABLES LIKE 'character_set%'
и увидеть, например, вот это:
character_set_connection utf8
character_set_database utf8
character_set_results utf8
character_set_server utf8
character_set_system utf8
или что-то иное.
Далее выполнить
SHOW VARIABLES LIKE 'collation%'
и увидеть, например,
collation_database utf8_general_ci
collation_server utf8_general_ci
Скорее всего, будет не так.
Лично у меня из знаков вопроса никогда и ничего восстановить не удавалось. Соответственно - надо выяснить причину, а дальше - либо поменять настройки, либо переконвертить базу.
Возможно, Вам будет небезинтересно, как я решил проблему кодировок.
Jackyk, спасибо, я уже читал твою тему. на самом деле действителньо - когда столкнулся с пробюлемой - никто ничего толком посоветовать не может. даже, видимо, сами разработчики. а все из-за того, что намудрили с кодировками. видите ли, можно задавать кодировки при подключении, кодировку базы, табилц, и даже полей. конечно, из-за всей это каши и будет неразбериха. англо-язычного контента это не касается - там в любой кодировке латиница отображаться будет, а вот с кириллицей проблемы.
Ну так а всё же - что дают запросы:
SHOW VARIABLES LIKE 'character_set%' и
SHOW VARIABLES LIKE 'collation%' ?
Важно же причину понять, а именно в подобной нестыковке она и может быть. Ведь раньше-то у Вас всё работало. Как вариант, что-то апгрейдили на хостинге, и что-то задали по-другому.