Кодировка URL: когда бежать, а когда что-то ломаешь

Что необходимо закодировать

Небольшой набор символов всегда безопасен — буквы, цифры, `-`, `_`, `.` и `~`. Все остальное либо зарезервировано, либо должно быть экранировано. Зарезервированные символы являются интересными, поскольку они разрешены в URL-адресе, но только в определенных позициях: `?` запускает запрос, `&` разделяет параметры, `=` присваивает значение, `#` запускает фрагмент, `/` разделяет сегменты пути. Поместите один из них в незакодированное значение, и вы незаметно перепишете структуру URL-адреса.

Плюс или %20

Космос – классический пример. В пути пробел должен быть `%20`; а `+` это буквальный плюс. В телах `application/x-www-form-urlencoded` и строках запроса, считываемых анализаторами форм, `+` понимается как пробел. Это расхождение объясняет, почему значение может кодироваться во что-то, что работает в одном контексте и не работает в другом, и почему декодеры предлагают обе интерпретации.

Кодируйте компоненты, а не целые URL-адреса. Запуск полного URL через компонентный кодер экранирует его собственные `://` и `?`, создавая ссылку, которая ни к чему не приводит.

Отличие JavaScript, которое привлекает всех

                encodeURI('https://x.com/a b?q=1')        // keeps :// ? = — for a whole URL
encodeURIComponent('a b?q=1')               // escapes ? and = — for one value
              

`encodeURI` сохраняет структуру URL и предназначен для полного адреса; `encodeURIComponent` экранирует все существенное и предназначено для одного значения параметра. Использование неправильного приводит либо к неработающему URL, либо к неэкранированному значению, а симптомы противоположны: ссылка с ошибкой 404 или строка запроса, которая теряет половину своих параметров.

Двойное кодирование и подписанные URL-адреса

Кодирование уже закодированного значения превращает `%20` в `%2520`, а затем сервер декодирует его один раз и передает вашему приложению литерал `%20` там, где был предназначен пробел. Это проявляется в многоуровневых системах: прокси-сервер перекодирует цель, клиент экранирует полученный URL-адрес, который уже экранирован. Это наиболее важно для подписанных URL-адресов: подписи вычисляются по точной закодированной строке, поэтому изменение экранирования одного символа делает ссылку недействительной, даже если она по-прежнему разрешается к тому же ресурсу.

Декодирование для отладки

Когда ссылка не работает, ее декодирование — это самый быстрый способ узнать, что на самом деле запрашивается у сервера — и ответом часто является значение, которое просочилось в структуру. Работа в браузере означает, что вы можете вставить URL, содержащий токены, подписанные параметры или идентификаторы клиентов, не отправляя его куда-либо. Это именно тот тип URL, который не следует вставлять в службу, регистрирующую запросы.