Кодировки и сортировка текста в MySQL и PostgreSQL: где искать русские буквы

MySQL и PostgreSQL по-разному хранят и сравнивают текст: у них разная логика кодировок, разные наборы правил сортировки (collation) и разное поведение при работе с русским языком. Ошибка в этих настройках — одна из самых частых причин «кракозябр» и странного порядка строк в отчётах.

Почему кодировки вообще важны для базы данных?

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

Сегодня универсальный ответ на вопрос «какую кодировку выбрать» — UTF-8. Она поддерживает практически все языки мира, включая русский, и стала фактическим стандартом для веб-проектов. Обе СУБД её прекрасно поддерживают, но реализуют по-разному.

Как с этим работает MySQL?

В MySQL исторически было несколько вариантов UTF-8: старый utf8, который на самом деле поддерживал не все символы Unicode, а только часть, и полноценный utf8mb4, который умеет хранить абсолютно любые символы, включая эмодзи и редкие иероглифы. Это важная деталь: если по старой привычке выбрать «просто utf8», можно неожиданно потерять часть символов при сохранении данных из современных приложений, соцсетей или мессенджеров.

Кодировка в MySQL задаётся на нескольких уровнях: у базы данных, у отдельной таблицы и даже у конкретного столбца. Это удобно, когда в одном проекте одна таблица хранит служебные технические коды на латинице, а другая — многоязычный пользовательский контент. Но такая гибкость же усложняет жизнь: легко забыть указать кодировку для нового столбца и получить несовпадение настроек внутри одной базы.

А что в PostgreSQL устроено иначе?

В PostgreSQL кодировка задаётся один раз — на уровне базы данных, при её создании. Изменить её потом «на ходу» без пересоздания базы не получится, поэтому важно определиться с UTF-8 заранее, ещё на этапе проектирования проекта. Зато внутри одной базы не может возникнуть путаницы с разными кодировками у разных таблиц — все они автоматически используют единую настройку.

Такой подход дисциплинирует: разработчик не может «на скорую руку» создать таблицу с несовместимой кодировкой. Это меньше гибкости, но больше предсказуемости — особенно ценно, когда над проектом работает не один человек, а целая команда.

Что такое collation и почему из-за него «неправильно» сортируются слова?

Collation — это набор правил, по которым СУБД сравнивает и сортирует текст: считать ли «а» и «А» одинаковыми буквами, куда ставить букву «ё» относительно «е», как сортировать строки с цифрами и без учёта регистра. Именно collation отвечает за привычный алфавитный порядок в отчётах и списках.

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

В чём разница подходов к сортировке у MySQL и PostgreSQL?

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

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

Как понять, что в проекте уже есть проблема с кодировками?

Есть несколько типичных симптомов:

• вместо русских букв в интерфейсе или в выгрузке отображаются вопросительные знаки или странные символы;
• поиск по базе не находит слово, которое точно есть в таблице, из-за несовпадения регистра или буквы «ё»;
• сортировка по алфавиту в отчётах выглядит хаотично, а не как привычный русский алфавит;
• при экспорте данных в файл или при импорте из другой системы часть текста «портится».

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

Есть ли интересный факт про кодировки, который стоит знать?

Да, и он довольно показателен: стандарт Unicode, на котором строится современная кодировка UTF-8, изначально создавался для того, чтобы объединить десятки несовместимых друг с другом кодировок для разных языков в единую систему. До его появления текст на кириллице мог храниться в нескольких разных, взаимно несовместимых кодировках одновременно — из-за этого документы, переданные между разными системами, массово превращались в те самые «кракозябры». UTF-8 решил эту проблему тем, что позволяет закодировать буквы практически любого языка мира в одном общем формате, оставаясь при этом обратно совместимым с базовой латиницей.

Что в итоге важно учесть при выборе и настройке СУБД под русскоязычный проект?

Главное правило простое: с самого старта проекта использовать полноценный UTF-8 — в MySQL это конкретно utf8mb4, а не устаревший utf8, а в PostgreSQL — выбрать нужную кодировку при создании базы, потому что поменять её потом без пересоздания базы не получится. Дополнительно стоит явно задать корректный набор правил сортировки для русского языка, а не оставлять настройки «по умолчанию», доставшиеся от системы или от шаблона установки.

Для тех, кто не хочет разбираться в этих тонкостях самостоятельно, разумный путь — использовать готовую инфраструктуру, где эти параметры уже настроены корректно. В «Клауд АйСи» базы данных на MySQL и PostgreSQL разворачиваются с правильными кодировками и настройками под русскоязычные проекты сразу «из коробки», так что переносить сюда старые базы или запускать новые можно без опасений насчёт «кракозябр» и неправильной сортировки.