Поддержка Проблемы и решения Отображение букв с надстрочными знаками в постах

  • После обновления вордпресс (или после восстановления БД), не уверенна на 100% после чего именно, все буквы, содержащие надстрочные и подстрочные знаки (французский язык) изменились на знаки вопроса. Например: Français — Fran?ais, то же с буквами é à ê ï и т.д.
    Подскажите, пожалуйста, можно ли избежать подобных изменений. Это проблема кодировки или что?
    Заранее спасибо

Просмотр 13 ответов — с 1 по 13 (всего 13)
  • Модератор Юрий

    (@yube)

    Кодировка, конечно. Посмотрите для начала в базе данных, всё ли там на месте.

    Спасибо за оперативный ответ. Если можно, уточните, пожалуйста, что именно нужно сделать.

    Я правильно поняла, что нужно через cPanel зайти в Базы данных My SQL? Там зашла, запустила проверку, появился список с пометкой возле каждого поля ОК.

    Или нужно идти в phpMyAdmin и смотреть там? А что именно смотреть, как я пойму, все ли на месте?

    Модератор Юрий

    (@yube)

    В PMA посмотрите, на месте ли «умляуты» в записях.

    И дайте адрес странички, где можно посмотреть проблему. А то искать по Вашему сайту (fle4u.com — он?) очень трудно — можно заснуть, пока что-то откроется.

    В PMA тоже вопросы вместо знаков.
    Вот, например, там вставка анонса передачи на французском. Раньше нормально было, потом значками, затем я поправила руками все через редактирование записи, а сейчас опять вопросы.

    Также обзор пособий, да и в добро пожаловать тоже есть значки.

    Вы меня прям расстроили, что так тормозит? У меня нормально открывается все. Ну, может, не летает, но в принципе нормально. Почему так?

    Нашла на одном из французских сайтов ответ. Только не соображу, что конкретно сделать надо.
    Оригинал тут: см. ответ Francescu

    Вот перевод ответа:
    Проблема замены значков на ? происходит от того, что кодировка страницы в UTF8, но данные в латинице. Прежде чем восстановить данные (после соединения с mysql сделай mysql_query(«SET NAMES UTF8»);

    Далее идет ссылка.

    Насколько я понимаю, по ссылке нужно проделать то, о чем идет речь в пункте MySQL

    • Прочитайте статью
    • Измените классификацию (не уверена, что правильно перевела interclassements — взаимная классификация?):
    1. Базы: ALTER DATABASE имяБазы CHARACTER SET UTF8
    2. Таблиц: ALTER TABLE имяТаблицы CHARACTER SET UTF8
    3. Колонок: ALTER TABLE имяТаблицы CONVERT TO CHARACTER SET UTF8
    4. Это изменит все колонки таблицы и конвертирует данные. Если Вы уже установили UTF8 в колонке прежде чем изменять кодировку, можно установить соответствие данных:
      ALTER TABLE имяТаблицы CHANGE имяКолонки имяКолонки BLOB;
      ALTER TABLE имяТаблицы CHANGE имяКолонки имяКолнки TEXT CHARACTER SET UTF8;
    • Затем нужно предупредить MySQL, что Ваши действия будут в UTF8, отправляя при каждом соединении:
    • SET NAMES UTF8

    Если можно, объясните, пожалуйста, просто и доступно, что конкретно нужно сделать и как.
    Спасибо

    Модератор Юрий

    (@yube)

    Вы меня прям расстроили, что так тормозит?

    Когда писал, тормозил жутко, то есть, я думал, что вообще не откроется. А сейчас нормально работает. Видать, что-то с каналами было.

    В PMA тоже вопросы вместо знаков.

    А вот сейчас я Вас расстрою. Это очень-очень плохо.

    Давайте пока статью не будем рассматривать. Посмотрите в PMA, какие сопоставления (collation) у текстовых полей в БД (смотреть в закладке «структура») и у таблиц вцелом (смотреть в «операции»)

    Скрины:
    http://s2.itrash.ru/idb/9de916b765236f5cb953e063401d69b9/omysql1.png.htm
    http://s2.itrash.ru/idb/9de916b765236f5cb953e063401d69b9/omysql2.png.htm

    PS Если на хостнге делаются бэкапы БД, срочно заберите их к себе.

    И НИЧЕГО С БАЗОЙ НЕ ДЕЛАЙТЕ, если не уверены в своих действиях на 200%

    Модератор Юрий

    (@yube)

    Еще раз внимательно прочел первый пост. «или после восстановления БД» — подробней об этом, пожалуйста.

    elkarina Вы можете проще поступить — дать временный доступ Юрию к БД, вероятность успешного решения проблемы повысится..

    Модератор Юрий

    (@yube)

    В чужие админки я лезу только в самых крайних случаях 😉

    Посмотрите в PMA, какие сопоставления (collation) у текстовых полей в БД (смотреть в закладке «структура») и у таблиц вцелом (смотреть в «операции»)

    В целом стоит utf8_general_ci, в структуре почти везде тоже utf8_general_ci, единственная таблица отличается: bb_bbpm, в ней utf8_unicode_ci.

    Еще раз внимательно прочел первый пост. «или после восстановления БД» — подробней об этом, пожалуйста.

    Предыстория такова, что вздумалось мне поставить на сайт bbforum. Долго не могла сообразить, как сделать, чтобы в адресной строке было forum а не bbpress, поэтому ставила, потом сносила (тупо удаляя в диспетчере файлов cPanel всю папку), снова ставила, пока не добилась, что нужно. В очередной раз поставила, все заработало, но дефолтная тема как-то криво показывалась в браузере (не табличкой форума, а все сплошняком сверху вниз). Я решила, что опять что-то не так установила и в очередной раз снесла.

    И тут меня перестало пускать в админку сайта, и все страницы сайта показывали ошибку «не найдено». Только главную можно было открыть, но с нее ничего не открывалось, да и руками если адрес вбить тоже не открывалось.

    Я написала в тех поддержку хостинга (eskhosting) с просьбой восстановить и заодно обновить вордпресс (я его никогда не обновляла, как мне его поставили год назад).

    У меня был бэкап полный (сама накануне делала в cPanel) от 9 мая, думаю, по нему и восстанавливали (по крайней мере в тех поддержке уточняли, где находится файл бэкапа). Мне восстановили сайт по состоянию на 9 мая и обновили вордпресс до 3.1.2. После этого и исчезли в записях все значки. Я руками поправила. Поставила плагин WordPress Database Backup. Сейчас у меня два раза в сутки приходят на почту базы.

    Через несколько дней после восстановления и обновления я поставила buddypress и потом опять куда-то полезла, уже не помню, кажется в сайдбар. Убрала RSS подписку из сайдбара на виджет и сделала его динамическим. И сразу сайт затормозил (видимо, как Юрий первый раз его смотрел, также было). Я испугалась, что, может что-то натворила, и сделала восстановление.

    И еще у меня в админке такая надпись сейчас: Автоматическое обновление WordPress завершить не удалось — пожалуйста, попробуйте ещё раз. Хотя я вроде специально не обновлялась. Только пыталась обновить какой-то плагин, поставив на него галочку, но почему-то появилась эта надпись. С обновлениями и загрузками плагинов и тем через админку отдельная история, там ничего не грузится (то не получается скопировать, то создать папку public html), но это уже другой вопрос, к значками не имеющий отношение.

    В общем, записи я какое-то время не просматривала, на наличие значков. Так что опять не могу сказать, от чего они слетели.

    Почитала на французском форуме wordpress, там французы тоже со значками мучаются, решений нет. Темы висят не решенными. Или решено с такими советами:

    1. в wp-config заменить
    define('DB_CHARSET', 'utf8'); на
    define('DB_CHARSET', '');
    Мне такое решение не подошло. Аксаны не появились, зато весь русский текст стал вопросами.
    2. В wp-config заменить
    define('DB_COLLATE', ''); на
    define('DB_COLLATE', 'utf8');
    Тоже не помогло.

    Единственное решение, где французы благодарят, что помогло, это в той статье, на которую давала ссылку.

    В общем как-то так. Извините, что слишком «поподробнее» получилось.

    Я с удовольствием дала бы доступ Юрию. Но цена вопроса? Я сейчас совсем «на мели», боюсь не потяну, чтобы «вскрытие делал специалист».

    Модератор Юрий

    (@yube)

    Мне восстановили сайт по состоянию на 9 мая

    Одно из двух: либо бэкап кривой, либо руки. Если тот бэкап у Вас есть в наличии, то стоит его посмотреть. Если он нормальный, то в .sql любой текстовый редактор, понимающий utf, должн показать правильные буквы. Также в «хорошем» бэкапе должна быть строка похожая на

    /*!40101 SET NAMES utf8 */;

    и у каждой таблички

    CREATE TABLE IF NOT EXISTS ....
    ....
    ) ENGINE=MyISAM  DEFAULT CHARSET=utf8...

    Если бэкап порченный, то есть, уже с вопросиками, то дело плохо — только руками исправлять каждое слово. Если бэкап хороший, то… ну, есть разные варианты, но все нудные и трудоемкие (простой вариант «отката в прошлое» не рассматриваем).

    Итак, проанализировала разные бэкапы в Notepad++. Отчитываюсь 🙂

    Бэкап, по которому восстанавливали был без значков с вопросами. Нашла другой бэкап от 24 мая, он со значками. Вывод — могут бэкапы и со значками создаваться. Но откат на 24 мая не устраивает. В моем случае самое простое решение исправить руками, так как много изменений было, плагины доставляла, форум, бади пресс и т.д. Исправила все записи руками (благо их пока немного). Вот только на будущее хотелось бы найти решение, чтобы каждый раз руками не править.

    После исправления посмотрела в PMA — записи правильные. Создала бэкап плагином WordPress Database Backup и через cPanel. Вот что получилось.

    Бэкап плагина сохраняет записи со значками, да и сами записи удобно структурируются по строчке на запись. Вот, например, структура таблицы:

    CREATE TABLE <code>wp_commentmeta</code> (
      <code>meta_id</code> bigint(20) unsigned NOT NULL auto_increment,
      <code>comment_id</code> bigint(20) unsigned NOT NULL default '0',
      <code>meta_key</code> varchar(255) default NULL,
      <code>meta_value</code> longtext,
      PRIMARY KEY  (<code>meta_id</code>),
      KEY <code>comment_id</code> (<code>comment_id</code>),
      KEY <code>meta_key</code> (<code>meta_key</code>)
    ) ENGINE=MyISAM AUTO_INCREMENT=52 DEFAULT CHARSET=utf8 ;

    Нет только слов IF NOT EXISTS.
    С другой стороны, в бэкапе, созданном плагином нет ничего похожего на /*!40101 SET NAMES utf8 */;

    Бэкап, созданный Мастером резервного копирования из cPanel содержит все записи (включая страницы, активность, документы, созданные плагином для бадипресс и т.д.) в одну строку. Все записи без значков, с вопросами. Однако в этом бэкапе есть строка
    /*!40101 SET NAMES utf8 */;
    Вот, например, как выглядит таблица:

    DROP TABLE IF EXISTS <code>wp_commentmeta</code>;
    /*!40101 SET @saved_cs_client     = @@character_set_client */;
    /*!40101 SET character_set_client = utf8 */;
    CREATE TABLE <code>wp_commentmeta</code> (
      <code>meta_id</code> bigint(20) unsigned NOT NULL auto_increment,
      <code>comment_id</code> bigint(20) unsigned NOT NULL default '0',
      <code>meta_key</code> varchar(255) default NULL,
      <code>meta_value</code> longtext,
      PRIMARY KEY  (<code>meta_id</code>),
      KEY <code>comment_id</code> (<code>comment_id</code>),
      KEY <code>meta_key</code> (<code>meta_key</code>)
    ) ENGINE=MyISAM AUTO_INCREMENT=52 DEFAULT CHARSET=utf8;
    /*!40101 SET character_set_client = @saved_cs_client */;

    Также в начале бэкапфайла есть такой раздел:

    /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
    /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
    /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
    /*!40101 SET NAMES cp1251 */;
    /*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
    /*!40103 SET TIME_ZONE='+00:00' */;
    /*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
    /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
    /*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
    /*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

    В общем, жду ваш вердикт на тему «Как предохраняться от замены аксанов на вопросы». Также, скажите, пожалуйста, чем чревато отсутствие строки /*!40101 SET NAMES utf8 */;

    Модератор Юрий

    (@yube)

    чем чревато отсутствие строки /*!40101 SET NAMES utf8 */;

    Эта строчка как раз и говорит mysql, что дальнейшее общение будет в кодировке utf-8 (обратите внимание, что имя кодировки у mysql без минуса — это такие популярные грабли…:). Если дамп без такой строки «скармливать» программе, которой иным способом не сказали, что используется utf, то программа будет использовать кодировку по умолчанию, следовательно, результат не предсказуем, строго говоря. У PMA есть дропдаун с кодировками в разделе «импорт», а вот у утилиты mysql и, помнится, импортера cPanelи нет возможности выбора, только прямым указанием в дампе. Нет указания — русская рулетка.

    Честно говоря, я не совсем понимаю, как получилось, что русский остался, а французский снесло. Чаще происходит наоборот. Разве что «<i>Бэкап, по которому восстанавливали был без значков с вопросами</i>» был в кодировке cp1251 (windows-1251), тогда да, русский остается, западноевропейский погибает.

    Предохраняться просто: поглядывать на бэкапы одним глазом. Дурное занятие, не спорю. Но если нет доверия к серверу, то остается старое, проверенное «глаз да глаз».

Просмотр 13 ответов — с 1 по 13 (всего 13)
  • Тема «Отображение букв с надстрочными знаками в постах» закрыта для новых ответов.