Как узнать кодировку текста: UTF-8, Windows-1251, KOI8-R

Введение

Знакомая картина: открываете файл или страницу, а вместо русского текста — непонятные символы, «кракозябры», иероглифы, вопросики. Причина почти всегда одна — неправильная кодировка. Текст закодирован в одной (например, Windows-1251), а открывается как UTF-8 или наоборот. Определить, в какой именно кодировке записан файл, — задача нетривиальная: сами байты не содержат метки о своём происхождении, и приходится угадывать по статистическим признакам. Инструменты определения кодировки анализируют байты и подсказывают, какая кодировка даёт осмысленный текст.

В этой статье разберём, что такое кодировка, почему появляются «кракозябры», как определить кодировку текста и что делать с неправильно открывшимися файлами. Быстрее всего — вставить проблемный текст в определитель кодировки: он определяет кодировку и сразу показывает восстановленный текст, а декодирование в Unicode-escape-последовательности доступно в декодере Unicode икодировщике.

Что такое кодировка

Компьютер хранит всё в виде байтов. Кодировка — таблица соответствия между символами и последовательностями байтов. Разные кодировки по-разному представляют один и тот же текст. Например, русская буква «А»:

• в Windows-1251 — один байт 0xC0;
• в UTF-8 — два байта 0xD0 0x90;
• в UTF-16 — два байта 0x10 0x04 (с обратным порядком в little-endian).

Если программа, читающая файл, применит не ту кодировку, символы интерпретируются неправильно. Один и тот же байт 0xC0 в Windows-1251 — это «А», в Latin-1 — «À», в KOI8-R — «ю». В UTF-8 байт 0xC0 в начале — ошибка (это продолжающий байт, а не начинающий).

Основные кодировки для русского языка

• UTF-8. Современный стандарт, используется почти везде: веб, операционные системы, базы данных. Представляет каждый символ переменным числом байтов (от 1 до 4). Кириллица занимает 2 байта. Поддерживает все языки мира.
• Windows-1251. Исторически основная кодировка в Windows для русского языка. Один байт на символ, поддерживает кириллицу и базовую латиницу. Всё ещё встречается в старых файлах и системах.
• KOI8-R. Историческая кодировка русского интернета времён Usenet и электронной почты. До сих пор используется в некоторых почтовых системах.
• CP866 (DOS). Кодировка времен MS-DOS, встречается в старых текстовых файлах.
• MacCyrillic. Кириллическая кодировка старых версий macOS.
• ISO 8859-5. Международный стандарт для кириллицы, в России практически не использовался.
• UTF-16, UTF-32. Редко встречаются в обычных текстовых файлах, но применяются внутри некоторых программ и систем (Windows API, Java String).

Одно слово — пять кодировок

Разница между кодировками нагляднее всего видна на одном слове. «Привет» — шесть букв, а байты за ними совершенно разные:

Однобайтовые кодировки укладываются в шесть байтов — по одному на букву, — но не совпадают ни в одной паре. UTF-8 тратит по два байта на каждую кириллическую букву, поэтому русский текст в нём вдвое длиннее, зато со своим почерком: старшие байты D0–D3 мелькают чуть ли не через символ. Именно на таких закономерностях построено автоматическое определение кодировки — байтовая статистика выдаёт ответ с высокой вероятностью даже без всяких маркеров.

Почему появляются «кракозябры»

Главная причина — несовпадение кодировки, в которой записан файл, с кодировкой, в которой его открывают. Типичные сценарии:

• Файл сохранён в Windows-1251, а открывается как UTF-8. Получаем «РџСЂРёРІРµС‚» вместо «Привет».
• Файл сохранён в UTF-8, а открывается как Windows-1251. Получаем «пїЅпїЅпїЅпїЅпїЅ» или похожие символы.
• Файл в KOI8-R открывается как Windows-1251. Получаем знакомую «потёмкинскую» кашу.
• Веб-страница отдаётся без указания кодировки, браузер угадывает и ошибается.
• База данных хранит текст в одной кодировке, а подключение к ней — в другой.

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

Кракозябры — это диагноз

Кракозябры — не хаос, а симптом: их характер почти однозначно указывает, какая именно подмена кодировок произошла. Проверьте испорченный текст по таблице:

Первые три случая лечатся за секунды: вставьте текст в определитель кодировки — он определит, что произошло, и покажет восстановленный текст. Последние два — повод вернуться к источнику данных, пока не потеряно то, что ещё можно спасти.

Как определить кодировку

Маркер BOM

Некоторые файлы начинаются с маркера порядка байтов (BOM, Byte Order Mark) — специальной последовательности байтов, которая указывает на кодировку и порядок байтов. BOM для UTF-8 — 0xEF 0xBB 0xBF, для UTF-16 LE — 0xFF 0xFE, для UTF-16 BE —0xFE 0xFF. Если файл начинается с BOM, кодировка известна точно. Но BOM добавляют не всегда, и в UTF-8 его часто опускают (особенно в вебе, где он может вызывать проблемы).

META-тег и HTTP-заголовки

В HTML-файлах кодировка указывается в теге <meta charset="utf-8"> или в HTTP-заголовке Content-Type. Если эти указания есть, браузер использует их. Если нет — начинает угадывать.

Статистический анализ

Когда явных маркеров нет, кодировку определяют по статистике байтов. Идея в том, что разные кодировки имеют разные частотные характеристики. В UTF-8 русский текст содержит много байтов из диапазонов 0xD0–0xD3 (старшие байты кириллицы). В Windows-1251 — из 0xC0–0xFF. В KOI8-R распределение тоже характерное. Анализируя распределение байтов, можно с высокой вероятностью угадать кодировку.

Современные библиотеки определения кодировки (например, jschardet для JavaScript, chardet для Python, uchardet для C++) используют статистические модели и эвристики. Они не дают 100% гарантии, но в большинстве практических случаев угадывают правильно.

Пробное декодирование

Самый надёжный способ — попробовать декодировать файл в каждой из возможных кодировок и посмотреть, в какой получается осмысленный текст. Если в UTF-8 все байты валидные и получаются осмысленные кириллические символы — это UTF-8. Если UTF-8 даёт ошибки декодирования — пробуем Windows-1251, KOI8-R и так далее. Человек сразу видит, в какой кодировке текст читается правильно.

Подводные камни

• Двойное кодирование. Если UTF-8-текст был ошибочно прочитан как Latin-1 и снова сохранён в UTF-8, получается « mojibake » — текст вида «РџСЂРёРІРµС‚». Восстановление требует обратного преобразования, и не всегда проходит без потерь.
• Смешанные кодировки. Иногда в одном файле встречаются фрагменты в разных кодировках (например, при склейке из разных источников). Статистический анализ выдаёт одну кодировку, а часть текста всё равно «кракозябры».
• Недетерминированность. Небольшие файлы (несколько символов) могут быть валидны в нескольких кодировках. Статистика не работает на малом объёме.
• Похожие кодировки. Windows-1251 и CP866 на коротких фрагментах дают похожее распределение байтов. Без контекста не отличить.
• BOM как часть данных. Если BOM случайно остался в середине файла (например, при склейке), он интерпретируется как символы и портит текст.
• Базы данных. Кодировка соединения с БД может не совпадать с кодировкой хранения. В MySQL это character_set_client, character_set_connection, character_set_database — три разные настройки, и рассинхрон любой из них даёт «кракозябры».

Сценарии использования

Открытие старого файла

Нашли в архиве текстовый файл десятилетней давности, открываете — «кракозябры». Инструмент определения кодировки покажет, что это Windows-1251 или CP866, и поможет перекодировать в UTF-8. После этого файл открывается нормально в любом современном редакторе.

Веб-страница без указания кодировки

Сайт отдаёт страницу без <meta charset> и без Content-Type. Браузер угадывает UTF-8, а на самом деле страница в Windows-1251. Решение — либо указать кодировку в настройках сервера, либо преобразовать сам файл в UTF-8.

Импорт данных из CSV

CSV-файл выгрузили из Excel в Windows-1251, а импортируете в систему, ожидающую UTF-8. Кириллица превращается в «кракозябры». Перед импортом файл нужно перекодировать. И наоборот: иногда CSV выгружается в UTF-8, а старая система ждёт Windows-1251.

Восстановление «испорченного» текста

Скопировали текст с сайта, вставили в редактор — «кракозябры». Это двойное кодирование. Существуют инструменты mojibake fixers, которые пробуют разные комбинации и восстанавливают исходный текст.

Анализ логов и старых данных

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

Лучшие практики

• Всегда используйте UTF-8. Это современный стандарт, поддерживающий все языки. В новых проектах UTF-8 — единственный разумный выбор.
• Указывайте кодировку явно. В HTML добавляйте <meta charset="utf-8">, в HTTP — заголовок Content-Type. В CSV-файлах добавляйте BOM, чтобы Excel правильно открывал UTF-8.
• Не сохраняйте файлы в Windows-1251 без необходимости. Если взаимодействуете со старыми системами, конвертируйте на границе, а внутри проекта храните в UTF-8.
• Проверяйте кодировку соединения с БД. В MySQL после подключения выполняйте SET NAMES utf8 (или utf8mb4 для поддержки эмодзи).
• Делайте резервные копии перед конвертацией. Перекодирование — разрушающая операция. Если ошиблись с исходной кодировкой, восстановить исходник без копии невозможно.
• Используйте BOM для UTF-8 в Windows-контексте. Excel и некоторые другие программы Windows лучше открывают UTF-8 с BOM.

Связанные инструменты

Для работы с кодировками полезны несколько инструментов ConvertHub:

• Кодирование в Unicode — превращает текст в unicode-escape последовательности (например, для безопасной передачи в JSON или JavaScript).
• Декодирование Unicode — обратное преобразование: unicode-escape последовательности обратно в читаемый текст.
• Base64-кодирование — для бинарных данных и текста в любой кодировке.

Подробнее об истории кодировок и переходе на UTF-8 — в материале про Unicode и UTF-8.

Заключение

Определение кодировки текста — задача, с которой хотя бы раз сталкивался каждый, кто работает с русскоязычными данными. Понимание того, как устроены кодировки, почему появляются «кракозябры» и какие методы помогают определить кодировку (BOM, статистика, пробное декодирование), позволяет быстро восстанавливать испорченный текст. Главное правило для новых проектов — всегда использовать UTF-8 и указывать кодировку явно. Воспользуйтесь инструментом декодирования Unicode при ближайших проблемах с кодировкой — и не забывайте делать резервные копии перед массовыми конвертациями.