Разрешено ли URL-адресу содержать пробел?
Мне очень нравится делать это с Object.assign, а не с помощниками неизменяемости.
handleCommentEdit: function(id, text) {
this.setState({
data: this.state.data.map(el => (el.id === id ? Object.assign({}, el, { text }) : el))
});
}
Я просто считаю, что это намного более сжато, чем сращивание, и не требует знания индекса или явной обработки не найден случай.
9 ответов
Согласно [1 115] RFC 1738 :
Небезопасный:
Символы могут быть небезопасными по ряду причин. пробел небезопасен, потому что значительные пробелы могут исчезнуть, и незначительные пробелы могут быть представлены, когда URL записываются или набираются или подвергаются обработке программ обработки текстов. символы
"<"и">"небезопасны, потому что они используются в качестве разделителей вокруг URL в произвольном тексте; метка кавычки (""") используется для разграничивания URL в некоторых системах. Символ"#"небезопасен и должен всегда кодироваться, потому что он используется во Всемирной паутине и в других системах для разграничивания URL от идентификатора фрагмента/привязки, который мог бы следовать за ним. Символ"%"небезопасен, потому что он используется для кодировки других символов. Другие символы небезопасны, потому что шлюзы и другие транспортные агенты, как известно, иногда изменяют такие символы. Эти символы"{","}","|","\","^","~","[","]", и"`".Все небезопасные символы должны всегда кодироваться в URL. Например, символ
"#"должен быть закодирован в URL даже в системах, которые обычно не имеют дело с фрагментом или идентификаторами привязки, так, чтобы, если URL копируется в другую систему, которая использует их, не было необходимо изменить кодирование URL.
Почему это должно быть закодировано? Запрос похож на это:
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
Более короткий ответ: нет, необходимо закодировать пространство; это корректно для кодирования пространства +, но только в строке запроса; в пути необходимо использовать %20.
URL определяются в RFC 3986 , хотя другие RFCs релевантны также, но RFC 1738 является устаревшим.
у Них не может быть пробелов в них, наряду со многими другими символами. Так как те запрещенные символы часто должны быть представлены так или иначе, существует схема кодирования их в URL путем перевода их в их ASCII шестнадцатеричный эквивалент с префиксом "%".
Большинство языков/платформ программирования обеспечивает функции для кодирования и декодирования URL, хотя они не могут правильно придерживаться стандартов RFC. Например, я знаю, что PHP не делает.
Да, пространство обычно кодируется к "%20" все же. Любые параметры, которые передают URL, должны быть закодированы, просто из соображений безопасности.
Отвечать на Ваш вопрос. Я сказал бы, что приложениям довольно свойственно заменить пробелы в значениях, которые будут использоваться в URL. Причина этого состоит в том, чтобы обычно избегать более трудного для чтения процента (URI), кодирующий, который происходит.
Выезд эта статья Википедии приблизительно кодирование Процента .
URL должны не , имеют пробелы в них. Если необходимо обратиться к тому, который делает, использует его закодированное значение %20
кто-то может указать на RFC, указывающий, что URL с пространством должен быть закодирован?
URIs и таким образом URL, определяются в RFC 3986.
при рассмотрении грамматики, определенной там, Вы в конечном счете отметите, что пробел никогда не может быть частью синтаксически легального URL, таким образом термин "URL с пространством" является противоречием сам по себе.
Firefox 3 отобразится %20 с в URL как пробелы в строке поиска.