От кодовых страниц к Unicode: почему шрифт не исправит «кракозябры»

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

На экране мы видим буквы, но файл обычно хранит последовательность байтов. Чтобы получить текст, программа должна знать правило, по которому эти байты превращаются в символы. Это правило и есть кодировка. Один и тот же байт может означать разные знаки в разных кодировках: например, старые документы Windows могли сохраняться в Windows-1251, а новые чаще передаются в UTF-8.

Важно различать четыре слоя. Кодовая страница или другая кодировка интерпретирует байты; Unicode назначает символам номера, называемые кодовыми точками; шрифт сопоставляет символам глифы и описывает их контуры; приложение размещает эти глифы в строке. Когда на одном слое происходит сбой, следующий слой не всегда способен его исправить. Хороший шрифт не может угадать, что неверно прочитанный байт задумывался как буква «П».

Упрощённо это можно представить как почтовый адрес и печать: кодировка отвечает за расшифровку адреса, Unicode — за единое имя объекта, а шрифт — за то, как его изображение выглядит на бумаге или экране. Если письмо доставили не тому адресату, смена гарнитуры не перенаправит его.

Ранние вычислительные системы располагали ограниченным числом кодовых значений и строились вокруг конкретных языков и устройств. ASCII закрепил базовый набор для английского текста и управляющих символов. Чтобы добавить национальные буквы, разные производители и операционные системы создавали расширенные таблицы. Для кириллицы применялись, среди прочих, CP866 в DOS, Windows-1251 в Windows и KOI8-R в Unix-среде. Они решали похожую задачу, но назначали значения байтам по-разному.

В пределах одной среды такая договорённость работала: автор и получатель использовали совместимые программы и настройки. Проблемы появлялись при переходе между платформами, почтовыми системами, базами данных и веб-сайтами. Если приложение принимало файл Windows-1251 за KOI8-R, одни и те же байты превращались в другие буквы. Если старая система могла представить только ограниченный набор символов, несовместимый знак иногда заменялся вопросительным знаком ещё при сохранении.

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

Unicode предложил общий репертуар символов и однозначные кодовые точки, чтобы тексты на разных языках могли сосуществовать в одной системе. Например, кириллическая заглавная «П» имеет кодовую точку U+041F. Это имя символа не говорит, сколько байтов он займёт в конкретном файле: кодировка UTF-8, UTF-16 или UTF-32 задаёт собственное представление кодовых точек в кодовых единицах. Поэтому выражение «файл в Unicode» обычно требует уточнения: важна форма кодирования, например UTF-8.

Unicode не является шрифтом и не является одной фиксированной последовательностью байтов. Стандарт описывает символы, их кодовые точки и свойства, а UTF-8, UTF-16 и UTF-32 — способы закодировать эти значения. Одна и та же буква может быть передана разными Unicode-совместимыми формами; после корректного декодирования приложение получает ту же кодовую точку.

Широкий общий репертуар упростил смешанный текст. В одной строке могут встречаться русские и английские буквы, математический знак, тире и символ валюты. Системам больше не нужно переключать таблицу для каждого языка на уровне байтов. Однако остаются вопросы совместимости, корректного объявления кодировки и поддержки нужного набора символов в выбранном шрифте.

Моджибейк возникает, когда байты декодируют с неверным правилом, а полученные символы затем показывают совершенно честно. Например, слово «Привет» в UTF-8 состоит из байтов D0 9F D1 80 D0 B8 D0 B2 D0 B5 D1 82. Если эти байты прочитать как Windows-1251, получится знакомая последовательность «РџСЂРёРІРµС‚». Шрифт здесь просто рисует символы, которые программа уже выбрала после ошибочного чтения.

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

Наконец, квадрат вместо буквы или пустой прямоугольник часто указывает на отсутствующий глиф в шрифте. При этом копирование текста может сохранять правильную букву. Такая проблема похожа на сбой кодировки внешне, но диагноз другой: символ есть, а конкретная гарнитура не умеет его отрисовать. В некоторых сложных письменностях причиной может быть также неподходящий механизм формирования текста, а не байты.

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

Перед исправлениями сделайте копию файла. Затем выясните, где текст впервые выглядит неверно: в исходнике, после импорта, в базе данных, в письме или только в экспортированном PDF. Чем раньше обнаружен сбой, тем выше шанс найти правильную интерпретацию без ручной правки.

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

После восстановления символов проверьте, как они отображаются в целевом шрифте. У гарнитуры могут отсутствовать отдельные кириллические знаки, дополнительные формы кавычек или символы для другого языка. Тогда система может подставить глиф из запасного шрифта; строка останется правильной, но визуальный стиль изменится. Здесь помогают проверка покрытия символов и осмысленный список резервных гарнитур.

Для собственного рукописного шрифта полезно проверить соответствие: введённая буква должна быть связана с тем же ожидаемым символом, а в файле должен присутствовать её глиф. Но это отдельная проверка после корректного декодирования текста. Если вы создаёте персональную кириллическую гарнитуру, Fontgenerator помогает пройти путь от заполненного шаблона к файлу шрифта; проверяйте готовый файл в реальном редакторе и тестовом русском тексте.

Обычно нет. Если неверно декодированы байты, приложение уже передало шрифту другие символы; шрифт только рисует их. Установка гарнитуры помогает, когда символ прочитан правильно, но у текущего шрифта отсутствует глиф.

Unicode задаёт общий набор символов и кодовые точки. UTF-8 — одна из форм представления этих значений последовательностями байтов. Есть также UTF-16 и UTF-32; они представляют те же Unicode-символы другим способом.

Часто это означает, что программа получила правильный символ, но выбранный шрифт не содержит его глиф. Скопируйте знак в редактор: если копируется ожидаемая буква, проверьте покрытие шрифта и подстановку гарнитуры.

Потому что исходные байты могли быть записаны в Windows-1251, а программа ошибочно приняла их за другую кодировку, например UTF-8. Верный вариант восстановления зависит от истории файла; сначала работайте с копией и проверяйте результат на нескольких фрагментах.

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

Приложения могут по-разному определять кодировку при отсутствии метаданных, использовать разные настройки импорта или по-разному отображать отсутствующие глифы. Сравните байты исходника, выбранную кодировку и результат копирования в каждом приложении.

Только если программа сначала правильно прочитала исходные байты и сохранила нужные символы без потерь. Перекодирование неверно прочитанного текста запишет ошибки в UTF-8 и сделает их постоянными; перед конвертацией проверьте исходное отображение и сохраните копию.

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

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

Unicode Consortium, модель кодирования символов: различия между набором символов, кодовыми точками и их кодированием в байты.

Unicode Consortium, история стандарта Unicode и FAQ по UTF-8, UTF-16, UTF-32 и BOM: развитие общего репертуара и различия между формами кодирования.

Microsoft Learn, страницы кодов Windows: таблица относит кодовую страницу 1251 к кириллице и рекомендует Unicode-кодировки для сохранения данных без потерь.