Форма не сохраняет эмодзи: как проверить кодировку базы данных

Если форма сохраняет обычный текст, но выдаёт ошибку на эмодзи, чаще всего один участок цепочки не поддерживает четырёхбайтовые символы Unicode. Проверять нужно не только таблицу: текст проходит через браузер, HTTP-запрос, приложение, соединение с БД и конкретный столбец.

Короткий порядок действий: воспроизведите сбой на безопасной тестовой записи, определите последний слой, где строка ещё цела, затем сравните кодировки соединения и столбца. Для хранения эмодзи в MySQL/MariaDB обычно нужен utf8mb4 по всей цепочке, а не только в настройках страницы.

Сначала подтвердите границу ошибки

Не начинайте с массового ALTER TABLE. Один и тот же симптом дают разные причины: браузер отправил повреждённую строку, приложение удалило символ при проверке, драйвер открыл соединение с другой кодировкой или столбец не принимает четырёхбайтовый символ.

На тестовом стенде или в отдельной технической записи последовательно отправьте:

1. латиницу и цифры;
2. кириллицу;
3. обычный символ Unicode, например «€»;
4. один эмодзи с кодовой точкой U+1F600;
5. тот же эмодзи внутри обычного предложения.

Запишите HTTP-статус и безопасный фрагмент серверной ошибки, но не копируйте в логи реальные обращения клиентов. Если запрос возвращает 200, дополнительно откройте сохранённую запись: форма может показать успех, хотя приложение обрезало или заменило символ.

Проверьте путь текста до базы данных

Браузер и HTTP-запрос

В DevTools откройте Network, повторите тест и посмотрите тело запроса. Для JSON проверьте, что поле осталось строкой с эмодзи и запрос отправлен с корректным Content-Type. Для обычной HTML-формы убедитесь, что страница и ответ используют UTF-8.

Тег <meta charset="utf-8"> описывает документ, но не настраивает соединение приложения с БД. Если в запросе строка цела, переходите на сервер.

Приложение и валидация

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

Проверьте фильтры, регулярные выражения, преобразования JSON, ограничение длины и функции работы со строками. Исправление кодировки таблицы не поможет, если эмодзи уже удалён валидатором или строка обрезана по байтам.

Соединение с MariaDB/MySQL

Кодировка клиента, соединения и результата задаётся для текущей сессии. В той же сессии, которой приложение выполняет вставку, полезно проверить:

SELECT
  @@character_set_client,
  @@character_set_connection,
  @@character_set_results,
  @@collation_connection;

Нужен согласованный utf8mb4-контракт между драйвером и сервером. Настройте charset штатным способом вашего драйвера при открытии соединения; разовый SET NAMES в консоли не доказывает, что рабочее приложение подключается так же.

Проверьте таблицу и конкретный столбец

Сначала получите фактическую схему:

SHOW CREATE TABLE feedback;

Для нескольких полей удобнее сверить INFORMATION_SCHEMA.COLUMNS: важна кодировка именно того VARCHAR или TEXT, куда записывается текст. Значение по умолчанию у базы или таблицы не меняет автоматически уже созданный столбец с явной другой кодировкой.

В MariaDB имя utf8 обычно означает трёхбайтовый вариант utf8mb3. Он хранит множество языков, но не дополнительные символы Unicode, к которым относятся многие эмодзи. Для них предназначен utf8mb4. Типичный сигнал на стороне БД — ошибка о некорректном значении строки, нередко с кодом 1366, но приложение может скрыть её за общей ошибкой формы.

Как подготовить безопасное исправление

1. Сделайте проверяемую резервную копию и оцените размер таблицы.
2. Выберите совместимую с вашей версией сервера collation для utf8mb4; не копируйте имя collation из чужой конфигурации вслепую.
3. Измените настройку соединения приложения и нужные текстовые столбцы одной версионируемой миграцией.
4. До запуска проверьте индексы, длины полей, внешние интеграции и возможную блокировку таблицы.
5. Выполните миграцию сначала на копии схемы с репрезентативными данными.
6. Повторите запись и чтение контрольной строки через тот же интерфейс, которым пользуется форма.

Команда вида ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 может затронуть все текстовые поля и при необходимости изменить их тип. Для точечного изменения безопаснее явно описать нужный столбец через MODIFY, сохранив его тип, NULL/ NOT NULL, значение по умолчанию и остальные атрибуты. Конкретный SQL зависит от текущей схемы, поэтому сначала сохраните результат SHOW CREATE TABLE.

Что проверить после миграции

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

Добавьте регрессионный тест с четырёхбайтовым символом и отдельный негативный сценарий для слишком длинного значения. Если форма критична для заявок, включите её контролируемый smoke-тест после релиза; общий порядок описан в чеклисте проверки сайта после релиза. Если сбой превращается в HTTP 500, отдельно проверьте цепочку диагностики серверной ошибки.

Где мониторинг поможет, а где нет

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

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