Декодер текста

Как исправить кракозябры в тексте

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

Ручной вариант нужен, когда известен источник поломки. «Прочитано как» означает таблицу, по которой программа уже превратила байты в видимые кракозябры. «Читать как» означает таблицу, по которой эти байты следовало прочитать. Подпись Windows-1251 → UTF-8 под результатом повторяет именно этот обратный путь. Вручную доступны шесть кодировок, а автоматический поиск проверяет до двух последовательных слоёв порчи.

1. Скопируйте исходную строку в безопасное место и не сохраняйте поверх неё результат эксперимента.
2. Попробуйте автоматический режим на связном фрагменте из нескольких слов или строк.
3. Проверьте результат по именам, числам, кавычкам, знакам валюты и смыслу соседних строк.
4. Если автоматический ответ сомнителен, выберите пару вручную по таблице ниже.

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

Какую пару кодировок попробовать первой

Внешний рисунок не доказывает историю файла, но хорошо задаёт первую гипотезу. Особенно узнаваемы повторяющиеся пары Р... и С..., западноевропейские сочетания Ã и Â, а также псевдографика из старых DOS-таблиц. Все примеры ниже можно воспроизвести в ручном режиме декодера.

Похожая строка может иметь несколько объяснений. Например, байты C3 A9 превращаются в é и при Windows-1252, и при классической ISO-8859-1, потому что именно эти две позиции в таблицах совпадают. Отдельной ISO-8859-1 в селекте нет: современная веб-платформа трактует её метки как Windows-1252. Одного слова всё равно недостаточно, чтобы доказать, какая программа и какая метка участвовали в ошибке.

Что происходит с байтами на каждом шаге

1. Русское слово в UTF-8. Буква «П» записана байтами D0 9F, а «р» байтами D1 80. При чтении этих четырёх байтов как Windows-1251 получаются знаки РџСЂ. Обратный путь Windows-1251 → UTF-8 восстанавливает начало слова «Пр» без угадывания букв.

2. Французское café. Буква é имеет код U+00E9 и в UTF-8 занимает байты C3 A9. Windows-1252 показывает их как é, поэтому всё слово становится café. Латинские c, a и f не меняются, потому что лежат в общей ASCII-части таблиц.

3. Знак евро. В UTF-8 символ € занимает три байта E2 82 AC. Windows-1252 назначает этим значениям знаки â, ‚ и ¬, поэтому появляется характерное €. Такой фрагмент часто выдаёт ошибку увереннее обычных латинских букв.

4. Сигнатура UTF-8. Три начальных байта BOM EF BB BF, прочитанные как Windows-1251, превращаются в п»ї. После обратного прохода получится невидимый U+FEFF перед текстом. Его можно убрать из начала документа, но сначала стоит проверить, что следующая за ним строка восстановилась тем же путём.

5. Двойной проход. Первый неверный импорт превращает café в café, а второй превращает уже этот результат в café. Исправление идёт в обратном порядке: один проход снимает последний слой, второй возвращает исходную букву. На каждом этапе результат должен оставаться строго обратимым.

Почему «Привет» превращается ⠫Привет»

Текстовый файл состоит из байтов, каждый байт имеет значение от 0 до 255. Кодировка задаёт правило, по которому один байт или последовательность байтов превращаются в кодовые точки Unicode. Шрифт уже после этого рисует кодовым точкам видимые знаки. Поэтому одинаковые байты могут дать разные буквы, а одинаково выглядящие буквы могут иметь разное внутреннее представление.

У русской буквы «П» кодовая точка U+041F. В UTF-8 она записывается двумя байтами: D0 9F. Если прочитать их независимо по Windows-1251, байт D0 даст «Р», а 9F даст «џ». Так начало слова «Привет» получает характерный префикс РџСЂ.... Декодер делает обратное: превращает «Рџ» в байты D0 9F, а затем читает их как UTF-8 и возвращает «П».

Базовая латиница, цифры и простая пунктуация относятся к диапазону ASCII от 0 до 127. Их значения можно проверить в конвертере ASCII-кодов. UTF-8 сохраняет для них те же однобайтовые значения, а большинство старых однобайтовых кодировок тоже не меняет нижнюю половину таблицы. Поэтому OK 123, адрес сайта или часть артикула могут пережить ошибку без единого заметного следа, хотя соседняя кириллица уже превратилась в мусор.

Современный UTF-8 использует от одного до четырёх байтов на одну кодовую точку. Базовые русские буквы занимают по два байта, многие эмодзи по четыре. Но видимый знак не всегда равен одной кодовой точке: эмодзи с оттенком кожи, флаг или семейная пиктограмма могут состоять из нескольких кодовых точек. Поэтому один воспринимаемый глазом знак иногда занимает больше четырёх байтов. Разницу между байтом, кодовой точкой и графемой подробнее объясняет материал о том, что считать символом в цифровом тексте.

Как автоматический режим выбирает результат

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

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

Среди допустимых вариантов выше оцениваются строки без управляющих знаков, U+FFFD, псевдографики и характерных сочетаний mojibake. Для русской фразы помогают частые пары букв, нормальное соотношение гласных и согласных, отсутствие хаотичного смешения латиницы с кириллицей. Это языковая эвристика, а не доказательство и не понимание смысла.

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

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

Какие кодировки поддерживает декодер

UTF-8 является переменной многобайтовой кодировкой Unicode. Остальные пять вариантов в калькуляторе являются однобайтовыми: нижние 128 значений совместимы с ASCII, а верхняя половина назначает байтам разные буквы, знаки и элементы псевдографики. Контекст происхождения помогает выбрать пару, но не заменяет проверку результата.

У этих названий есть история. UTF-8 был придуман Кеном Томпсоном в сентябре 1992 года при участии Роба Пайка, а позднее закреплён для интернета в RFC 3629. KOI8-R зарегистрировали в RFC 1489 в 1993 году как широко используемый формат для Unix и сетевых приложений бывшего СССР. IBM866 сохранила не только русские буквы, но и множество знаков псевдографики, нужных текстовым интерфейсам DOS.

Есть и неочевидная веб-особенность. По правилам современной веб-платформы метки latin1, iso-8859-1 и даже us-ascii при декодировании страницы ведут к Windows-1252. Это историческая совместимость браузеров, а не утверждение, что исходные стандарты полностью одинаковы. Поэтому название, показанное старой программой, и фактическая таблица браузера могут расходиться.

Слово «ANSI» в старом диалоге сохранения тоже не называет одну универсальную кодировку. В разных локалях и программах за ним могли скрываться разные системные кодовые страницы. Для русского Windows-наследия разумной первой гипотезой будет Windows-1251, но само слово «ANSI» ещё ничего не доказывает.

BOM, charset и момент, когда возникает поломка

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

UTF-8 может начинаться с трёх байтов EF BB BF, известных как BOM. Для UTF-8 порядок байтов менять не требуется, поэтому здесь BOM работает скорее как сигнатура формата. Если эти три байта прочитать как Windows-1251, в начале текста появится знакомое п»ї. Сам по себе этот префикс не портит остальные данные, но хорошо указывает, что UTF-8 открыли не той таблицей.

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

Знаки �, ?, пустой квадрат и невидимые символы

Символ � имеет код U+FFFD и официальное название REPLACEMENT CHARACTER, знак замены. Декодер часто подставляет его, когда последовательность байтов нельзя корректно прочитать по выбранным правилам. U+FFFD является допустимой кодовой точкой и теоретически мог присутствовать в исходнике буквально, но в кракозябрах обычно обозначает место потери. Он не хранит исходные значения: один знак замены может соответствовать целой недопустимой подпоследовательности, а не ровно одному байту.

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

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

Пустой квадрат, прямоугольник или значок с шестнадцатеричным номером часто указывает не на кодировку, а на отсутствие нужного глифа в шрифте. Кодовая точка при этом может оставаться целой. Скопируйте знак в современный редактор или смените шрифт: если он появился, преобразовывать байты не нужно. В строке также может находиться невидимый U+FEFF. Комбинируемый акцент устроен иначе: отдельного места он обычно не занимает, но меняет вид соседней буквы.

Двойная и смешанная порча

При двойной порче результат первой ошибки успели сохранить, а затем повторили тот же или другой неверный проход. Хорошо узнаваемая цепочка выглядит так: café → café → café. Обратные действия выполняются с конца. Первый проход вернёт café, второй вернёт café.

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

Смешанная порча устроена иначе. Заголовок мог прийти из современной системы, а описание из старой базы:

Тема: Привет
Описание: Привет

Строгий декодер отклонит преобразование всей строки как необратимое; менее осторожная программа может испортить уже правильный заголовок. Разделите текст по границе, восстановите только описание и затем соедините части. Такой же подход нужен, когда в CSV один столбец импортирован иначе, чем остальные, или несколько файлов склеили после разных этапов обработки.

Что выглядит странно, но не является mojibake

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

Base64 ничего не шифрует и не обещает, что внутри находится текст. После декодирования можно получить изображение, архив или набор байтов, который ещё нужно прочитать как UTF-8 либо другую кодировку. В URL каждая запись %HH представляет один байт; для русской буквы обычно требуется несколько таких троек. Поэтому простое удаление символов процента даст неверный результат.

Даже одинаковое изображение буквы не гарантирует одинаковую последовательность Unicode. Например, é может быть одной кодовой точкой U+00E9 или сочетанием e и комбинируемого акцента U+0301. Это вопрос нормализации Unicode, а не mojibake. Декодер кодировок не должен самовольно менять такие эквивалентные записи.

Как проверить и сохранить исправленный текст

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

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

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

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

Похожие калькуляторы

Возможно вам пригодятся ещё несколько калькуляторов по данной теме:

• Конвертер ASCII-кодов. Переводите латинский текст в десятичные, HEX- и двоичные коды и обратно.
• URL-кодировщик и декодировщик. Кодируйте текст для URL и декодируйте процентную запись.
• Конвертер Base64. Кодируйте текстовую строку в Base64 и декодируйте её обратно в UTF-8.
• Форматтер и валидатор JSON. Проверьте JSON, приведите его к читаемому виду или сожмите без потери данных.
• Визуальный редактор HTML. Редактируйте бесплатно и онлайн HTML-код, и сразу же смотрите внешний вид текста и страницы в режиме предпросмотра (WYSIWYG).
• Генератор паролей. Создайте сложный и надёжный пароль бесплатно с помощью онлайн-генератора из 8, 10, 12 или большего числа рандомных (случайных) символов.
• Генератор QR-кода. Вставьте ссылку или текст. Готовый QR-код можно скопировать или скачать как PNG.
• Сумма прописью. Переведите сумму в виде цифр в сумму прописью - текстом. Сделайте расшифровку правильно для договоров и других документов.
• Хрономер: время чтения текста. Оцените, сколько времени займёт чтение или произнесение текста вслух. Просто введите текст в форму, и хронометраж рассчитается автоматически.
• Рандомайзер: генератор случайных чисел. Выберите случайное число в нужном диапазоне для любых целей, в частности для розыгрышей и онлайн-лотерей в соцсетях.

Есть что добавить?

Напишите своё мнение, комментарий или предложение.