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