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

Ответ 1

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

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

и

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

Потому что это указано в RFC:

2,4. Последовательности выхода

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

и

2.4.2. Когда побегать и освобождать

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

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

Потому что у процента "%" всегда есть зарезервированная цель    являясь индикатором выхода, он должен быть экранирован как "% 25", чтобы    использоваться как данные в URI. Исполнители должны быть осторожны, чтобы не    escape или unescape одной и той же строки более одного раза, поскольку unescaping    уже несвязанная строка может привести к неверному истолкованию процента    данных в качестве другого экранированного символа, или наоборот в    случай экранирования уже экранированной строки.

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

http://myapp/my%20test/

и

http://myapp/my test/

Записное пространство и %20 являются частью URL.

Ответ 5

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

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

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

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

localhost/index.php?name=&joe

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