Когда пробел в URL-адресе кодируется как +
, а когда он кодируется как %20
?
URL-адрес, кодирующий пробел: + или% 20?
Ответы (4)
Из Wikipedia (выделено и добавлена ссылка):
При отправке данных, которые были введены в формы HTML, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST, или, как правило, по электронной почте. Кодировка, используемая по умолчанию, основана на очень ранней версии общих правил процентного кодирования URI с количество модификаций, таких как нормализация новой строки и замена пробелов на" + "вместо"% 20 ". Тип данных MIME, закодированных таким образом является application / x-www-form-urlencoded, и в настоящее время он определен (все еще очень устаревшим) в спецификациях HTML и XForms.
Таким образом, реальное процентное кодирование использует %20
, в то время как данные формы в URL-адресах находятся в измененной форме, которая использует +
. Таким образом, вы, скорее всего, увидите только +
в URL-адресах в строке запроса после ?
.
multipart/form-data
использует кодировку MIME; application/x-www-form-urlencoded
использует +
, а правильно закодированные URI используют %20
.
- person McDowell; 28.10.2009
http://www.bing.com/search?q=hello+world
и ресурс с пробелом в имени http://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
- person William Entriken; 14.04.2013
+
.
- person Joey; 28.04.2014
mailto:[email protected]?subject=I%20need%20help
. Если вы попробовали это с +, письмо откроется с + es вместо пробелов.
- person Sygmoral; 19.02.2015
Эта путаница возникает из-за того, что URL-адреса по сей день «не работают».
Возьмем, к примеру, "http://www.google.com". Это URL. URL-адрес - это унифицированный указатель ресурсов, который на самом деле является указателем на веб-страницу (в большинстве случаев). На самом деле URL-адреса имеют очень четко определенную структуру с момента первой спецификации в 1994 году.
Мы можем извлечь подробную информацию об URL "http://www.google.com":
+---------------+-------------------+
| Part | Data |
+---------------+-------------------+
| Scheme | http |
| Host | www.google.com |
+---------------+-------------------+
Если мы посмотрим на более сложный URL-адрес, например:
"https://bob:[email protected]:8080/file;p=1?q=2#third "
мы можем извлечь следующую информацию:
+-------------------+---------------------+
| Part | Data |
+-------------------+---------------------+
| Scheme | https |
| User | bob |
| Password | bobby |
| Host | www.lunatech.com |
| Port | 8080 |
| Path | /file;p=1 |
| Path parameter | p=1 |
| Query | q=2 |
| Fragment | third |
+-------------------+---------------------+
https://bob:[email protected]:8080/file;p=1?q=2#third
\___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/
| | | | | | \_/ | |
Scheme User Password Host Port Path | | Fragment
\_____________________________/ | Query
| Path parameter
Authority
Зарезервированные символы различны для каждой части.
Для URL-адресов HTTP пробел в части фрагмента пути должен быть закодирован как «% 20» (нет, абсолютно не «+»), в то время как символ «+» в части фрагмента пути можно оставить незакодированным.
Теперь в части запроса пробелы могут быть закодированы либо как «+» (для обратной совместимости: не пытайтесь искать его в стандарте URI), либо как «% 20», в то время как символ «+» (в результате этой неоднозначности ) необходимо преобразовать в "% 2B".
Это означает, что строка «синий + голубой» должна кодироваться по-разному в частях пути и запроса:
"http://example.com/blue+light%20blue?blue%2Blight+blue ".
Отсюда вы можете сделать вывод, что кодирование полностью сконструированного URL-адреса невозможно без синтаксической осведомленности о структуре URL-адреса.
Это сводится к следующему:
У вас должно быть %20
перед ?
и +
после.
key1=value1&key1=value2
, где ключи и значения кодируются по любым правилам, которым encodeURIComponent
следуют, но AFAIK содержимое части запроса полностью зависит от приложения. Остальное идет только к первому #
, официальной кодировки нет.
- person gman; 26.07.2018
?
, но после ?
это это просто дело вкуса. Ради любви к Богу, люди, просто всегда используйте кодирование, основанное на знаках процента, и освобождает место в мозгу для более важных вещей.
- person nydame; 06.12.2020
Я бы порекомендовал %20
.
Вы их жестко кодируете?
Однако это не очень единообразно для разных языков. Если я не ошибаюсь, в PHP urlencode()
пробелы рассматриваются как +
, а в Python urlencode()
они рассматриваются как %20
.
РЕДАКТИРОВАТЬ:
Кажется, я ошибаюсь. Python urlencode()
(по крайней мере, в 2.7.2) использует quote_plus()
вместо quote()
и, таким образом, кодирует пробелы как "+". Также кажется, что рекомендация W3C - это «+», как здесь: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
Фактически, вы можете следить за этой интересной дискуссией в собственном трекере проблем Python о том, что использовать для кодирования пробелов: http://bugs.python.org/issue13866.
РЕДАКТИРОВАТЬ № 2:
Я понимаю, что наиболее распространенный способ кодирования "" - это "+", но просто примечание, это может быть только я, но меня это немного сбивает с толку:
import urllib
print(urllib.urlencode({' ' : '+ '})
>>> '+=%2B+'
URLEncoder.encode()
в Java также преобразует его в +
.
- person рüффп; 24.10.2014
Пробел может быть закодирован только как "+" в части запроса пар ключ-значение типа содержимого "application / x-www-form-urlencoded" URL. На мой взгляд, это МОЖНО, а не ОБЯЗАТЕЛЬНО. В остальных URL-адресах он кодируется как% 20.
На мой взгляд, лучше всегда кодировать пробелы как% 20, а не как "+", даже в части запроса URL-адреса, потому что это спецификация HTML (RFC-1866) указывает, что символы пробелов должны быть закодированы как " + "in" application / x-www-form-urlencoded "пары ключ-значение типа содержимого (см. параграф 8.2.1. подпункт 1.)
Этот способ кодирования данных формы также указан в более поздних спецификациях HTML. Например, поищите соответствующие абзацы о application / x-www-form-urlencoded в спецификации HTML 4.01 и т. Д.
Вот пример строки в URL, где спецификация HTML допускает кодирование пробелов как плюсов: "http://example.com/over/there?name=foo+bar ". Итак, только после "?" Пробелы можно заменить на плюсы. В других случаях пробелы следует кодировать как% 20. Но поскольку правильно определить контекст сложно, лучше никогда не кодировать пробелы как «+».
Я бы рекомендовал кодировать в процентах все символы, кроме "незарезервированных", определенных в RFC-3986, п. 2.3.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Реализация зависит от выбранного вами языка программирования.
Если ваш URL-адрес содержит национальные символы, сначала закодируйте их в UTF-8, а затем закодируйте результат в процентах.