Приходится иметь дело с форматом с URL-кодировкой? Тогда этот сайт идеально вам подойдет! Воспользуйтесь нашим невероятно удобным онлайн-инструментом для кодирования или декодирования ваших данных.

Кодирование «данного» в формат с URL-кодировкой

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

Кодирование файлов в формат с URL-кодировкой

Нажмите (или коснитесь) здесь, чтобы выбрать файл
Максимальный размер файла - 192 МБ.

Информация

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

URL-кодирование, которое также называется процентной кодировкой, предусматривает кодирование информации в унифицированном идентификаторе ресурса (URI). Несмотря на название, этот инструмент используется в основном наборе унифицированных идентификаторов ресурсов (URI), который включает в себя унифицированный указатель ресурсов (URL) и унифицированное имя ресурса (URN). Он также используется при подготовке данных типа «application/x-www-form-urlencoded», что часто требуется для отправки информации в HTML-формате в рамках HTTP-запросов.

Дополнительные параметры
  • Набор символов: наш веб-сайт использует набор символов UTF-8, и ваши входные данные также передаются в этом формате. Измените этот параметр, если вы хотите преобразовать данные в другой набор символов перед выполнением кодирования. Внимание: при использовании текстовой информации схема кодирования не содержит набор символов, поэтому в процессе декодирования может возникнуть необходимость в указании соответствующего набора. Что касается файлов, по умолчанию используется бинарный формат, который исключает преобразование; эта опция требуется для любых материалов, кроме текстовых документов.
  • Разделитель строк: в системах Unix и Windows используются разные символы переноса строк, поэтому перед кодированием оба варианта заменяются выбранным параметром. Что касается секции файла, частично это не имеет значения, поскольку файлы уже содержат соответствующие разделители, однако вы можете принять решение о том, какой из них использовать для функций «кодирование каждой строки» и «разделение строк на фрагменты».
  • Кодирование каждой строки: символы новой строки кодируются в проценты. Используйте этот параметр, если вам нужно закодировать несколько независимых записей, разделенных переносами строк. (*)
  • Разделение строк на фрагменты: закодированные данные превратятся в непрерывный текст без пробелов, так что эту опцию следует использовать, если вам нужно разделить его на несколько строк. Ограничение по количеству символов определено в спецификации MIME (RFC 2045), где указано, что длина закодированных строк не должна превышать 76 символов. (*)
  • Режим реального времени: при включении этой опции введенные данные немедленно кодируются с помощью встроенных функций JavaScript вашего браузера без отправки какой-либо информации на наши серверы. В настоящее время этот режим поддерживает только UTF-8.
(*) Эти параметры нельзя активировать одновременно, поскольку полученный результат окажется некорректным для большинства приложений.

Полная безопасность

Связь с нашими серверами поддерживается через защищенное зашифрованное по протоколу SSL соединение (https). Мы удаляем загруженные файлы с наших серверов сразу после обработки, при этом полученный загружаемый файл удаляется сразу после первой попытки загрузки или через 15 минут бездействия (в зависимости от того, какой период короче). Мы не храним и не проверяем предоставленные данные или загруженные файлы. Подробная информация представлена в нашей политике конфиденциальности.

Абсолютно бесплатно

Мы предлагаем бесплатный инструмент. Теперь вам не нужно скачивать программное обеспечение для решения таких простых задач.

Подробная информация о URL-кодировании

Типы URI-символов

Символы, предусмотренные URI, бывают зарезервированными или незарезервированными (или представлены в виде процентов, если речь идет о процентной кодировке). Зарезервированные символы - это символы, которые иногда имеют особое значение. Например, прямая косая черта используется для разделения частей URL (или, в более общем смысле, URI). Незарезервированные символы не имеют специального назначения. При процентном кодировании зарезервированные символы представляются в виде специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, слегка менялись с каждой новой версией спецификаций, которые регулируют URI и схемы URI.

RFC 3986, раздел 2.2, «Зарезервированные символы» (январь 2005 г.)
! * ' ( ) ; : @ & = + $ , / ? # [ ]

RFC 3986, раздел 2.3, «Незарезервированные символы» (январь 2005 г.)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Другие символы в URI должны быть закодированы в процентах.

Процентное кодирование зарезервированных символов

Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в конкретном контексте, а схема URI указывает на необходимость в использовании этого символа для другой цели, его следует преобразовать в процент. Процентное кодирование зарезервированного символа предполагает преобразование символа в соответствующее значение байта в ASCII, которое затем должно быть представлено в виде пары шестнадцатеричных цифр. Цифры, перед которыми стоит знак процента («%»), затем используются в URI вместо зарезервированного символа. (Символы, не относящиеся к ASCII, обычно преобразуют в последовательность байтов в UTF-8, после чего каждое значение байта представляют так, как описано выше.)

К примеру, зарезервированный символ «/», который используется в компоненте URI под названием «путь», имеет особое значение, поскольку разделяет сегменты пути. Если в соответствии с заданной схемой URI символ «/» должен быть включен в сегмент пути, в сегменте вместо «/» должны использоваться три символа «%2F» (или «%2f»).

Зарезервированные символы после процентного кодирования
! # $ & ' ( ) * + , / : ; = ? @ [ ]
%21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

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

В компоненте URI «запрос» (часть после «?»), например, «/» по-прежнему считается зарезервированным символом, но обычно не имеет зарезервированного назначения (если схемой URI не предусмотрено иное). Символ не должен кодироваться в процентах, если у него нет зарезервированного назначения.

URI, которые отличаются только тем, кодируется ли зарезервированный символ в процентах или нет, обычно считаются не эквивалентными друг другу (обозначающими один и тот же ресурс) при условии, что рассматриваемые зарезервированные символы не имеют зарезервированного назначения. Это определение зависит от правил, предусмотренных в отношении зарезервированных символов конкретными схемами URI.

Процентное кодирование незарезервированных символов

Символы из незарезервированного набора не должны кодироваться в процентах.

URI, которые отличаются только тем, кодируется ли незарезервированный символ в процентах или нет, эквивалентны по определению, но URI-обработчики на практике не всегда воспринимают их равноценно. Например, URI-потребители не должны разделять «%41» и «A» («%41» обозначает это процентное кодирование «A») или «%7E» от «~», но иногда дело обстоит именно так. Поэтому для обеспечения максимальной совместимости URI-производителям не рекомендуется применять процентное кодирование к незарезервированным символам.

Процентное кодирование символа с процентом

Поскольку символ с процентом («%») служит индикатором для октетов, закодированных в процентах, он должен кодироваться в процентах как «%25», чтобы этот октет можно было использовать в качестве данных в URI.

Процентное кодирование произвольных данных

Большинство схем URI содержат произвольные данные, такие как IP-адрес или путь в файловой системе, которые являются компонентами URI. Спецификации схем URI должны обеспечивать явное соотнесение URI-символов со всеми возможными значениями данных, представленными этими символами, но зачастую дело обстоит не так.

Двоичные данные

С момента публикации RFC 1738 в 1994 году вышло указание о том, что схемы, которые предусматривают представление двоичных данных в URI, должны разделять данные на 8-битные байты и кодировать каждый байт в процентах так же, как описано выше. Например, значение байта 0F (шестнадцатеричное) должно быть представлено в виде «%0F», но значение байта 41 (шестнадцатеричное) может быть представлено как «A» или «%41». Использование незашифрованных символов в отношении буквенно-цифровых и других незарезервированных символов обычно предпочтительнее, поскольку это позволяет получить более короткие URL-адреса.

Символьные данные

Процедура процентного кодирования двоичных данных зачастую (иногда ненадлежащим образом или в отсутствие полной информации) экстраполируется на символьные данные. В годы формирования Всемирной паутины при работе с символами данных в ASCII и использовании соответствующих байтов в ASCII в качестве основы для определения последовательностей, кодируемых в процентах, такая практика была относительно безобидной; многие считали, что символы и байты соотносятся друг с другом и являются взаимозаменяемыми. Однако потребность в представлении символов за пределами диапазона ASCII быстро росла, и URI-схемы и протоколы зачастую уже не могли обеспечить стандартные правила подготовки символьных данных для включения в URI. В связи с этим в веб-приложениях начали использовать различные многобайтовые кодировки, кодировки с контролируемым состоянием и другие кодировки, не совместимые с ASCII, в качестве основы для процентного кодирования, что привело к неоднозначности, а также затруднило достоверную интерпретацию URI.

К примеру, в соответствии со многими схемами и протоколами URI, основанными на RFC 1738 и 2396, символы данных необходимо сначала преобразовывать в байты согласно неопределенной символьной кодировке, прежде чем включать их в URI с помощью незарезервированных символов или кодированных в процентах байтов. Если схема не позволяет включить в URI подсказку о том, какая кодировка была использована, или если кодировка противоречит использованию ASCII в отношении зарезервированных и незарезервированных символов с процентной кодировкой, то достоверная интерпретация URI становится невозможной. В некоторых схемах кодирование вообще не учитывается. Вместо этого просто предполагается, что символы данных напрямую соотносятся с символами URI, в результате чего решение о том, кодировать ли символы данных, которые не входят ни в зарезервированные, ни в незарезервированные наборы, и как это делать, остается за пользователями.

Распространенные символы после процентного кодирования (на основе ASCII или UTF-8)
новая строка пробел " % - . < > \ ^ _ ` { | } ~
%0A или %0D или %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

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