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

Что делает этот инструмент

В адресах допустим лишь ограниченный набор символов ASCII. Всё остальное — пробелы, кириллица, иероглифы, &, =, ?, # и большая часть пунктуации — должно быть закодировано процентами как последовательности %XX, прежде чем отправиться в ссылку, отправку формы или вызов API. Эта страница кодирует в обе стороны и, в отличие от большинства кодировщиков, ещё и разбирает результат: вставьте любой адрес или строку запроса, и параметры появятся раскодированной таблицей «ключ — значение», так что рекламную ссылку или редирект OAuth можно прочитать с одного взгляда.

Текст трактуется как UTF-8, поэтому «текст» превращается в %D1%82%D0%B5%D0%BA%D1%81%D1%82 ровно так, как этого ждут браузеры и серверы. Декодирование снисходительное: одиночный %, не образующий корректной последовательности, остаётся как есть, а не вызывает ошибку, а + считается пробелом, когда вы раскодируете данные формы.

Значение или адрес целиком

«Кодировать значение» — это encodeURIComponent из JavaScript: экранируется всё, кроме букв, цифр и -_.!~*'(). Берите его для одного значения, которое пойдёт в параметр запроса, сегмент пути или поле формы. «Кодировать адрес» — это encodeURI: он не трогает структурные символы :/?#[]@!$&'()*+,;=, чтобы полный адрес остался корректным адресом, и экранирует только пробелы и не-ASCII. Выбрать не то — классическая ошибка: encodeURIComponent на полном адресе превращает каждую / в %2F и ломает ссылку, а encodeURI на значении, содержащем &, молча разрезает его на два параметра.

Переключатель «Пробел как +» выбирает между %20 (RFC 3986, применяется в адресах) и + (application/x-www-form-urlencoded, применяется в телах HTML-форм и во многих старых строках запроса). Раскодируются здесь оба варианта; выбирайте тот, которого ждёт принимающая сторона.

Частые ошибки

Двойное кодирование: если закодировать уже закодированное значение, %20 превратится в %2520, и сервер увидит буквальное «%20». Если в раскодированном выводе всё ещё встречаются последовательности %XX, раскодируйте ещё раз. Незакодированные & или # внутри значения обрезают параметр. Кодирование всего адреса через encodeURIComponent ломает схему и косые черты. Разные соглашения о + и %20 на клиенте и сервере дают плюсы в именах пользователей. И наконец, процентное кодирование — это не шифрование и не сокрытие: после раскодирования значение читается полностью, поэтому прятать в нём токены нельзя; если полезную нагрузку нужно сделать непрозрачной для канала передачи, обычно берут Base64, но и он обращается тривиально.

История: откуда взялось процентное кодирование

Процентное кодирование появилось вместе с первой спецификацией URL, RFC 1738 (1994), написанной Тимом Бернерсом-Ли и коллегами, и было уточнено в RFC 3986 (2005) — действующем стандарте синтаксиса URI. Механизм с экранированием через % старше повсеместного UTF-8, поэтому старые системы иногда кодируют байты в Latin-1 или Shift-JIS и дают крокозябры при раскодировании как UTF-8; стандарт URL от WHATWG наконец предписал UTF-8 для нового кодирования. Соглашение «+ вместо пробела» пришло из отдельной спецификации HTML-форм, а не из стандарта URL, — по этой исторической причине два способа кодировать пробел сосуществуют до сих пор.

Где это нужно

Сборка запросов к API вручную (поисковые фразы, фильтры, адреса обратного вызова), разбор рекламных ссылок (utm_source, gclid, fbclid), чтение редиректов OAuth и SSO (redirect_uri, state, scope), построение ссылок mailto: и tel: с темой и текстом письма, ссылки с кириллическими или японскими путями, изучение полезной нагрузки вебхуков, присланной как данные формы. Таблица параметров удобна, когда нужно вставить длинный адрес из заявки в поддержку и увидеть, что именно запрашивалось. Значения внутри строки запроса часто оказываются JSON или Base64 — раскодируйте их здесь, а затем вставьте в соответствующий инструмент.

Частые вопросы