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

Question

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

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

472 5

urlencode

5 ответов:

Comments

Ничего не найдено.

bobince · Accepted Answer · 2017-01-11 18:09:16

+ означает пробел только на 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-адрес, это всегда безопасный, чтобы заменить пробелы с %20 и плюсы с %2B. Это то, что например. encodeURIComponent() делает в JavaScript. К сожалению, это не то, что urlencode делает в PHP (rawurlencode безопаснее).

Смотрите Также HTML 4.01 спецификация application / x-www-form-urlencoded

cerberos · Accepted Answer · 2011-11-14 05:29:52

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

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

zgwortz · Accepted Answer · 2017-11-08 22:15:28

Итак, ответы здесь все немного неполным. Использование "%20 " для кодирования пространства в URL-адресах явно определено в RFC3986, который определяет, как строится URI. В этой спецификации нет упоминания об использовании ' + 'для кодирования пространств - если вы идете исключительно по этой спецификации, пространство должно быть закодировано как'%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 request определены как этот тип. На самом деле нет никакого упоминания о кодировке строки запроса в чем-либо после спецификации HTML 2.0.

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

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

Maxim Masiutin · Accepted Answer · 2016-10-28 10:59:25

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

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

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

Я бы порекомендовал процентов-кодирования всех символов, кроме "безоговорочной" определено в RFC 3986, стр. 2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

KajMagnus · Accepted Answer · 2016-10-14 00:04:05

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

при использовании + вместо %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 думает, что это нормально.