Если вы знакомы с MySQL, вы, вероятно, уже знаете, что он поставляется с несколькими кодировками символов. Одной из основных кодировок в мире MySQL и в Интернете в целом является UTF-8 — она используется почти в каждом веб-приложении и мобильном приложении и считается вариантом «по умолчанию» для MySQL. UTF-8 также поддерживает несколько наборов символов и имеет пару других уникальных особенностей: в этом блоге мы рассмотрим их, а также одну особенность — тот факт, что «UTF-8» в MySQL не считается «настоящим» UTF-8. Запутались? Читайте дальше!
Что такое UTF-8?
Начнем с того, что UTF-8 — это одна из самых распространенных кодировок символов. В UTF-8 каждый символ представлен диапазоном от одного до четырех байт. Таким образом, у нас есть несколько наборов символов:
- utf8, который в прежние времена считался стандартом «де-факто» для MySQL. По сути, utf8 также можно считать «псевдонимом» для utf8mb3.
- utf8mb3, который использует от одного до трех байт на символ.
- utf8mb4, который использует от одного до четырех байт на символ.
UTF8 был набором символов по умолчанию в прошлом, когда MySQL только начинал свою работу, и все было замечательно. Однако, поговорите с администраторами баз данных MySQL в наши дни, и вы быстро поймете, что сейчас это уже не так. Проще говоря, utf8, как таковой, больше не является набором символов по умолчанию — им является utf8mb4.
utf8 против utf8mb4
Основная причина разделения utf8 и utf8mb4 заключается в том, что UTF-8 отличается от правильной кодировки UTF-8. Это происходит потому, что UTF-8 не обеспечивает полную поддержку Unicode, что может привести к потере данных или даже к проблемам безопасности. Неспособность UTF-8 полностью поддерживать Unicode является настоящим ударом — кодировка UTF-8 требует до четырех байт на символ, в то время как кодировка «utf8», предлагаемая MySQL, поддерживает только три. Видите, в чем проблема? Другими словами, если мы хотим хранить смайлы, представленные таким образом:
Мы не сможем этого сделать — MySQL не то чтобы будет хранить их в формате «???» или подобном, но он не будет хранить их вообще и выдаст сообщение об ошибке, подобное следующему:
Incorrect string value: ‘x77xD0’ for column ‘demo_column’ at row 1
Этим сообщением об ошибке MySQL говорит: «Ну, я не распознаю символы, из которых состоит этот смайл. Извините, я ничего не могу сделать» — в этот момент вы можете задаться вопросом, что делается для решения такой проблемы? Знает ли MySQL вообще о ее существовании? На самом деле, было бы ложью сказать, что MySQL не знает об этой проблеме — скорее, знает, но разработчики MySQL так и не собрались ее исправить. Вместо этого они выпустили обходной путь более десяти лет назад вместе с MySQL 5.5.3.
Это обходное решение называется «utf8mb4». utf8mb4 практически ничем не отличается от своего старшего аналога — utf8 — просто в этой кодировке используется от одного до четырех байт на символ, что означает, что она способна поддерживать более широкий спектр символов и знаков.
Используйте MySQL 8.0, немного поработайте с данными, и вы быстро заметите, что действительно, utf8mb4 является набором символов по умолчанию, доступным в MySQL — более того, есть предположение, что в ближайшем будущем utf8mb4 станет ссылкой на стандарт utf8 в MySQL.
Разновидности utf8mb4
Поскольку время идет, и utf8 опережает utf8mb4 почти по всем параметрам, естественно, что существует несколько вариантов коллизий, которые могут быть использованы. По сути, эти колляции действуют как «набор» правил сортировки, разработанных для лучшего соответствия конкретным наборам данных. У utf8mb4 тоже есть пара вариантов:
В данном случае обратите внимание на окончание «_ci» в коллизии: это означает «нечувствительность к регистру». Нечувствительность к регистру связана с сортировкой и сравнением.
Эти два «вкуса» utf8mb4 используются все чаще и чаще — по мере выхода новых версий MySQL мы также видим, что для большинства людей, работающих с MySQL сегодня, наиболее предпочтительной является коллизия utf8mb4_unicode_ci. Одно можно сказать наверняка — не все люди, использующие MySQL таким образом, знают о функциональных возможностях и преимуществах utf8mb4 по сравнению с его аналогом utf8, но они обязательно увидят разницу при импорте данных с необычными символами! Мы уже убедили вас перейти в царство utf8mb4?
Правильная работа с данными на основе utf8mb4
Вот как некоторые разработчики создают базы данных и таблицы на основе utf8mb4:
За исключением того, что этот запрос выдает ошибку (ниже запроса), которая часто приводит в замешательство как начинающих, так и опытных разработчиков — MySQL по сути говорит, что когда мы используем колляцию на основе utf8mb4, мы также должны использовать совместимый набор символов, а в данном случае latin1 не подходит, поэтому, что бы вы ни делали, помните об этом:
- utf8mb4 — это не настоящий utf8 в MySQL и его разновидностях (MariaDB и Percona Server): utf8 поддерживает только 3 байта данных, utf8mb4 поддерживает 4, что и должно быть в utf8 в первую очередь. Если используется utf8, некоторые символы могут отображаться неправильно.
- Когда мы решаем использовать utf8mb4 вместо utf8 в MySQL, мы также должны убедиться, что используем соответствующий набор символов (utf8mb4.) Обратите внимание на сообщение об успехе под запросом:
Теперь все в порядке — мы можем хранить любые символы в нашей базе данных, и MySQL не выдаст ошибку «Неверное значение строки»! Ух ты!
Резюме
UTF-8 в MySQL сломан — он не способен поддерживать четыре байта на символ, как и положено UTF-8. «utf8mb4» может быть использован для решения этой проблемы, и в целом с ним довольно легко работать — просто выберите определенную корелляцию (в данном случае выберите либо общую, если вы используете MySQL для личного проекта или небольшого сайта, либо корелляцию Unicode, либо если вы используете его для чего-то более технического или хотите довести MySQL до предела).
Однако, прежде чем доводить MySQL до предела, имейте в виду, что помимо документации, есть еще несколько блогов, таких как блог Arctype, которые предоставляют информацию о том, как работать с реляционной системой управления базами данных и всеми ее разновидностями. Мы рассказываем о том, как работать с MySQL и большими данными, как оптимизировать схемы баз данных и многое другое! Если вы увлекаетесь базами данных, обязательно следите за блогом Arctype, и мы увидим вас в следующем выпуске!