Иногда пробелы кодируются URL-адресом в знак +, а иногда - в %20. В чем разница и почему это должно произойти?
Когда закодировать пробел до плюс (+) или %20?
Ответ 1
+ означает пробел только в 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
Ответ 2
http://www.example.com/some/path/to/resource?param1=value1
Часть перед вопросительным знаком должна использовать% encoding (so %20 для пробела), после вопросительного знака вы можете использовать либо %20, либо + для пробела. Если вам нужен фактический + после использования вопросительного знака %2B.
Ответ 3
Итак, ответы здесь немного неполны. Использование "%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 определены как этот тип. Фактически нет никакого упоминания о кодировке строки запроса в чем-либо после спецификации HTML 2.0.
Что оставляет нас с вопросом - действительно ли это? Конечно, есть много устаревшего кода, который поддерживает "+" в строках запроса и много кода, который также генерирует его. Итак, шансы хорошие, вы не сломаетесь, если используете "+" . (И, фактически, я сделал все исследования по этому поводу недавно, потому что я обнаружил главный сайт, который не смог принять "%20" в запросе GET в качестве пробела. На самом деле они не смогли декодировать никоим образом закодированный символ. использование может также иметь значение.)
Но из чистого чтения спецификаций, без языка из спецификации HTML 2.0, перенесенного в более поздние версии, URL-адреса полностью покрываются RFC3986, что означает, что пробелы должны быть преобразованы в "%20". И определенно это должно быть так, если вы запрашиваете что-либо, кроме HTML-документа.
Ответ 4
Лучше всегда кодировать пробелы как %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. Но так как трудно определить контекст, лучше никогда не кодировать пробелы как "+" .
Я бы рекомендовал процент-кодировать весь символ, кроме "unreserved", определенный в RFC-3986, стр .2.3
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Ответ 5
Какая разница: см. другие ответы.
При использовании + вместо %20? Используйте +, если по какой-то причине вы хотите сделать строку запроса URL (?.....) или хеш-фрагмент (#....) более читаемой. Пример: вы действительно можете прочитать это:
https://www.google.se/#q=google+doesn%27t+encode+:+and+uses+%2B+instead+of+spaces
(%2B= +)
Но гораздо труднее прочитать: (по крайней мере для меня)
Я бы подумал, что + вряд ли что-то сломает, поскольку Google использует + (см. первую ссылку выше), и они, вероятно, подумали об этом. Я собираюсь использовать + сам, потому что читаемый + Google думает, что все в порядке.