Кодировка URL-адреса для пробелов: %20 или Plus?

Пробел в данных URL обычно становится %20, но сериализация запроса в стиле формы представляет его как +. Оба могут быть правильными. Правильный вывод зависит от места назначения: используйте процентное кодирование для отдельного компонента URI и используйте соглашение «плюс» только тогда, когда принимающий рабочий процесс ожидает приложение/x-www-form-urlencoded данные.

Этот ClockTools URL-кодировщик делает этот контекст явным с помощью профилей компонента URI, полного URL-адреса и данных формы. Вставить зеленый чай, переключите профили и сравните выходные данные перед изменением кода приложения.

Начните с пункта назначения

Не спрашивайте: «Какой символ всегда означает пробел?» Спросите, какой парсер получит значение.

Для сегмента пути, значения фрагмента или значения отдельного запроса надежным представлением является процентное кодирование. Байт UTF-8 символа пробела является шестнадцатеричным. 20, поэтому его тройка с процентным кодированием равна %20.

Для данных в стиле формы HTML соглашение о сериализации использует + для пробелов и процентов кодирует буквальный плюс как %2Б. Стандарт URL-адреса WHATWG определяет это поведение, закодированное в виде URL-адреса, отдельно от общего анализа URL-адресов.

Этот Синтаксис URI RFC 3986 определяет октет с процентным кодированием как % за которыми следуют две шестнадцатеричные цифры. Он также отличает зарезервированные разделители от незарезервированных символов данных. Это различие является причиной того, что кодирование значения отличается от кодирования всего адреса.

Таблица решений %20 по сравнению с плюсом

Последняя строка предотвращает распространенную ошибку. Если предполагаемое значение C++, отправка C++ через декодер формы может создать С . Закодируйте каждый литерал плюс как %2Б перед разбором формы.

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

Мы выполнили четыре небольших ввода через текущую реализацию инструмента. Его профиль компонента URI использует JavaScript. кодироватьURIComponent. Данные формы применяют ту же кодировку компонента, а затем заменяют %20 с +. Полный URL-адрес использует кодироватьURI, который сохраняет структуру URL.

Это детерминированные результаты трансформации, а не доказательства поискового ранжирования. Вы можете воспроизвести их локально в браузере. Страница немедленно обновляет выходные данные, сообщает об экранированных процентах и ​​количестве байтов, и ей не нужно отправлять входные данные на сервер для преобразования.

Используйте URL-декодер чтобы запустить обратную проверку. Декодировать зеленый%20чай под профилем компонента и зеленый+чай в разделе «Данные формы». Декодер предупреждает, когда под профилем, не являющимся формой, появляется плюс, поскольку предполагаемое значение неоднозначно.

Что защищает кодирование компонентов?

В URL-адресе в качестве грамматики используются пунктуация. В строке запроса & может начать другой параметр и = отделяет имя от значения. # начинается фрагмент. ? начинает запрос. Если один из этих символов принадлежит пользовательским данным, оставление его необработанным может изменить структуру.

Рассмотрим значение таймер и будильник. Кодирование компонентов производит таймер%20%26%20будильник. Амперсанд становится %26, поэтому парсер получает одно значение вместо интерпретации сигнализация в качестве нового параметра.

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

Когда вам нужно сравнить строку запроса «до» и «после», Проверка текстовых различий делает каждый измененный escape видимым. Это более надежно, чем сканирование длинного URL-адреса обратного вызова на предмет отсутствия одного из них. %25.

Почему двойное кодирование создает %2520?

Двойное кодирование происходит, когда уже закодированный текст обрабатывается как необработанные данные и кодируется снова.

Начните с одного пробела:

```текст

пробел -> %20

```

Кодировать %20 как новый компонент. Знак процента становится %25, а цифры остаются буквальными:

```текст

%20 -> %2520

```

Одно декодирование меняется %2520 вернуться к %20. Второе декодирование меняется %20 в пространство. Если ваше приложение ожидает один проход декодирования, но получает значение с двойным кодированием, пользователь может увидеть %20 вместо пустого.

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

Путь отладки несоответствия пространства

Используйте этот путь, когда одна система отправляет %20 и еще один дисплей +, %2520или буквальный пробел.

1. Захватите необработанное значение до того, как какой-либо анализатор платформы изменит его.

2. Определите, является ли поле сегментом пути, компонентом запроса, полным URL-адресом или телом формы.

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

4. Воспроизведите тот же ввод в соответствующем профиле ClockTools.

5. Декодируйте один раз с помощью принимающего профиля.

6. Сравните результат с ожидаемым значением.

7. Найдите в потоке приложения второй кодер или декодер, если %25 появляется неожиданно.

Этот путь отладки намеренно узок. Он отделяет контекст данных от догадок, и каждый шаг имеет видимые входные и выходные данные.

Когда следует кодировать полный URL-адрес?

Используйте профиль «Полный URL-адрес» только в том случае, если вы хотите, чтобы адрес оставался адресом. Он сохраняет структурные знаки пунктуации, такие как двоеточие схемы, косая черта, вопросительный знак, знак равенства, амперсанд и маркер фрагмента, при кодировании таких символов, как пробелы.

Используйте компонент URI, когда полный URL-адрес вложен в другой параметр. Например, адрес обратного вызова, помещенный в перенаправление= это данные с точки зрения внешнего URL. Кодирование вложенного адреса как одного компонента предотвращает его ? и & от присоединения к внешнему запросу.

Не передавайте адрес повторно через разные профили в надежде получить универсально безопасную строку. Напишите границу явно:

```текст

внешняя структура URL + encodeURIComponent (внутренний URL обратного вызова)

```

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