Как исправить конфликты charset и collation в WordPress

Что означают charset и collation

Charset, или кодировка, определяет, какие символы может хранить база данных. Для современного WordPress обычно требуется `utf8mb4`, поскольку он поддерживает полный набор Unicode, включая эмодзи и символы разных языков. Старая кодировка `utf8` в MySQL и MariaDB не является полноценным UTF-8 и может не поддерживать четырехбайтные символы.

Collation определяет правила сравнения и сортировки текста: учитывается ли регистр, как сравниваются буквы с диакритическими знаками и в каком порядке возвращаются результаты. Например, `utf8mb4_unicode_ci` и `utf8mb4_general_ci` могут давать разные результаты сортировки.

Конфликт возникает, когда MySQL сравнивает или объединяет текстовые значения с разными collation и не может автоматически привести их к единому варианту. Проблема может проявляться не только на уровне всей таблицы, но и в конкретной колонке, временной таблице или запросе плагина.

• charset — набор символов, которые можно хранить;
• collation — правила сравнения и сортировки текста;
• `utf8mb4` — рекомендуемый базовый charset для современного WordPress;
• для колонок, которые сравниваются между собой, желательно использовать одинаковую collation.

Создайте резервную копию перед изменениями

Конвертация таблиц изменяет структуру и иногда перестраивает индексы. Перед началом работы создайте полную резервную копию базы данных и убедитесь, что ее можно восстановить. Для крупных сайтов желательно также иметь копию файлов и выполнять операции в окно технического обслуживания.

Если доступен WP-CLI, резервную копию можно создать приведенной ниже командой. Она использует настройки подключения из WordPress и сохраняет дамп в файл.

• Не выполняйте `ALTER TABLE` в рабочей базе данных без проверенного дампа.
• Перед изменениями зафиксируйте текущие версии MySQL или MariaDB и WordPress.
• Проверьте, есть ли у пользователя базы данных права на изменение таблиц.
• Для критически важного сайта сначала протестируйте процедуру на копии или staging-среде.

wp db export backup-before-collation.sql

Определите таблицы WordPress с разной кодировкой

Не предполагайте, что префикс таблиц всегда равен `wp_`. Его можно проверить в файле конфигурации или получить через WP-CLI. В приведенном ниже запросе префикс `wp_` используется только в качестве примера.

Сначала просмотрите charset и collation всех таблиц текущей базы данных. Запрос с `DATABASE()` автоматически использует базу, к которой подключено текущее соединение.

• Таблицы с одинаковым charset, но разными collation также могут вызывать конфликты.
• Плагины часто создают собственные таблицы, которые не начинаются с `wp_` или используют другой префикс.
• Отдельно проверьте таблицы, в которых хранятся записи, метаданные, комментарии, таксономии и данные плагинов.

wp db query "
SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = DATABASE()
ORDER BY TABLE_NAME;"

Проверьте charset и collation отдельных колонок

Настройки таблицы не всегда отражают фактическую структуру каждой колонки. Текстовая колонка может иметь собственные `CHARACTER_SET_NAME` и `COLLATION_NAME`, унаследованные из другой схемы или измененные во время импорта.

Для быстрой проверки конкретной таблицы используйте `SHOW FULL COLUMNS`. Это особенно важно для `wp_posts`, `wp_postmeta`, `wp_comments`, `wp_terms`, `wp_term_taxonomy` и таблиц плагинов.

wp db query "SHOW FULL COLUMNS FROM wp_posts;"

wp db query "
SELECT TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME, COLUMN_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND CHARACTER_SET_NAME IS NOT NULL
ORDER BY TABLE_NAME, ORDINAL_POSITION;"

Как найти подозрительные колонки

В результатах обратите внимание на текстовые колонки, в которых charset отличается от `utf8mb4`, или на колонки с другой collation по сравнению с остальными колонками таблицы. Если ошибка возникает только во время поиска или импорта, также проверьте таблицы, которые создает соответствующий плагин.

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

• Сравнивайте не только таблицы, но и конкретные текстовые колонки.
• Учитывайте таблицы сторонних плагинов и пользовательские таблицы темы.
• Сохраните результаты диагностики до внесения изменений.

Выберите совместимую collation

Выбор collation зависит от версии сервера. `utf8mb4_unicode_ci` является распространенным и совместимым вариантом для многих установок WordPress. В MySQL 8 могут быть доступны collations с суффиксом `0900`, но их может не быть в старых версиях MySQL или в MariaDB. Поэтому не переносите такое значение между серверами без предварительной проверки.

Список доступных вариантов можно получить непосредственно на сервере. Для сайта, который должен работать в разных средах, обычно безопаснее выбрать collation, присутствующую на всех целевых серверах.

wp db query "SELECT VERSION();"
wp db query "SHOW COLLATION LIKE 'utf8mb4%';"

Что учитывать при выборе

Согласуйте charset и collation: collation для `utf8mb4` должна относиться к `utf8mb4`, а не к устаревшему `utf8`. Если сайт активно работает с украинским и другими языками, после конвертации протестируйте сортировку на реальных данных.

Не нужно механически менять все таблицы на самую новую доступную collation. Совместимость с версией сервера, плагинами, резервными копиями и будущей средой важнее самого факта использования более нового названия.

• Проверьте поддержку выбранной collation в MySQL или MariaDB.
• Используйте один согласованный вариант для связанных таблиц.
• Не смешивайте collations только потому, что они доступны на текущем сервере.

Конвертируйте таблицы поэтапно

Для изменения charset и collation таблицы используется `ALTER TABLE ... CONVERT TO CHARACTER SET`. Команда преобразует текстовые колонки таблицы, поэтому ее нужно выполнять осторожно и сначала протестировать на одной таблице.

В примере ниже используется `utf8mb4_unicode_ci`. Замените ее на вариант, который поддерживается вашим сервером и выбран после проверки.

ALTER TABLE wp_posts
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

ALTER TABLE wp_postmeta
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_ci;

Порядок действий и технические ограничения

После конвертации первой таблицы проверьте сайт и только затем переходите к следующей. Для крупных таблиц операция может временно блокировать записи, потреблять дополнительное дисковое пространство и создавать нагрузку.

В старых версиях MySQL или при наличии длинных индексов конвертация может завершиться ошибкой из-за ограничения длины индекса. Не сокращайте индексы вслепую: сначала выясните, какая именно колонка или индекс вызвали проблему, и составьте отдельный план изменений.

Если таблица принадлежит плагину, изучите его документацию или схему обновления. Принудительное изменение структуры может быть перезаписано во время следующего обновления плагина.

• Начинайте с небольшой таблицы или staging-копии.
• Для крупных таблиц запланируйте окно технического обслуживания.
• Не прерывайте операцию, не понимая ее текущее состояние.
• После каждой группы изменений проверяйте состояние таблиц и журналы ошибок.

Проверьте результат после исправления

После конвертации повторно выполните запросы к `information_schema` и убедитесь, что нужные таблицы и текстовые колонки имеют ожидаемые значения. Проверка только одной таблицы не гарантирует, что конфликт исчез во всей базе данных.

Затем протестируйте функции, которые ранее вызывали ошибку: поиск, сортировку, фильтры, импорт, создание записей и комментариев. Отдельно проверьте сохранение украинских символов, эмодзи и текста с диакритическими знаками.

Если ошибка осталась, найдите полный SQL-запрос в журнале PHP, WordPress или плагина. Проблема может быть не в таблицах, а в запросе, который явно задает другую collation через `COLLATE`, создает временную таблицу или сравнивает значения из разных источников.

• Проверьте главную страницу, панель администратора и страницы с поиском.
• Создайте тестовую запись с кириллицей и эмодзи.
• Проверьте сортировку по заголовку, имени и метаданным.
• Повторите импорт или синхронизацию, во время которых возникала ошибка.
• Просмотрите журналы после тестирования, а не только сообщение в браузере.

Типичные ошибки при исправлении

Самый опасный подход — выполнить массовую замену collation без предварительной инвентаризации базы данных. Это может скрыть первопричину, создать проблемы с индексами или повлиять на данные плагинов.

Также не стоит путать исправление кодировки с восстановлением уже поврежденного текста. Если данные были импортированы с неправильным charset и уже превратились в символы вроде `????` или некорректную последовательность, изменение collation не восстановит оригинал. Для этого потребуется восстановление из корректной резервной копии или отдельная миграция данных.

Не редактируйте дамп в текстовом редакторе, если не понимаете, в какой кодировке он сохранен. Во время экспорта и импорта проверяйте charset самого файла, настройки клиента MySQL и параметры инструмента миграции.

• Не используйте collation, которой нет на целевом сервере.
• Не изменяйте только одну колонку, если связанные таблицы остаются несовместимыми.
• Не удаляйте индексы для обхода ошибки без плана их восстановления.
• Не считайте успешное выполнение `ALTER TABLE` доказательством корректности данных.
• Не пропускайте тестирование на копии сайта, если база данных большая или критически важная.