Кодирование и декодирование URL

Кодирование и декодирование URL применяет percent-encoding RFC 3986 к тексту и обращает последовательности %HH обратно в символы. Режим компонента кодирует зарезервированные символы вроде /, ? и &, чтобы они могли безопасно сидеть внутри одного параметра запроса. Режим полного URI сохраняет структурные разделители, чтобы полный адрес оставался рабочей ссылкой. Обработка пробелов предлагает и %20, и плюс формы.

Всё кодирование и декодирование выполняется в браузере. Ничего из вставленного не отправляется на сервер.

Кодирование текста для безопасного использования в URL

Percent-encoding заменяет небезопасные или зарезервированные байты знаком процента, за которым следуют две шестнадцатеричные цифры. Цифры это значение байта, обычно из UTF-8. Введите строку, выберите режим компонента или полного URI и скопируйте закодированный результат в query string, сегмент пути или цель редиректа.

Символы, уже входящие в незарезервированный набор, проходят без изменений. Всё остальное в режиме компонента становится последовательностями %HH. Кодирование обратимо, когда на декодировании те же правила; смешение плюса form-encoding с %20 в стиле пути это обычный источник сломанных циклов.

Декодирование percent-encoded строки

Декодирование находит каждый %, за которым следуют две hex-цифры, переводит эту пару в байт и восстанавливает исходный текст с выбранной кодировкой символов. Один % или % с не-hex цифрами это ошибка. Плюсы можно опционально трактовать как пробелы, когда ввод пришёл из тел application/x-www-form-urlencoded.

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

Зарезервированные и незарезервированные символы

RFC 3986 делит ASCII на незарезервированные символы, которым никогда не нужно кодирование в URI, и зарезервированные символы, несущие структурный смысл вроде разделителей. Незарезервированные буквы, цифры и -_.~ остаются буквальными. Зарезервированные знаки вроде /, ? и & должны быть percent-encoded, когда они появляются как данные, а не как синтаксис, обрамляющий URL.

Незарезервированные: A-Z, a-z, 0-9, дефис -, подчёркивание _, точка ., тильда ~

Зарезервированные (gen-delims): `: / ?

Зарезервированные (sub-delims): ! $ & ' ( ) * + , ; =

Незарезервированные символы остаются буквальными. Зарезервированные должны кодироваться, когда они данные, а не разделители. Вопросительный знак внутри значения параметра это данные; вопросительный знак, начинающий query string, это структура. Выбор режима это то, как калькулятор знает, какую роль играет каждый символ.

Кодирование целого URL и одного параметра

Кодирование полного URI, похожее на JavaScript encodeURI, оставляет структурные символы нетронутыми, чтобы https:// и слэши пути сохранились. Кодирование компонента, похожее на encodeURIComponent, кодирует эти символы, чтобы значение могло сидеть внутри параметра, не ломая окружающий URL. Неверный режим либо уничтожает ссылку, либо оставляет разделители, которые неправильно делят query.

Ввод	Стиль полного URI	Стиль компонента
https://example.com/a b	https://example.com/a%20b	https%3A%2F%2Fexample.com%2Fa%20b
red&blue	red&blue	red%26blue
a=b	a=b	a%3Db

Кодирование всего URL режимом компонента уничтожает его как ссылку: двоеточие схемы и слэши становятся %3A и %2F. Кодирование одного параметра режимом полного URI оставляет & и = нетронутыми, что неправильно делит query. Выберите режим под слот, который займёт строка.

Кодирование слэша и вопросительного знака

Тестовая строка / and ? в режиме компонента становится %2F%20and%20%3F. Слэш и вопросительный знак это зарезервированные разделители, здесь трактуемые как текст данных, поэтому каждый экранируется. Пробелы становятся %20, буквы в and незарезервированы и проходят без изменений слева направо по строке.

Символ	Причина	Закодировано
/	зарезервированный разделитель пути	%2F
пробел	не незарезервированный	%20
a, n, d	незарезервированные буквы	без изменений
?	зарезервированный разделитель query	%3F

Пройдите строку слева направо: закодируйте /, закодируйте пробел, пропустите and, закодируйте пробел, закодируйте ?. Результат %2F%20and%20%3F безопасен для размещения в параметре запроса, например q. Режим полного URI на той же строке оставил бы / и ? буквальными, что верно только когда эти символы задуманы как структура, а не как текст данных.

%20 и знак плюс

Пробел кодируется как %20 в путях URI и в современных query strings по RFC 3986. HTML-формы, отправляющиеся как application/x-www-form-urlencoded, исторически кодируют пробелы как +. Обе конвенции встречаются в продакшене, и трактовка их как идентичных это самая частая ошибка пробелов при декодировании смешанных входов.

Контекст	Кодирование пробела
Сегмент пути	%20
Query по RFC 3986	%20
Тело формы / legacy query	+

Буквальный плюс в данных должен кодироваться как %2B, иначе form-декодер превратит его в пробел. Калькулятор помечает, какая конвенция пробелов активна, чтобы декодированный + не приняли за символ плюс при включённом form-режиме, а %20 не отклонили при path-режиме.

Разбор URL на части

Типичный URL имеет схему, хост, необязательный порт, путь, query string и fragment; правила кодирования различаются по частям. Структурные разделители вроде ://, /, ?, &, = и # остаются буквальными, когда они обрамляют адрес.

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

https://example.com:443/search?q=a%20b&lang=en#top
└─┬─┘   └─────┬─────┘ └─┬──┘ └───────┬───────┘ └┬┘
схема       хост     путь        query      fragment

Часть	Роль
Схема	Протокол, например https
Хост	Домен или IP, с необязательным портом
Путь	Расположение ресурса, через слэши
Query	Список параметров после ?, через &
Fragment	Клиентская якорная часть после #, не отправляется на сервер в request URI так же

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

Таблица кодирования символов

Таблица ниже перечисляет распространённые зарезервированные и небезопасные символы с их percent-формами при UTF-8 кодировании байтов. Пробел становится %20, амперсанд %26, решётка %23. Не-ASCII символы разворачиваются в несколько единиц %HH, потому что каждый байт UTF-8 кодируется отдельно, а не как один абстрактный глиф.

Символ	Percent	Примечания
пробел	%20	Или + в form-encoding
!	%21
#	%23	Разделитель fragment
$	%24
&	%26	Разделитель пар query
'	%27
(	%28
)	%29
+	%2B	Буквальный плюс
,	%2C
/	%2F	Разделитель пути
:	%3A	Разделитель схемы / хоста
;	%3B
=	%3D	Присвоение параметра
?	%3F	Начало query
@	%40	Разделитель userinfo
[	%5B
]	%5D

Не-ASCII текст сначала выражается как байты UTF-8, затем каждый байт percent-encoded. Один видимый символ поэтому может развернуться в две или три единицы %HH. Подробности legacy charset вроде Shift JIS живут у инструмента Base64; эта страница ссылается, а не повторяет тот каталог.

Часто задаваемые вопросы

Итог

Кодирование и декодирование URL percent-encode и декодирует текст по правилам RFC 3986, с отдельными режимами для полных URI и отдельных компонентов. Тестовый fixture / and ? становится %2F%20and%20%3F в режиме компонента. Пробелы используют %20 в контекстах URI и могут использовать + в form-encoding, это другая конвенция.

Зарезервированные символы сохраняют смысл только когда оставлены буквальными как структура; кодируйте их, когда они данные. Вся работа остаётся на устройстве.