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

Question

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

Answer 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 Specification application/x-www-form-urlencoded

Answer 2

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

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

Answer 3

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

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

Answer 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. Но так как трудно определить контекст, лучше никогда не кодировать пробелы как «+».

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

unreserved = ALPHA/DIGIT/"-"/"."/"_"/"~" 

Answer 5

Итак, ответы здесь все немного неполные. Использование «% 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-документа.