Почему я должен использовать urlencode?

Question

Я пишу веб-приложение и изучаю, как urlencode html-ссылки ...

Все вопросы urlencode здесь (см. Тег ниже): «Как ...?»вопросы.

Мой вопрос не "Как?"но "Почему?".

Даже статья в Википедии посвящена только механике этого:
http://en.wikipedia.org/wiki/Urlencode, но не , почему Я должен использовать urlencode в моем приложении вообще.

Каковы последствия безопасности использования (или, скорее, не использования) urlencode?

Каким образом невозможность использования urlencode эксплуатируется ?

Какие ошибок или сбои могут возникать при использовании некодированных URL-адресов?

Я спрашиваю, потому что даже без urlencodeСсылка на мой веб-сайт разработчика приложений, как показано ниже, работает, как и ожидалось: http://myapp/my%20test/ée/ràé

Почему мне следует использовать urlencode?

Или другим способомчтобы поставить это:

Когда я должен использовать urlencode?В каких ситуациях?

Answer 1

Обновление: Ниже приведено еще лучшее объяснение (imo):

URI представляется в виде последовательности символов, а не последовательности октетов.Это связано с тем, что URI может быть «передан» средствами, которые не передаются через компьютерную сеть, например напечатаны на бумаге, считаны по радио и т. Д.

и

Однако для оригинальных последовательностей символов, которые не являются символами ASCII, ситуация более сложная.Ожидается, что интернет-протоколы, которые передают последовательности октетов, предназначенные для представления последовательностей символов, обеспечат некоторый способ идентификации используемой кодировки, если их может быть несколько [RFC2277].Однако в настоящее время в универсальном синтаксисе URI отсутствует условие для выполнения этой идентификации.Для отдельной схемы URI может потребоваться один набор символов, определить набор символов по умолчанию или предоставить способ указать используемый набор символов.

---

Поскольку это указано в RFC :

2.4.Escape-последовательности

Данные должны быть экранированы, если они не имеют представления, использующего незарезервированный символ;это включает в себя данные, которые не соответствуют печатному символу набора кодированных символов US-ASCII или соответствуют любому символу US-ASCII, который не разрешен, как описано ниже.

и

2.4.2.Когда выходить и Unescape

URI всегда находится в «экранированной» форме, поскольку экранирование или удаление завершенного URI может изменить его семантику.Обычно единственное безопасное кодирование времени может быть безопасно выполнено, когда URI создается из его составных частей;каждый компонент может иметь свой собственный набор символов, которые зарезервированы, поэтому только механизм, ответственный за генерацию или интерпретацию этого компонента, может определить, изменится ли экранирование символа в его семантике.Аналогично, URI должен быть разделен на его компоненты, прежде чем экранированные символы в этих компонентах могут быть безопасно декодированы.

В некоторых случаях данные, которые могут быть представлены незарезервированным символом, могут казаться экранированными;например, некоторые из незарезервированных символов «метки» автоматически экранируются некоторыми системами.Если данная схема URI определяет алгоритм канонизации, то незарезервированные символы могут быть экранированы в соответствии с этим алгоритмом.Например, «% 7e» иногда используется вместо «~» в пути URL-адреса http, но эти два значения эквивалентны URL-адресу http.

Поскольку символ процента «%» всегда имеет зарезервированное назначение:Будучи индикатором escape, он должен быть экранирован как "% 25", чтобы использоваться в качестве данных в URI.Разработчики должны быть осторожны, чтобы не экранировать или не экранировать одну и ту же строку более одного раза, поскольку удаление из экранирования уже неэкранированной строки может привести к неверной интерпретации символа данных процента как другого экранированного символа или наоборот в случае экранирования уже экранированной строки.*

Answer 2

Основная причина в том, что по существу экранирует символов для включения в URL-адрес вашей веб-страницы.

Предположим, пользователь вводит поле формы пользователя как "& joe", и мы хотели быперенаправить на страницу, которая содержит это имя как часть URL, используя URL-кодировку, тогда это будет, например:

localhost/index.php?name=%26joe //note how the ampersand is escaped

Если вы не использовали urlencoding, вы получите:

localhost/index.php?name=&joe

и этот амперсанд вызовет всевозможные непредсказуемости

Answer 3

Две причины, о которых я мог подумать:

• Это действительно зависит от того, как вы анализируете свою сторону сервера запросов.Например, передача параметров с использованием HTTP-запроса GET будет иметь проблемы, если в каком-либо параметре есть такие символы, как &.
• Он позволяет вам обрабатывать неанси-символы так, как вы хотели бы (вы диктуете кодировку),В противном случае браузер может передать их в некоторой произвольной кодировке (не думайте, что она действительно определена в каком-либо стандарте; исправьте меня, если я ошибаюсь).

Answer 4

Существуют RFC (http://www.faqs.org/rfcs/rfc1738.html и т. П.), Которые определяют формат для URL-адресов, и разработчики браузеров / веб-серверов используют этот стандарт в качестве стандарта для интерпретации данных. Если вы не согласны, результаты могут быть непредсказуемыми.

HTTP URL имеет свою спецификацию и утверждает, что практически все нелатинские символы должны быть закодированы.

Answer 5

Как вы будете различать, если ваши два пути похожи на это

http://myapp/my%20test/

и

http://myapp/my test/

Пробел &% 20 является частью URL.