Можно ли в URL-адресе содержать пробел?

132

Разрешено ли URI (в частности, URL-адрес HTTP) содержать один или несколько пробелов? Если URL-адрес должен быть закодирован, это +просто общепринятое соглашение или законная альтернатива?

В частности, может ли кто-нибудь указать на RFC, в котором указано, что URL-адрес с пробелом должен быть закодирован?

Мотивация для вопроса: во время бета-тестирования веб-сайта я заметил, что некоторые URL-адреса были созданы с пробелами. Казалось, что Firefox поступил правильно, что меня удивило! Но я хотел указать разработчикам на RFC, чтобы они почувствовали необходимость исправить эти URL-адреса.

Джо Касадонте
источник
расширенный набор,
появившийся

Ответы:

101

Согласно RFC 1738 :

Опасное:

Персонажи могут быть небезопасными по ряду причин. Пробел небезопасен, потому что значимые пробелы могут исчезнуть, а незначащие пробелы могут появиться, когда URL-адреса транскрибируются, набираются или обрабатываются программами обработки текста. Символы "<"и ">"небезопасны, потому что они используются в качестве разделителей URL-адресов в произвольном тексте; кавычка ( """) используется для разграничения URL-адресов в некоторых системах. Этот символ "#"небезопасен и всегда должен кодироваться, поскольку он используется во всемирной паутине и в других системах для отделения URL-адреса от идентификатора фрагмента / привязки, который может следовать за ним. Персонаж"%"небезопасно, так как используется для кодирования других символов. Другие символы небезопасны, поскольку известно, что шлюзы и другие транспортные агенты иногда изменяют такие символы. Эти символы "{", "}", "|", "\", "^", "~", "[", "]", и "`".

Все небезопасные символы всегда должны кодироваться в URL . Например, символ "#"должен быть закодирован в URL-адресах даже в системах, которые обычно не имеют дело с идентификаторами фрагментов или привязок, так что если URL-адрес копируется в другую систему, которая их использует, не нужно будет изменять кодировку URL-адреса.

Марк Новаковский
источник
2
1738 заменен на 2396. ietf.org/rfc/rfc2396.txt Это текущая спецификация Uri. Но в данном случае это не имеет значения.
Стив Северанс,
40
А 2396 был заменен 3986. Многие люди ошибаются, поскольку RFC неизменяемы, и поэтому не сообщают читателю, что они устарели. Подсказка: используйте tools.ietf.org/html/rfcnnnn , например tools.ietf.org/html/rfc2396, вместо этого он отображает недостающие метаданные сверху.
Джулиан Решке,
43

Зачем это нужно кодировать? Запрос выглядит так:

GET /url HTTP/1.1
(Ignoring headers)

Есть 3 поля, разделенных пробелом. Если вы поместите пробел в свой URL:

GET /url end_url HTTP/1.1

Вы знаете, что у вас есть 4 поля, HTTP-сервер сообщит вам, что это недействительный запрос.

GET /url%20end_url HTTP/1.1

3 поля => действительно

Примечание: в строке запроса (после?) Пробел обычно кодируется как +

GET /url?var=foo+bar HTTP/1.1 

скорее, чем

GET /url?var=foo%20bar HTTP/1.1 
Julien
источник
Что, если var действительно будет "foo + bar", а не "foo bar"?
Ivo3185
2
Я бы сказал, что это требование транспортного уровня, а не самой спецификации URI. GET явно является свойством спецификации http:, а не спецификации URL. Точно так же вы можете утверждать, что кавычки в URL-адресах «должны» быть закодированы, иначе веб-страницы могут сломаться. Но это свойство ограничений форматирования HTML (против которых существуют другие стратегии), а не свойство спецификации URL.
Кент Фредрик,
ietf.org/rfc/rfc1738.txt - Небезопасные символы, включая пробелы) должны быть закодированы
Жюльен
@KentFredric Это, скорее, уровень представления , а не транспортный уровень. Как пишет Жюльен (почти), исходная спецификация URI ( RFC 1630 ) содержит это ограничение, поэтому оно является частью самой спецификации URI, независимо от ваших личных ощущений. Поскольку спецификация URI была написана после черновиков HTTP, вполне возможно, что URI были разработаны с учетом HTTP, включая запрет на использование пробелов, но на самом деле это не имеет значения, не так ли? Правда в том, что спецификация - это то, что есть спецификация.
Кристофер Шульц
38

Короче ответ: нет, вы должны кодировать пробел; это является правильным для кодирования пространства как +, но только в строке запроса; в пути, который вы должны использовать %20.

Питер Хилтон
источник
1
Привет, я тоже запутался, когда-то я видел, что в книге используется "+", но иногда "% 20", вы можете показать какой-нибудь пример для этого? Когда пользователь отправляет форму, как форма кодирует пространство? с каким персонажем?
GMsoF
1
См. Этот ответ для получения дополнительных сведений.
DavidRR
а как насчет фрагмента / хеш-части? Как там нужно кодировать пробелы?
gumkins
@gumkins: фрагмент (# и после) не отправляется на сервер. На практике вы можете использовать% 20 ​​или + где угодно для кодирования пробела.
Жюльен
9

URL-адреса определены в RFC 3986 , хотя другие RFC также актуальны, но RFC 1738 устарел.

В них может не быть пробелов, как и многих других символов. Поскольку эти запрещенные символы часто необходимо каким-то образом представлять, существует схема их кодирования в URL-адрес путем перевода их в их шестнадцатеричный эквивалент ASCII с префиксом «%».

Большинство языков / платформ программирования предоставляют функции для кодирования и декодирования URL-адресов, хотя они могут не соответствовать стандартам RFC. Например, я знаю, что PHP этого не делает.

Роб Уильямс
источник
7

Да, пробел обычно кодируется как "% 20". Любые параметры, которые передаются в URL, должны быть закодированы просто из соображений безопасности.

user54650
источник
6

URL-адрес может содержать пробел, и в большинстве браузеров они будут отображаться как% 20, но правила кодирования браузера меняются довольно часто, и мы не можем зависеть от того, как браузер будет отображать URL-адрес.

Поэтому вместо этого вы можете заменить пробел в URL-адресе любым символом, который, по вашему мнению, сделает URL-адрес более читабельным и «красивым»;) ..... О, поэтому предпочтительными общими символами являются «-», «_», "+" .... но это не принуждение, поэтому вы можете использовать любой символ, который не должен быть в URL-адресе.

Избегайте использования%, &,}, {,], [, /,>, <в качестве замены символа пробела URL-адреса, так как они могут вызывать ошибку в некоторых браузерах и платформах.

Как видите, переполнение Stak использует символ «-» в качестве замены пробела (% 20).

Удачных вопросов.

AM Web Surfer
источник
5

В URL не должно быть пробелов. Если вам нужно обратиться к одному из них, используйте его закодированное значение%20

Крис Балланс
источник
5

Может ли кто-нибудь указать на RFC, указывающий, что URL-адрес с пробелом должен быть закодирован?

URI и, следовательно, URL-адреса определены в RFC 3986.

Если вы посмотрите на определенную там грамматику, вы в конечном итоге заметите, что пробел никогда не может быть частью синтаксически допустимого URL-адреса, поэтому термин «URL-адрес с пробелом» сам по себе противоречит.

Джулиан Решке
источник
3

Ответить на ваш вопрос. Я бы сказал, что приложения довольно часто заменяют пробелы в значениях, которые будут использоваться в URL-адресах. Причина этого обычно заключается в том, чтобы избежать сложного для чтения процентного кодирования (URI).

Посмотрите эту статью в Википедии о процентном кодировании .

Эрик Шуновер
источник
2

Firefox 3 будет отображать %20s в URL-адресах как пробелы в адресной строке.

Софи Альперт
источник
Это не правильный ответ на довольно простой вопрос: "Is a URL allowed to contain a space?". Скорее комментарий.
Roko C. Buljan