Декодер текста: URL, HTML, Unicode, Base64

Выберите формат, вставьте исходную строку и нажмите «Обработать». URL-режим преобразует последовательности вида %D0%9F обратно в текст UTF-8. Режим HTML-сущностей раскрывает распространённые имена и числовые записи вроде & и П. Unicode escape преобразует записи вида обратный слеш, u и четыре шестнадцатеричные цифры. Base64 декодируется в байты, которые затем проверяются как UTF-8.

Выбирайте формат по признакам исходника. Проценты с двумя шестнадцатеричными символами обычно означают URL-кодирование, амперсанд с точкой с запятой — HTML-сущность, обратный слеш и u — Unicode escape. Base64 часто состоит из латинских букв, цифр, плюса, косой черты и знаков равенства на конце. Такой внешний вид не доказывает формат, поэтому проверяйте результат.

Незавершённый процент, например «%D0%», не является корректной URL-последовательностью. Генератор покажет ошибку вместо частично повреждённого текста. Base64 может содержать любые байты, а этот режим предназначен именно для текста UTF-8: двоичный файл или строка в другой кодировке не будут выданы как якобы читаемый текст.

У HTML-сущностей есть множество именованных форм. Этот инструмент поддерживает часто используемые имена и числовые ссылки; неизвестную сущность он оставляет без изменения. Если нужно обработать целую HTML-страницу, учитывайте, что разбор текстовых сущностей и разбор документа — разные задачи. Не вставляйте раскодированный HTML непосредственно в страницу без проверки безопасности.

«%D0%9F%D1%80%D0%B8%D0%B2%D0%B5%D1%82» в URL-режиме станет «Привет». «<strong>» в HTML-режиме станет «<strong>» как текст результата. «\u041F» в Unicode-режиме станет буквой «П». Для Base64 пример «0J/RgNC40LLQtdGC» превращается в «Привет». Результат можно скопировать либо скачать в TXT.

Инструмент делает один проход. Если данные закодированы дважды, например процент записан как %25, сначала раскодируется внешний слой. Повторный проход имеет смысл только после проверки промежуточного текста: автоматическое многократное декодирование может неожиданно превратить безопасную строку в разметку или управляющие символы.

Обработка полностью локальная; ввод не отправляется на сервер. Виджет скрыт от записи Вебвизора, в аналитике уходит только название инструмента и тип действия. Скачивание создаёт файл на устройстве. Для просмотра JSON после декодирования используйте JSON-форматировщик, для HTML — HTML-форматировщик, для ссылок с метками — разборщик UTM.

Если строка представляет токен доступа или секрет, не публикуйте её даже после декодирования. Base64 — способ представления байтов, а не шифрование. Декодированный текст может содержать личные данные. При внедрении обмена данными между сайтом и внешним сервисом команда Pugofka поможет определить формат, кодировку и безопасный путь обработки.

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

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

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

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

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

Для файлов важны и кодировка, и формат данных. CSV с русским Excel часто использует особый разделитель или кодировку; JSON по своему формату ожидает Unicode-текст. Прежде чем декодировать строку, определите, что именно вы получили: URL-параметр, HTML-фрагмент, содержимое файла или двоичный вложенный объект. Это сэкономит время на попытках исправить «не ту» проблему.

Не открывайте автоматически адрес, который получился после URL-декодирования. Сначала прочитайте домен и путь, особенно если строка пришла в письме или сообщении от незнакомого отправителя. Декодирование раскрывает символы, но не подтверждает безопасность сайта. Если результат похож на HTML или скрипт, просматривайте его как текст, а не вставляйте в консоль браузера или шаблон сайта.

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

Предположим, в логе виден фрагмент «%252Fcatalog%252F». Один проход URL-декодера превратит его в «%2Fcatalog%2F», второй — в «/catalog/». Это не всегда ошибка: приложение могло намеренно передать закодированный путь как значение параметра, чтобы слеш не разделял сегменты. Поэтому не запускайте второй проход автоматически. Посмотрите, на каком уровне строка используется: как URL целиком, как query-параметр или как часть JSON.

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

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

После проверки результата можно перейти к связанным задачам: JSON-форматировщик, HTML-форматировщик, Разработка на Битрикс. Используйте инструмент на настоящем образце перед публикацией результата.