Почему отличается кодировка URL-адреса и части строки запроса?

Я изучал, почему у моих параметров запроса есть плюсы + в нем вместо %20 и почему у них есть строки типа %C3%BC вместо ü (UTF-8) в качестве кодированного URL-адреса.

После 2 часов размышления мой webapp не совместим со стандартом кодирования URL-адресов, я обнаружил, что схема кодирования строки запроса не совпадает с кодировкой URL-адреса (здесь я имею в виду часть без строки запроса).

Примеры:

URL:
- пробелы кодируются в %20
- Символы UTF-8 остаются символами UTF-8
Параметры запроса:
- пробелы кодируются до +
- Шаблоны UTF-8 кодируют шестнадцатеричное представление

Так может кто-нибудь сказать мне, почему схемы кодирования отличаются, поскольку параметры запроса являются частью URL?

См:

Ответ 1

URI создаются в RFC 1630 с процентным кодированием как методом, позволяющим отображать символы "небезопасных". Эта оригинальная версия на самом деле упоминала набор символов ISO Latin 1 как кодировку для символов, отличных от ASCII. RFC 1738 позже в этом году удалила эту ссылку на Latin-1 при определении URL-адресов.

Формат строки запроса - это фактически другая, но связанная с ней кодировка, application/x-www-form-urlencoded, определенная в RFC 1866 наряду с HTML 2.0. Он был основан на RFC 1738, но указал, что пробелы (не все пробелы, только символ с кодом ASCII 0x20) заменены на "+" и что разрывы строк должны быть закодированы как CRLF (т.е. %0D%0A). Первая из них, вероятно, связана с тем, что она сохраняет 2 байта для очень общего символа в представлениях форм за счет использования дополнительных 2 байтов для гораздо менее общего символа, а вторая заключается в том, чтобы избежать проблем при передаче между системами, использующими разные конечные результаты, линейных кодировок. Символы, отличные от ASCII, остались нерассмотренными.

Кодирование UTF-8 в URI появилось через десятилетие, в RFC 3986, хотя отдельные протоколы могли указать эту или другую кодировку не- -ASCII ранее. Чтобы поддерживать обратную совместимость, все октеты UTF-8 должны быть закодированы в процентах. Сопутствующий RFC 3987 определяет "Инициаторы интернационализированных ресурсов" (IRI), которые в основном "URI с большинством кодовых точек 160 и выше разрешены, чтобы отображаться незакодированными", но многие протоколы по-прежнему требуют URI. Обратите внимание, что приведенное выше утверждение неверно, поскольку RL U не может содержать unencoded ü или любой другой символ, отличный от ASCII.

application/x-www-form-urlencoded интернационализирован по-другому. спецификация HTML5 для приложения /x -www-form-urlencoded явно позволяет использовать любой набор символов, совместимый с ASCII, для символов в строке запроса, и на самом деле разные поля могут использовать разные наборы символов, но все не-ASCII-октеты все равно должны быть закодированы в процентах. При использовании в части запроса IRI возможно, что эти символы могут быть представлены незакодированными, если правильно-нормализованный UTF-8 используется в качестве набора символов, поскольку преобразование обратно в URI приведет к правильному приложению /x -www -форма-urlencoded данные.

Ответ 2

Они не обязательно должны отличаться, a + является допустимым символом пути, а ü является допустимым символом поиска (на RFC 3987). Вероятно, вы видите браузеры или какую-либо другую предвзятую схему кодирования, делающую предположения, которые либо устарели, либо чрезмерно осторожны.

Ответ 3

Нет разницы между + и %20, когда дело доходит до строковых параметров Query:

SPACE кодируется как "+" или "%20"

Цитировать ссылка