Когда в URL кодируется пробел +
и когда он кодируется %20
?
Когда в URL кодируется пробел +
и когда он кодируется %20
?
Ответы:
Из Википедии (выделение и ссылка добавлены):
Когда данные, введенные в формы 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
.
http://www.bing.com/search?q=hello+world
это ресурс с пробелом в имениhttp://camera.phor.net/cameralife/folders/2012/2012-06%20Pool%20party/
mailto:support@example.org?subject=I%20need%20help
. Если вы пробовали это с +, электронное письмо будет открываться с + es вместо пробелов.
Эта путаница объясняется тем, что 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: bobby@www.lunatech.com: 8080 / file; p = 1? q = 2 # третий »
мы можем извлечь следующую информацию:
+-------------------+---------------------+
| 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:bobby@www.lunatech.com:8080/file;p=1?q=2#third
\___/ \_/ \___/ \______________/ \__/\_______/ \_/ \___/
| | | | | | \_/ | |
Scheme User Password Host Port Path | | Fragment
\_____________________________/ | Query
| Path parameter
Authority
Зарезервированные символы различны для каждой части.
Для HTTP-URL пробел в части фрагмента пути должен быть закодирован как «% 20» (не совсем, не «+»), в то время как символ «+» в части фрагмента пути может быть оставлен незакодированным.
Теперь в части запроса пробелы могут быть закодированы либо в «+» (для обратной совместимости: не пытайтесь искать его в стандарте URI), либо в «% 20», пока символ «+» (из-за этой неоднозначности ) должен быть экранирован до "% 2B".
Это означает, что строка «синий + голубой» должна кодироваться по-разному в частях пути и запроса:
" http://example.com/blue+light%20blue?blue%2Blight+blue ".
Отсюда вы можете сделать вывод, что кодирование полностью сконструированного URL невозможно без синтаксической осведомленности о структуре URL.
Это сводится к:
Вы должны иметь %20
до ?
и +
после.
key1=value1&key1=value2
там, где ключи и значения кодируются с соблюдением любых правил, encodeURIComponent
но AFAIK содержание части запроса полностью на 100% до приложения. В остальном это касается только первой #
, официальной кодировки нет.
Я бы порекомендовал %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 также конвертирует его +
.
Пробел может быть закодирован только в «+» в части запроса «пары ключ-значение контента» типа 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, а затем закодируйте в процентах результат.