URL encoding, officially known as percent-encoding, is a method to encode arbitrary data in a uniform resource identifier (URI) using only the US-ASCII characters legal within a URI. Although it is known as URL encoding, it is also used more generally within the main Uniform Resource Identifier (URI) set, which includes both Uniform Resource Locator (URL) and Uniform Resource Name (URN). As such, it is also used in the preparation of data of the application/x-www-form-urlencoded media type, as is often used in the submission of HTML form data in HTTP requests.
The characters allowed in a URI are either reserved or unreserved (or a percent character as part of a percent-encoding). Reserved characters are those characters that sometimes have special meaning. For example, forward slash characters are used to separate different parts of a URL (or more generally, a URI). Unreserved characters have no such meanings. Using percent-encoding, reserved characters are represented using special character sequences. The sets of reserved and unreserved characters and the circumstances under which certain reserved characters have special meaning have changed slightly with each revision of specifications that govern URIs and URI schemes.
Other characters in a URI must be percent-encoded.
When a character from the reserved set (a "reserved character") has a special meaning (a "reserved purpose") in a certain context, and a URI scheme says that it is necessary to use that character for some other purpose, then the character must be percent-encoded. Percent-encoding a reserved character involves converting the character to its corresponding byte value in ASCII and then representing that value as a pair of hexadecimal digits (if there is a single hex digit, a leading zero is added). The digits, preceded by a percent sign (%) as an escape character, are then used in the URI in place of the reserved character.
(For a non-ASCII character, it is typically converted to its byte sequence in UTF-8, and then each byte value is represented as above.)
/Например, зарезервированный символ , если он используется в компоненте «путь» URI , имеет особое значение, поскольку является разделителем между сегментами пути. Если в соответствии с заданной схемой URI /он должен находиться в сегменте пути, то в сегменте необходимо использовать три символа %2Fили %2fвместо необработанного /.
Зарезервированные символы, которые не имеют зарезервированного назначения в определенном контексте, также могут быть закодированы в процентах, но семантически не отличаются от тех, которые этого не делают.
Например, в компоненте запроса URI (часть после символа ) все еще считается зарезервированным символом, но обычно он не имеет зарезервированного назначения, если только конкретная схема URI не говорит иное. Символ не обязательно должен быть закодирован в процентах, если у него нет зарезервированной цели.?/
URI, которые отличаются только тем, закодирован ли зарезервированный символ в процентах или отображается буквально, обычно считаются неэквивалентными (обозначающими один и тот же ресурс), если только не может быть определено, что рассматриваемые зарезервированные символы не имеют зарезервированного назначения. Это определение зависит от правил, установленных для зарезервированных символов отдельными схемами URI.
Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.
URI, которые отличаются только тем, закодирован ли незарезервированный символ в процентах или отображается буквально, эквивалентны по определению, но процессоры URI на практике не всегда могут распознать эту эквивалентность. Например, потребители URI не должны обращаться %41иначе с Aили %7Eиначе с ~, но некоторые так и делают. Для обеспечения максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.
Поскольку символ процента ( %) служит индикатором октетов, закодированных в процентах, он должен быть закодирован в процентах, %25чтобы этот октет можно было использовать в качестве данных в URI.
Большинство схем URI включают представление произвольных данных, таких как IP-адрес или путь к файловой системе , в качестве компонентов URI. Спецификации схемы URI должны (но часто этого не делают) обеспечивать явное сопоставление между символами URI и всеми возможными значениями данных, представленными этими символами.
С момента публикации RFC 1738 в 1994 году было указано, что схемы, обеспечивающие представление двоичных данных в URI, должны делить данные на 8-битные байты и процентно кодировать каждый байт таким же образом, как указано выше. [1] Значение байта 0x0F, например, должно быть представлено как %0F, а значение байта 0x41 может быть представлено как A, или %41. Обычно предпочтительнее использовать незакодированные символы для буквенно-цифровых и других незарезервированных символов, поскольку это приводит к сокращению URL-адресов.
Процедура процентного кодирования двоичных данных часто экстраполировалась, иногда ненадлежащим образом или не будучи полностью указанной, для применения к символьным данным. В годы становления Всемирной паутины при работе с символами данных в репертуаре ASCII и использовании соответствующих им байтов в ASCII в качестве основы для определения последовательностей с процентным кодированием эта практика была относительно безвредной; просто предполагалось, что символы и байты сопоставляются один к одному и взаимозаменяемы. Однако потребность в представлении символов за пределами диапазона ASCII быстро росла, и схемы и протоколы URI часто не обеспечивали стандартные правила подготовки символьных данных для включения в URI. В результате веб-приложения начали использовать различные многобайтовые кодировки, кодировки с отслеживанием состояния и другие несовместимые с ASCII кодировки в качестве основы для процентного кодирования, что привело к двусмысленности и трудностям с надежной интерпретацией URI.
Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторой неопределенной кодировкой символов , прежде чем они будут представлены в URI незарезервированными символами или байтами с процентным кодированием. Если схема не позволяет URI предоставлять подсказку о том, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI не может быть надежно интерпретирован. Некоторые схемы вообще не учитывают кодировку и вместо этого просто предполагают, что символы данных сопоставляются непосредственно с символами URI, что оставляет на усмотрение реализаций решать, следует ли кодировать процентное кодирование символов данных, которые не входят ни в зарезервированные, ни в незарезервированные наборы, и если да, то как.
Данные произвольных символов иногда кодируются в процентах и используются в ситуациях, не связанных с URI, например, для программ запутывания паролей или других протоколов трансляции, специфичных для системы.
Общий синтаксис URI рекомендует, чтобы новые схемы URI, обеспечивающие представление символьных данных в URI, фактически представляли символы из незарезервированного набора без перевода и преобразовывали все остальные символы в байты в соответствии с UTF-8 , а затем в проценты. -закодировать эти значения. Это предложение было введено в январе 2005 года с публикацией RFC 3986. Схемы URI, введенные до этой даты, не затрагиваются.
В текущей спецификации не рассматривается вопрос о том, что делать с закодированными символьными данными. Например, на компьютерах символьные данные на некотором уровне проявляются в закодированной форме и, таким образом, могут рассматриваться как двоичные или символьные данные при сопоставлении с символами URI. Предположительно, спецификация схемы URI должна учитывать эту возможность и требовать того или иного, но на практике лишь немногие из них, если таковые имеются, на самом деле это делают.
Существует нестандартная кодировка символов Юникода: , где xxxx — это кодовая единица UTF-16 , представленная четырьмя шестнадцатеричными цифрами. Такое поведение не указано ни в одном RFC и отклонено W3C. 13-е издание ECMA-262 по-прежнему включает функцию, использующую этот синтаксис: она применяет к строке кодировку UTF-8 , а затем экранирует полученные байты в процентах. [2]%uxxxxescape
При отправке данных, введенных в HTML- формы , имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST или, исторически, по электронной почте . [3] Кодировка, используемая по умолчанию, основана на ранней версии общих правил процентного кодирования URI, [4] с рядом модификаций, таких как нормализация новой строки и замена пробелов +вместо %20. Медиа -тип данных, закодированных таким образом, — application/x-www-form-urlencoded, и в настоящее время он определен в спецификациях HTML и XForms . Кроме того, спецификация CGI содержит правила того, как веб-серверы декодируют данные этого типа и делают их доступными приложениям.
Когда данные формы HTML отправляются в запросе HTTP GET, они включаются в компонент запроса URI запроса, используя тот же синтаксис, который описан выше. При отправке в запросе HTTP POST или по электронной почте данные помещаются в тело сообщения и application/x-www-form-urlencodedвключаются в заголовок Content-Type сообщения.
В следующих спецификациях обсуждаются и определяются зарезервированные символы, незарезервированные символы и процентное кодирование в той или иной форме:
Различные реализации: