В URL-адресе следует кодировать пробелы с помощью %20 или +? Например, в следующем примере, какой из них правильный?
www.mydomain.com?type=xbox%20360
www.mydomain.com?type=xbox+360
Наша компания склоняется к первому, но использует метод Java URLEncoder.encode(String, String) с "xbox 360" (и "UTF-8") возвращает последний.
Итак, какая разница?
Данные формы (для GET или POST) обычно кодируются как application/x-www-form-urlencoded: это указывает + для пробелов.
URL-адреса закодированы как RFC 1738, который указывает %20.
В теории я думаю, что перед ? и + после:
example.com/foo%20bar?foo+bar
В соответствии с W3C (и они являются официальным источником этих данных), символ пробела в строке запроса (и в запросе строка) может быть закодирована как "%20" или "+". Из раздела "Строки запроса" в разделе "Рекомендации":
В строке запроса знак плюса зарезервирован как сокращенное обозначение пробела. Следовательно, символы реального плюса должны быть закодированы. Этот метод использовался для упрощения передачи URI запросов в системах, которые не допускали пробелов.
В соответствии с разделом 3.4 RFC2396, который является официальной спецификацией URI в целом, компонент "запроса" зависит от URL:
3.4. Компонент запроса Компонент запроса представляет собой строку информации, которая должна интерпретироваться ресурс.
query = *uricВ компоненте запроса символы ";", "/", "?", ":", "@", "&", "=", "+", "," и "$" зарезервированы.
Поэтому это ошибка в другом программном обеспечении, если он не принимает URL-адреса с пробелами в строке запроса, закодированной как символы "+".
Что касается третьей части вашего вопроса, один способ (хотя и немного уродливый) исправить выход из URLEncoder.encode() заключается в том, чтобы затем call replaceAll("\\+","%20") по возвращаемому значению.
Эта путаница в том, что 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 перед ? и + после
Это не должно иметь значения, если вы закодировали букву А как% 41.
Однако, если вы имеете дело с системой, которая не распознает одну форму, кажется, что вам просто нужно дать ей то, что она ожидает, независимо от того, что говорит "spec".
Вы можете использовать либо - это означает, что большинство людей выбирает "+", поскольку оно более читаемо для человека.
При кодировании значений запроса допустимы либо форма, плюс, либо процент-20; однако, поскольку пропускная способность интернета не бесконечна, вы должны использовать плюс, так как это два байта.