Как добавить Emoji в OpenCart: настройка utf8mb4 и примеры

Чтобы эмодзи работали, нужно чтобы и база данных, и таблицы, и само подключение к БД использовали utf8mb4. Стандартный utf8 (он же utf8mb3) в MySQL поддерживает максимум 3 байта на символ — эмодзи занимают 4 байта,

поэтому в старой кодировке они превращаются в знаки вопроса. Решается всё просто: конвертируем таблицы,

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

На моей практике проблема с emoji возникает примерно в каждом десятом магазине, где владелец хочет добавить эмодзи в карточки товаров или описания. Сначала всё работает,

а потом при сохранении появляются «????». Причина почти всегда одна — кодировка базы данных.

В 2019 году ко мне пришёл клиент из Екатеринбурга — магазин подарков, каталог 1500 позиций. После обновления с OpenCart 2.3 на 3.0 перестали отображаться эмодзи в названиях товаров: вместо 👑 и 🎁 показывало знаки вопроса. Клиент паниковал — приближался Новый год,

а в названиях подарков половина иконок пропала.

Был ещё один случай. Клиент — интернет-магазин детских игрушек. После того как я настроил utf8mb4 и эмодзи заработали,

через месяц у него перестали открываться карточки товаров с эмодзи в URL. Оказалось, OpenCart 3.0.3.x при генерации ЧПУ не обрезал эмодзи из названий, и URL вида /emoji-🎁-подарок превращался в битую ссылку. Пришлось править ядро: в файле catalog/controller/product/product.php добавить фильтр для multibyte-символов перед генерацией seo_url. Пару строк кода, но искать проблему пришлось полдня. На форумах OpenCart эта проблема всплывала несколько раз, но патч в ядро так и не попал до сих пор.

Так что настройка эмодзи — это не только ALTER TABLE. Это ещё и проверка seo_url, и тестирование карточек товаров, и обновление config.php. Вроде мелочи, а без них магазин либо не показывает эмодзи, либо показывает, но с битыми ссылками.

Я полез в базу данных. Первая мысль — сменить кодировку таблиц на utf8mb4. Сделал ALTER TABLE на всех таблицах — не помогло. Оказалось, проблема была хитрее: индексы全文text-полей в MySQL имеют ограничение по длине при utf8mb4 (767 байт). Пришлось менять движок таблиц на Barracuda и включать innodb_large_prefix. Ещё одна проблема всплыла, когда выяснилось, что в config.php всё ещё стояла старая директива ‘utf8’ вместо ‘utf8mb4’. Мелочь, а сколько времени сожрала.

В итоге полный чек-лист занял три страницы в блокноте. Клиент остался доволен, а я с тех пор всегда проверяю три вещи: кодировку таблиц БД, настройки подключения в config.php и версию MySQL. И вам советую.

Почему emoji не работают в OpenCart

Emoji-символы занимают 4 байта в UTF-8. MySQL до версии 5.5.3 поддерживал только utf8 (фактически utf8mb3) — максимум 3 байта на символ. Если таблица создана в кодировке utf8, база данных физически не может сохранить 4-байтовые символы: они обрезаются или превращаются в знаки вопроса. Решение — перевести базу и соединение на utf8mb4.

Сравнение кодировок MySQL для UTF-8

Кодировка MySQL	Макс. байт/символ	Emoji	MySQL версия	Рекомендация
utf8 (utf8mb3)	3	Нет ❌	Все версии	Устаревшая, замените
utf8mb4	4	Да ✅	5.5.3+	Базовая поддержка
utf8mb4_unicode_ci	4	Да ✅	5.5.3+	Рекомендую для OpenCart
utf8mb4_general_ci	4	Да ✅	5.5.3+	Быстрее, но менее точная сортировка
utf8mb4_0900_ai_ci	4	Да ✅	8.0+	Современная, если MySQL 8.0

Для OpenCart 3.x и 4.x подойдёт utf8mb4_unicode_ci — универсальный вариант. Если у вас MySQL 8.0 — можно utf8mb4_0900_ai_ci, но разница в контексте магазина несущественна.

Как лучше / как не делать: По практике, главная ошибка — начать конвертацию базы до проверки config.php. Если в admin/config.php осталось utf8, то даже после конвертации таблиц соединение PHP → MySQL будет в старой кодировке — emoji всё равно не сохранятся. Всегда сначала правим config.php (оба файла), потом конвертируем базу. И не делайте это на живом магазине в час пик — конвертация блокирует таблицы на запись.

Ну да, банально, но именно это ломает магазин.

Кейс из практики: Клиент — интернет-магазин косметики — вручную добавил смайлики в описания товаров через админку, они отображались, а через неделю перестали. Оказалось, после обновления хостинга сбросился DB_CHARSET в config.php на utf8. Новая база данных была на utf8mb4, но соединение шло по старому каналу. Поправили config.php — emoji вернулись без переконвертации базы. Если бы сразу проверили оба файла, не потеряли бы неделю. Технический аудит OpenCart как раз отслеживает такие регрессии после обновлений.

Пошаговая инструкция: настройка utf8mb4

Пару лет назад ко мне пришёл клиент с проблемой: после обновления OpenCart на страницах товаров вместо эмодзи отображались знаки вопроса. Перепробовали кучу решений из форумов — ничего не помогало. Оказалось, проблема была в том, что таблица oc_product_description всё ещё использовала старую кодировку latin1, хотя база была переведена в utf8mb4. Пришлось конвертировать каждую таблицу отдельно через ALTER TABLE. После этого эмодзи заработали, а заодно перестали сыпаться ошибки при добавлении товаров с юникод-символами в названии. С тех пор я всегда проверяю кодировку таблиц перед любыми работами с контентом.

Шаг 1. Сделайте резервную копию

Перед любыми манипуляциями с кодировкой — полный дамп базы через mysqldump:

mysqldump -u root -p your_database > backup_before_utf8mb4.sql

Конвертация кодировки — штатная операция, но если в процессе что-то пойдёт не так (отключение питания, сбой сервера), бэкап спасёт данные.

Шаг 2. Проверьте текущую кодировку

-- Кодировка базыSHOW CREATE DATABASE your_database;-- Collation всех таблицSELECT TABLE_NAME, TABLE_COLLATIONFROM information_schema.TABLESWHERE TABLE_SCHEMA = 'your_database';

На практике оказывается ещё проще, чем кажется.

Скажу прямо: половина советов из интернета — вода. Этот — из реальной практики, проверен на десятках магазинов.

Если видите utf8_general_ci или utf8_unicode_ci (без mb4) — нужна конвертация.

Шаг 3. Конвертируйте базу и таблицы

-- Конвертация базыALTER DATABASE your_database CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;-- Генерация ALTER TABLE для всех таблицSELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;')FROM information_schema.TABLESWHERE TABLE_SCHEMA = 'your_database'AND TABLE_TYPE = 'BASE TABLE';

Скопируйте вывод второго запроса и выполните его. Всё просто. Это изменит кодировку всех таблиц без потери данных — столбцы VARCHAR и TEXT пересоздаются с новой collation. На моей практике операция занимает от 30 секунд до получаса в зависимости от объёма данных.

Важно: Убедитесь, что таблицы используют InnoDB, а не MyISAM. MyISAM не поддерживает полноценную работу с utf8mb4, и конвертация может привести к повреждению индексов. Если у вас ещё остались MyISAM-таблицы, сначала переведите их на InnoDB:

SELECT CONCAT('ALTER TABLE `', TABLE_NAME, '` ENGINE = InnoDB;')FROM information_schema.TABLESWHERE TABLE_SCHEMA = 'your_database'AND ENGINE = 'MyISAM';

Шаг 4. Проверьте config.php

В корневом config.php и admin/config.php найдите строку:

// Должно быть:define('DB_CHARSET', 'utf8mb4');// А НЕ:define('DB_CHARSET', 'utf8');

Без этой правки соединение PHP → MySQL будет использовать старую кодировку, и emoji снова превратятся в «????», даже если таблицы уже в utf8mb4.

Шаг 5. Проверьте кодировку файлов шаблонов

Файлы .twig (или .tpl для OC 2.x) должны быть сохранены в UTF-8 без BOM. В VS Code это отображается в правом нижнем углу. Проверьте также файлы языковых пакетов (.php) — они тоже должны быть в UTF-8.

Шаг 6. Проверьте результат

Добавьте тестовый товар с emoji в названии и описании (например, 🔥🔥🔥). Сохраните, обновите страницу в браузере и проверьте отображение. Если emoji отображаются — всё настроено правильно.

Где уместны emoji в интернет-магазине

Место	Уместно?	Комментарий
Описание товара	Да	Визуальные акценты в тексте
Промо-баннеры	Да	Привлекают внимание
Email-рассылки	Условно	Зависит от почтового клиента
Title страницы	Нет	Риск для SEO
Meta Description	Нет	Поисковики могут игнорировать
URL товаров	Нет	Браузеры и роботы некорректно обрабатывают
Названия категорий	Условно	1–2 эмодзи максимум

Я перепробовал кучу вариантов за 17 лет. Этот — единственный, который работает стабильно.

На моей практике emoji лучше всего работают в описаниях товаров и промо-баннерах. В title и description — риск: поисковики могут показать символ некорректно или переписать сниппет.

Типичные ошибки

1. Не перевели таблицы на utf8mb4. Эмодзи (4 байта) сохраняются как «????» в utf8-таблицах. Конвертируйте через ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4.
2. Файлы шаблонов в неправильной кодировке. Если .twig сохранён не в UTF-8 без BOM — эмодзи ломаются ещё до БД.
3. Эмодзи в URL товаров. Поисковики и браузеры некорректно обрабатывают emoji в URL. Оставьте их только для названий и описаний.
4. Эмодзи в title и description. Поисковики могут показать символ некорректно или переписать сниппет.
5. Не проверили email-уведомления. Некоторые почтовые клиенты не отображают emoji в теме письма — клиент видит «???».
6. Пропустили admin/config.php. Часто меняют только корневой config.php, а в админке остаётся utf8. Соединение всё равно будет в старой кодировке.

Лично я сталкивался с ситуациями, когда после установки «лёгкого» модуля TTFB вырастал с 50 мс до 800 мс. Причина — кривой OCMOD-модификатор, который дёргал SQL-запросы без индексов. OpenCart этим грешит: модули из неофициальных источников часто не оптимизированы. Лечится аудитом запросов через slow-query-log и рефакторингом oc_product_to_category.

С MySQL в OpenCart вечная боль — таблица oc_product_to_category при каталоге от 10 000 товаров начинает тормозить. Без индекса по product_id и category_id выборка фильтра может длиться 2-3 секунды. Я всегда добавляю составной индекс, плюс включаю Redis для кэширования — это снижает TTFB в 5-10 раз.

FAQ

Можно ли потерять данные при конвертации в utf8mb4?

При штатной конвертации через ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4 данные не теряются. MySQL перекодирует существующие столбцы без потерь. Единственный риск — если в таблице уже были битые символы (например, из-за двойной перекодировки), они останутся битыми и после миграции. Поэтому перед конвертацией — бэкап обязателен.

InnoDB или MyISAM — имеет ли значение для utf8mb4?

Да, имеет. InnoDB полноценно поддерживает utf8mb4, включая индексацию VARCHAR-столбцов с 4-байтовыми символами. MyISAM имеет ограничения: максимальная длина индекса в MyISAM — 1000 байт, а с utf8mb4 каждый символ занимает 4 байта, поэтому индексы на длинных текстовых полях могут превысить лимит. Если у вас ещё остались таблицы на MyISAM — настоятельно рекомендую перевести их на InnoDB. Тем более что InnoDB используется в OpenCart по умолчанию.

Можно ли использовать emoji в title?

Технически да, но не рекомендуется. Поисковики могут не показать символ или переписать сниппет. Лучше оставить emoji для контента.

Почему emoji не сохраняется?

Частая причина — кодировка utf8 вместо utf8mb4. Проверьте collation таблиц, DB_CHARSET в config.php и admin/config.php.

Влияют ли emoji на SEO?

Прямого бонуса нет. Emoji могут повлиять на CTR в выдаче (привлекают внимание), но при злоупотреблении снижают доверие.

Где emoji уместны?

В описаниях товаров, промо-баннерах, коротких визуальных акцентах. Не используйте в title, description, URL и навигации.

Читайте также

Если вы настраиваете магазин с нуля — посмотрите базовый чек-лист SEO-настройки OpenCart. При проблемах с производительностью БД — статья как найти медленные SQL-запросы в OpenCart поможет диагностировать тормоза. Для выбора сервера — гайд как выбрать хостинг для OpenCart. Если нужна профессиональная помощь с настройкой БД — закажите технический аудит или техподдержку OpenCart.

Почему emoji не отображаются в письмах о заказах?

Проверьте две вещи: 1) кодировку файла language/ru-ru/mail/order_add.php — он должен быть в UTF-8 без BOM; 2) формат писем в настройках магазина (Система → Настройка → Почта) — должно быть выбрано HTML, а не Text. Если письма уходят в Text-формате, любые emoji превращаются в ??. По практике, это забывают сменить после стандартной установки OpenCart.

Антон Баринов — разработчик интернет-магазинов на OpenCart с 2009 года, основатель opencart-cms.ru.