Эмодзи в MySQL

Вчера при импорте на сайт реакций из «Телеграма» заметил какой-то странный баг — количество реакций совпало, а их состав — нет. В «Телеграме» две пары «глаз» и «палец вниз», а у меня на сайте — только глаза.

Заметил, что реации из «Телеграма» импортируются неправильно

Пошёл разбираться, выяснилось, что в базе всё лежит отдельно, как положено. Нейросеть «Сол» обнаружила странное — несмотря на то, что эмодзи «глаз» и «палец» имеют разные коды, «МайЭсКьюЭль» считает их одним значением и объединяет при группировке.

Вот тут «Сол» меня сильно расстроил. Сначала он предложил группировать через функцию HEX() . Решение само по себе плохое, но проблема ещё и в том, что движок сайта поддерживает три СУБД, и в «Постгресе» такой функции нет, а генерировать разные запросы под базы не очень хочется.

Тогда он решил считать хеш через PHP, чтобы группировать по нему. К сожалению, в этот момент я не следил за окном, где он копался, и он успел это реализовать и даже задеплоить.

Меня такая реализация категорически не устроила. Мне в целом понятно, что проблема связана с тем, что называется «collate» — в СУБД это набор правил, по которым сравниваются строки. У «МайЭсКьюЭля» много особенностей при работе с Юникодом, с которыми я уже сталкивался, поэтому был уверен, что дело именно в одной из них.

Готовый рецепт нашёлся безо всяких проблем. Чтобы эмодзи сравнивались правильно, нужно установить «collate» для этого столбца как utf8mb4_bin, что мы и сделали. Не думаю, что это необходимо, тем не менее для остальных баз мы выставили в этом месте бинарный «collate» — С для «Постгреса» и BINARY для «ЭскуэльЛайта».