Кодирование URL-адресов , официально известное как процентное кодирование , представляет собой метод кодирования произвольных данных в единый идентификатор ресурса (URI) с использованием только символов US-ASCII , допустимых в URI. Хотя оно известно как кодирование URL-адреса , оно также используется в более общем смысле в основном наборе унифицированных идентификаторов ресурсов (URI), который включает в себя как унифицированный указатель ресурса (URL), так и унифицированное имя ресурса (URN). Как таковой, он также используется при подготовке данных медиа- application/x-www-form-urlencoded типа , как часто используется при отправке данных HTML- формы в HTTP- запросах.
Символы, разрешенные в URI, могут быть зарезервированы или незарезервированы (или символ процента как часть процентного кодирования). Зарезервированные символы — это символы, которые иногда имеют особое значение. Например, косая черта используется для разделения различных частей URL-адреса (или, в более общем смысле, URI). Незарезервированные символы не имеют такого значения. При использовании процентного кодирования зарезервированные символы представляются с помощью специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, немного изменились с каждой редакцией спецификаций, регулирующих URI и схемы URI.
Другие символы в URI должны быть закодированы в процентах.
Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в определенном контексте, и схема URI говорит, что необходимо использовать этот символ для какой-то другой цели , тогда символ должен быть закодирован в процентах . Процентное кодирование зарезервированного символа включает преобразование символа в соответствующее ему байтовое значение в ASCII , а затем представление этого значения в виде пары шестнадцатеричных цифр (если есть одна шестнадцатеричная цифра, добавляется ведущий ноль ). Цифры, которым предшествует знак процента ( %) в качестве escape-символа , затем используются в URI вместо зарезервированного символа. (Для символов, отличных от ASCII, они обычно преобразуются в последовательность байтов в UTF-8 , а затем каждое значение байта представляется, как указано выше.)
/Например, зарезервированный символ , если он используется в компоненте «путь» 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 сообщения.
В следующих спецификациях обсуждаются и определяются зарезервированные символы, незарезервированные символы и процентное кодирование в той или иной форме:
Различные реализации: