В URL-адресе должны быть закодированы пробелы с использованием %20 или +?

В URL-адресе следует кодировать пробелы с помощью %20 или +? Например, в следующем примере, какой из них правильный?

www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360

Наша компания склоняется к первому, но использует метод Java URLEncoder.encode(String, String) с "xbox 360" (и "UTF-8") возвращает последний.

Итак, какая разница?

Ответ 1

Данные формы (для GET или POST) обычно кодируются как application/x-www-form-urlencoded: это указывает + для пробелов.

URL-адреса закодированы как RFC 1738, который указывает %20.

В теории я думаю, что перед ? и + после:

у вас должно быть %20,

example.com/foo%20bar?foo+bar

Ответ 2

В соответствии с W3C (и они являются официальным источником этих данных), символ пробела в строке запроса (и в запросе строка) может быть закодирована как "%20" или "+". Из раздела "Строки запроса" в разделе "Рекомендации":

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

В соответствии с разделом 3.4 RFC2396, который является официальной спецификацией URI в целом, компонент "запроса" зависит от URL:

3.4. Компонент запроса Компонент запроса представляет собой строку информации, которая должна интерпретироваться ресурс.
   query         = *uric
В компоненте запроса символы ";", "/", "?", ":", "@", "&", "=", "+", "," и "$" зарезервированы.

Поэтому это ошибка в другом программном обеспечении, если он не принимает URL-адреса с пробелами в строке запроса, закодированной как символы "+".

Что касается третьей части вашего вопроса, один способ (хотя и немного уродливый) исправить выход из URLEncoder.encode() заключается в том, чтобы затем call replaceAll("\\+","%20") по возвращаемому значению.

Ответ 3

Эта путаница в том, что URL по-прежнему "сломан" по сей день

Возьмите http://www.google.com" например. Это URL. URL-адрес является унифицированным указателем ресурсов и на самом деле является указателем на веб-страницу (в большинстве случаев). На самом деле URL-адреса имеют очень четкую структуру начиная с первой спецификации в 1994 году.

Мы можем получить подробную информацию о http://www.google.com" URL:

+---------------+-------------------+   
|      Part     |      Data         |   
+---------------+-------------------+   
|  Scheme       | http              |   
|  Host address | www.google.com    |   
+---------------+-------------------+

Если мы посмотрим на более сложный URL-адрес, такой как " https://bob:[email protected]:8080/file;p=1?q=2#third" мы можем извлеките следующую информацию:

+-------------------+---------------------+
|        Part       |       Data          |
+-------------------+---------------------+
|  Scheme           | https               |
|  User             | bob                 |
|  Password         | bobby               |
|  Host address     | www.lunatech.com    |
|  Port             | 8080                |
|  Path             | /file               |
|  Path parameters  | p=1                 |
|  Query parameters | q=2                 |
|  Fragment         | third               |
+-------------------+---------------------+

Зарезервированные символы различаются для каждой части

Для URL-адресов HTTP пространство в фрагменте фрагмента пути должно быть закодировано до "%20" (не, абсолютно не "+" ), а символ "+" в пути фрагмент может быть оставлен незакодированным.

Теперь в части запроса пробелы могут быть закодированы либо "+" (для обратная совместимость: не пытайтесь искать его в URI стандарт) или "%20", в то время как символ "+" (в результате этого двусмысленность) должен быть экранирован до "%2B".

Это означает, что строка "синяя + светло-голубая" должна быть закодирована по-разному в частях пути и запроса: " http://example.com/blue+light%20blue?blue%2Blight+blue". Оттуда вы можете вывести, что кодирование полностью сконструированного URL-адреса невозможно без синтаксического понимания структуры URL.

Что это сводится к

вы должны иметь %20 перед ? и + после

Источник

Ответ 4

Это не должно иметь значения, если вы закодировали букву А как% 41.

Однако, если вы имеете дело с системой, которая не распознает одну форму, кажется, что вам просто нужно дать ей то, что она ожидает, независимо от того, что говорит "spec".

Ответ 5

Вы можете использовать либо - это означает, что большинство людей выбирает "+", поскольку оно более читаемо для человека.

Ответ 6

При кодировании значений запроса допустимы либо форма, плюс, либо процент-20; однако, поскольку пропускная способность интернета не бесконечна, вы должны использовать плюс, так как это два байта.