URL-адрес, кодирующий пробел: + или% 20?

Когда пробел в URL-адресе кодируется как +, а когда он кодируется как %20?


person BC.    schedule 27.10.2009    source источник
comment
Этот вопрос был бы более полезным, чем несколько вопросов, относящихся к конкретному языку, не так ли?   -  person squarecandy    schedule 11.01.2015
comment
Возможный дубликат Когда кодировать пробел на плюс (+) или% 20?   -  person user    schedule 16.04.2017
comment
@user вопрос, на который вы ссылаетесь, был задан позже, что сделало его обманщиком, а не этим.   -  person Warlike Chimpanzee    schedule 01.09.2017


Ответы (4)


Из Wikipedia (выделено и добавлена ​​ссылка):

При отправке данных, которые были введены в формы HTML, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST, или, как правило, по электронной почте. Кодировка, используемая по умолчанию, основана на очень ранней версии общих правил процентного кодирования URI с количество модификаций, таких как нормализация новой строки и замена пробелов на" + "вместо"% 20 ". Тип данных MIME, закодированных таким образом является application / x-www-form-urlencoded, и в настоящее время он определен (все еще очень устаревшим) в спецификациях HTML и XForms.

Таким образом, реальное процентное кодирование использует %20, в то время как данные формы в URL-адресах находятся в измененной форме, которая использует +. Таким образом, вы, скорее всего, увидите только + в URL-адресах в строке запроса после ?.

person Joey    schedule 27.10.2009
comment
Итак, + кодирование технически будет кодированием multipart / form-data, а процентное кодирование - application / x-www-form-urlencoded? - person BC.; 28.10.2009
comment
@BC: no - multipart/form-data использует кодировку MIME; application/x-www-form-urlencoded использует +, а правильно закодированные URI используют %20. - person McDowell; 28.10.2009
comment
Таким образом, вы, скорее всего, увидите только + в URL-адресах в строке запроса после? Это преуменьшение. Вы никогда не должны видеть + в части пути URL-адреса, потому что он не будет делать то, что вы ожидаете (пробел). - person Adam Gent; 22.07.2011
comment
@McDowell, ваш ответ, комментарий от BC был мне очень полезен, вместе с вводом от Адама Гента - person Chris Marisic; 09.07.2012
comment
Привет, я тоже запутался, когда-то я видел, что книга использует +, но когда-то% 20, Когда пользователь отправляет форму, как форма кодирует пространство? с каким персонажем? Зависит ли результат от браузера? - person Sam YC; 07.11.2012
comment
Итак, в основном: целью отправки GET является 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
comment
Данные uris используют ту же кодировку, что и uris. После прочтения этого RFC я могу с уверенностью сказать, что я недостаточно умен, чтобы понять, следует ли разрешать кодирование пробела как символ +. Однако я могу сказать, что если вы используете + вместо% 20, URI данных не будет работать в браузерах. - person Rob Murphy; 28.04.2014
comment
@Rob: Вероятно, это действительно запрещено в URI данных. Потому что, как указано, это только в той части запроса, где используется +. - person Joey; 28.04.2014
comment
Обратите внимание, что для ссылок на электронную почту вам нужен% 20, а не + после?. Например, mailto:[email protected]?subject=I%20need%20help. Если вы попробовали это с +, письмо откроется с + es вместо пробелов. - person Sygmoral; 19.02.2015
comment
Это помогло мне, stackoverflow.com / questions / 5572718 / - person zeros-and-ones; 19.12.2017
comment
Проблема с использованием плюса заключается в том, что если вы хотите принимать знаки плюса отдельно от таких пробелов, как? Search = The A + School - person Curtis; 01.08.2019

Эта путаница возникает из-за того, что 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 перед ? и + после.

Источник

person Matas Vaitkevicius    schedule 29.04.2015
comment
›› у вас должно быть% 20 ​​перед знаком? и + после Простите за глупый вопрос. Я немного знаю, что параметр хэштега используется после? параметр вопросительного знака. Хотя как-то иначе, потому что использование # не перезагружает страницу. Но я пытался использовать знак% 20 и + после хэштега #, и, похоже, это не работает. Какой из них нужно использовать после #? - person Philcyb; 22.12.2015
comment
@Philcyb Возможно, вы захотите прочитать это en.wikipedia.org/wiki/Percent-encoding - person Matas Vaitkevicius; 23.12.2015
comment
Действительно ли у части запроса есть официальный стандарт? Я думал, что эта часть зависит от приложения. 99,99% приложений используют key1=value1&key1=value2, где ключи и значения кодируются по любым правилам, которым encodeURIComponent следуют, но AFAIK содержимое части запроса полностью зависит от приложения. Остальное идет только к первому #, официальной кодировки нет. - person gman; 26.07.2018
comment
Спасибо, что указали на то, что сбивающая с толку несогласованность связана с устаревшим сломанным дизайном. - person wlnirvana; 09.04.2020
comment
На самом деле, я только что взглянул на статью в блоге LunaTech, на которую вы любезно сослались, и сообщение, которое можно взять домой, похоже, больше похоже на: Вы должны использовать% 20, а не + перед ?, но после ? это это просто дело вкуса. Ради любви к Богу, люди, просто всегда используйте кодирование, основанное на знаках процента, и освобождает место в мозгу для более важных вещей. - person nydame; 06.12.2020
comment
Вау, чувак. Я должен сказать, что график в ASCII выглядит круто. - person Miłosz Brzechczyn; 09.06.2021

Я бы порекомендовал %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+'
person Rui Vieira    schedule 27.10.2009
comment
Не жесткое кодирование. Пытаюсь определить с эстетической точки зрения, как будут выглядеть мои URL-адреса, содержащие пробелы. - person BC.; 28.10.2009
comment
Привет, я тоже запутался. Когда пользователь отправляет html-форму, как форма кодирует пространство? с каким персонажем? Зависит ли результат от браузера? - person Sam YC; 07.11.2012
comment
И метод URLEncoder.encode() в Java также преобразует его в +. - person рüффп; 24.10.2014
comment
И тогда возникает вопрос, как обрабатывать кодировку в теле запроса POST: Content-Type: application / x-www-form-urlencoded, где параметры имеют форму a = b & c = d, но не в URL вообще, только в теле документа. Они устроили настоящий беспорядок в этом вопросе, и чертовски сложно найти окончательные ответы. - person fyngyrz; 05.12.2014
comment
Perls uri_escape () рассматривает их как% 20 - person someuser; 08.02.2015
comment
Проблема с% 20 заключается в том, что если вы добавляете его к URL-адресу, ваш сервер перенаправляет его на новый URL-адрес с тем же запросом, он может кодировать процент, и вы получите% 2520 вместо% 20 - person Curtis; 01.08.2019

Пробел может быть закодирован только как "+" в части запроса пар ключ-значение типа содержимого "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, а затем закодируйте результат в процентах.

person Maxim Masiutin    schedule 27.10.2016
comment
Зачем кому-то нужна спецификация HTML, если запрошенный ресурс не является HTML? Я видел + в некоторых веб-API, которые не отвечают с HTML, например. вы запрашиваете pdf. Я считаю неправильным, что они не используют% 20. - person The incredible Jan; 12.10.2017
comment
@TheincredibleJan, я согласен с вами. Вот о чем мой ответ. - person Maxim Masiutin; 02.04.2018
comment
@MaximMasiutin Когда в вашем ответе говорится, что это МОЖЕТ, а не ОБЯЗАТЕЛЬНО, на какую спецификацию вы имеете в виду? Я изо всех сил пытаюсь найти спецификацию, в которой это возможно. В w3.org/TR / 1999 / REC-html401-19991224 / interact / использование знака "+" (в разделе запроса) находится в обязательном разделе спецификации. - person JosephH; 07.05.2019
comment
@JosephH - спасибо за ваше сообщение. Это мое личное мнение о МАЕ. Я отредактировал сообщение. Я имел в виду, что указанная вами спецификация HTML определяет +, но в контексте URL-адреса применяются другие правила, которые также разрешают кодирование пробелов как% 20. - person Maxim Masiutin; 03.06.2019