Когда закодировать пробел до плюс (+) или% 20?

Иногда пробелы получают URL-адрес в +знак, а иногда и другие %20. В чем разница и почему это должно произойти?

urlencode,

381

Ответов: 5


383 принят

+означает пробел только в application/x-www-form-urlencodedсодержимом, таком как часть запроса URL-адреса:

http://www.example.com/path/foo+bar/path?query+name=query+value

В этом URL-адресе имя параметра имеет query nameпробел, а значение имеет query valueпробел, но имя папки в пути буквально foo+bar, а не foo bar .

%20является допустимым способом кодирования пространства в любом из этих контекстов. Поэтому, если вам нужно URL-кодировать строку для включения в часть URL-адреса, всегда безопасно заменять пробелы %20и плюсы %2B. Это то, что напр. encodeURIComponent()в JavaScript. К сожалению, это не то, что urlencode делает на PHP ( rawurlencode безопаснее).

См. Также Приложение спецификации HTML 4.01 / x-www-form-urlencoded


41

http://www.example.com/some/path/to/resource?param1=value1

Часть перед вопросительным знаком должна использовать% encoding (поэтому %20для пробела), после вопросительного знака вы можете использовать либо %20или +для пробела. Если вам нужна фактическая информация +после использования вопросительного знака %2B.


13

Итак, ответы здесь немного неполны. Использование «unreserved = ALPHA / DIGIT /» - «/». " / "_" / "~" 'для кодирования пробела в URL-адресах явно определено в RFC3986 , которое определяет, как создается URI. В этой спецификации не упоминается использование «+» для пространств кодирования - если вы идете исключительно по этой спецификации, пространство должно быть закодировано как «% 20».

Упоминание об использовании «% 20» для пространств кодирования исходит из различных воплощений спецификации HTML - особенно в разделе, описывающем тип контента «application / x-www-form-urlencoded». Это используется для отправки данных формы.

Теперь спецификация HTML 2.0 (RFC1866) явно указала в разделе 8.2.2, что часть запроса строки URL-адреса запроса GET должна быть закодирована как «application / x-www-form-urlencoded». Это, теоретически, предполагает, что в строке запроса (после «?») Допустимо использовать «+» в URL-адресе.

Но ... это правда? Помните, что HTML сам по себе является спецификацией содержимого, а URL-адреса с строками запросов могут использоваться с контентом, отличным от HTML. Кроме того, в то время как более поздние версии спецификации HTML продолжают определять «? .....» как законные в содержании «application / x-www-form-urlencoded», они полностью опускают часть, заявляющую, что строки запроса запроса GET определены как этот тип. На самом деле нет никакого упоминания о кодировке строки запроса в чем-либо после спецификации HTML 2.0.

Что оставляет нас с вопросом - действительно ли это? Конечно, есть много устаревшего кода, который поддерживает «# ....» в строках запроса и много кода, который также генерирует его. Итак, шансы хорошие, вы не сломаетесь, если используете «+». (И, фактически, я сделал все исследования по этому поводу недавно, потому что я обнаружил главный сайт, который не смог принять «% 20» в запросе GET в качестве пробела. На самом деле они не смогли декодировать никоим образом закодированный символ. использование может также иметь значение.)

Но из чистого чтения спецификаций, без языка из спецификации HTML 2.0, перенесенного в более поздние версии, URL-адреса полностью покрываются RFC3986, что означает, что пробелы должны быть преобразованы в «% 20». И определенно это должно быть так, если вы запрашиваете что-либо, кроме HTML-документа.


Лучше всегда кодировать пробелы как% 20, а не как «+».

Это RFC-1866 (спецификация HTML 2.0), в которой указано, что символы пробела должны быть закодированы как «+» в парах ключ-значение типа «application / x-www-form-urlencoded». (см. пункт 8.2.1, подпункт 1). Этот способ кодирования данных формы также приведен в более поздних спецификациях HTML, ищите соответствующие абзацы о приложении / x-www-form-urlencoded.

Ниже приведен пример такой строки в URL-адресе, где RFC-1866 позволяет использовать пробелы в виде плюсов: «http://example.com/over/there?name=foo+bar». Итак, только после «?», Пробелы могут быть заменены плюсами, согласно RFC-1866. В других случаях пробелы должны быть закодированы до% 20. Но так как трудно определить контекст, лучше никогда не кодировать пробелы как «+».

Я бы порекомендовал процент-кодировать весь символ, кроме «безоговорочного», определенного в RFC-3986, стр.2.3

%2B

2

В чем разница: см. Другие ответы.

При использовании +вместо %20? Используйте, +если по какой-то причине вы хотите сделать строку запроса URL ( +) или хеш-фрагмент ( +) более читаемой. Пример: вы действительно можете прочитать это:

https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces ( %2B= +)

Но гораздо труднее прочитать: (по крайней мере, для меня)

https://www.google.se/#q=google%20doesn%27t%20oops%20:%20%20this%20text%20%2B%20is%20different%20spaces

Я думаю +, вряд ли что-нибудь сломает, так как Google использует +(см. 1-ую ссылку выше), и они, вероятно, подумали об этом. Я собираюсь использовать +себя только потому, что читаемый + Google считает, что все в порядке.

UrlEncode,