Процентное кодирование - Percent-encoding

Код urlencode в MediaWiki см. Справка: Волшебные слова
Ссылки в Википедии, требующие процентного кодирования, см. Справка: URL (в разделе Исправление ссылок с неподдерживаемыми символами)

Процентов -кодирование, также известный как Кодировка URL, это метод кодировать произвольные данные в Единый идентификатор ресурса (URI) с использованием только ограниченного US-ASCII допустимые символы в URI.

Хотя он известен как Кодировка URL, на самом деле он используется более широко в основном Единый идентификатор ресурса (URI) набор, который включает оба Единый указатель ресурсов (URL) и Единое имя ресурса (УРН). Таким образом, он также используется при подготовке данных приложение / x-www-form-urlencoded тип СМИ, как это часто бывает при отправке HTML форма данные в HTTP Запросы.

Процентное кодирование в URI

Типы символов URI

Допустимые символы в URI: зарезервированный или же безоговорочный (или символ процента как часть процентного кодирования). Зарезервированный символы - это те символы, которые иногда имеют особое значение. Например, косая черта символы используются для разделения разных частей URL (или, в более общем смысле, URI). Безоговорочно у персонажей нет такого значения. При использовании процентного кодирования зарезервированные символы представляются с помощью специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, незначительно менялись с каждым пересмотром спецификаций, управляющих URI и схемами URI.

RFC 3986 Раздел 2.2 Зарезервированные персонажи (Январь 2005 г.)
!#$&'()*+,/:;=?@[]
RFC 3986 Раздел 2.3 Незарезервированные персонажи (Январь 2005 г.)
АBCDEFграммЧАСяJKLMNОпQрSТUVWИксYZ
абcdежграммчасяjkлмпопqрsттыvшИксуz
0123456789-_.~

Остальные символы в URI должны быть закодированы в процентах.

Зарезервированные символы с процентным кодированием

Когда символ из зарезервированного набора («зарезервированный символ») имеет особое значение («зарезервированное назначение») в определенном контексте, а схема URI говорит, что необходимо использовать этот символ для некоторых Другой цель, то персонаж должен быть закодированный в процентах. Процентное кодирование зарезервированного символа включает преобразование символа в соответствующее ему значение байта в ASCII а затем представляя это значение как пару шестнадцатеричный цифры. Цифры, которым предшествует знак процента (%), который используется как escape-символ, затем используются в URI вместо зарезервированного символа (для символа, отличного от ASCII, он обычно преобразуется в свою последовательность байтов в UTF-8, а затем каждое значение байта представлено, как указано выше.)

Зарезервированный персонаж /, например, если используется в компоненте "путь" URI, имеет особое значение быть разделитель между отрезки пути. Если в соответствии с заданной схемой URI, / должно быть в сегмент пути, затем три символа % 2F или же % 2f необходимо использовать в сегменте вместо необработанного /.

Зарезервированные символы после процентного кодирования
!#$%&'()*+,/:;=?@[]
%21%23%24%25%26%27%28%29% 2A% 2B% 2C% 2F% 3A% 3B% 3D% 3F%40% 5B% 5D

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

В "запрос "компонент URI (часть после символа?), например, / по-прежнему считается зарезервированным символом, но обычно не имеет зарезервированного назначения, если в конкретной схеме URI не указано иное. Символ не нужно кодировать в процентах, если он не имеет зарезервированной цели.

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

Незарезервированные символы с процентным кодированием

Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.

URI, которые различаются только тем, является ли незарезервированный символ закодированным в процентах или выглядит буквально, эквивалентны по определению, но процессоры URI на практике не всегда могут распознать эту эквивалентность. Например, потребители URI не следует относиться %41 в отличие от А или же % 7E в отличие от ~, но некоторые делают. Для максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.

Процентное кодирование символа процента

Поскольку символ процента ( % ) служит индикатором для октетов, закодированных в процентах, он должен быть закодирован как %25 чтобы этот октет использовался в качестве данных в URI.

Процентное кодирование произвольных данных

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

Двоичные данные

С момента публикации RFC 1738 в 1994 г. было уточнено, что схемы, предусматривающие представление двоичные данные в URI необходимо разделить данные на 8-битные байты и закодировать каждый байт в процентах таким же образом, как указано выше.[1] Например, значение байта 0x0F должно быть представлено как % 0F, но значение байта 0x41 может быть представлено как А, или же %41. Использование незакодированных символов для буквенно-цифровых и других незарезервированных символов обычно является предпочтительным, поскольку это приводит к более коротким URL-адресам.

Данные персонажа

Процедура процентного кодирования двоичных данных часто экстраполируется, иногда неправильно или не полностью, для применения к символьным данным. в Всемирная паутина в годы становления, когда мы имели дело с символами данных в репертуаре ASCII и использовали соответствующие им байты в ASCII в качестве основы для определения последовательностей, закодированных в процентах, эта практика была относительно безвредной; просто предполагалось, что символы и байты отображаются взаимно однозначно и взаимозаменяемы. Однако потребность в представлении символов вне диапазона ASCII быстро росла, и схемы и протоколы URI часто не обеспечивали стандартных правил для подготовки символьных данных для включения в URI. Следовательно, веб-приложения начали использовать разные многобайтовые, сохранный и другие несовместимые с ASCII кодировки в качестве основы для процентного кодирования, что приводит к неоднозначности и трудностям надежной интерпретации URI.

Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторыми неопределенными кодировка символов перед представлением в URI незарезервированными символами или байтами с процентной кодировкой. Если схема не позволяет URI предоставлять подсказку о том, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI не может быть надежно интерпретирован. В некоторых схемах вообще не учитывается кодирование, и вместо этого просто предлагается, чтобы символы данных отображались непосредственно на символы URI, что оставляет на усмотрение реализации решать, следует ли и как кодировать символы данных в процентах, которые не входят ни в зарезервированные, ни в незарезервированные наборы.

Общие символы после процентного кодирования (на основе ASCII или UTF-8)
новая линияКосмос"%-.<>\^_`{|}~£円
% 0A или же % 0D или же % 0D% 0A%20%22%25% 2D% 2E% 3C% 3E% 5C% 5E% 5F%60% 7B% 7C% 7D% 7E% C2% A3% E5% 86% 86

Данные с произвольными символами иногда кодируются в процентах и ​​используются в ситуациях, не связанных с URI, например, для программ обфускации паролей или других системных протоколов трансляции.

Текущий стандарт

Основная статья: Интернационализированный идентификатор ресурса

Общий синтаксис URI рекомендует, чтобы новые схемы URI, которые обеспечивают представление символьных данных в URI, по сути, представляли символы из незарезервированного набора без перевода и должны преобразовывать все другие символы в байты в соответствии с UTF-8, а затем закодируйте эти значения в процентах. Это предложение было внесено в январе 2005 г. с публикацией RFC 3986. Схемы URI, представленные до этой даты, не затрагиваются.

В текущей спецификации не рассматривается, что делать с кодированными символьными данными. Например, в компьютерах символьные данные проявляются в закодированной форме на некотором уровне и, таким образом, могут обрабатываться либо как двоичные, либо как символьные данные при сопоставлении с символами URI. Предположительно, спецификация схемы URI должна учитывать эту возможность и требовать того или другого, но на практике этого мало, если таковые имеются.

Нестандартные реализации

Для символов Unicode существует нестандартная кодировка: % uхххх, куда хххх это UTF-16 единица кода представлена ​​четырьмя шестнадцатеричными цифрами. Это поведение не определено никакими RFC и было отклоненный от W3C. Восьмое издание ECMA-262 все еще включает побег функция, которая использует этот синтаксис вместе с encodeURI и encodeURIComponent функции, которые применяются UTF-8 кодирование в строку, затем процентное экранирование результирующих байтов.[2]

Тип application / x-www-form-urlencoded

Когда данные, введенные в HTML формы отправляется, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода ПОЛУЧАТЬ или же ПОЧТОВЫЙ, или исторически через электронное письмо.[3] Кодировка, используемая по умолчанию, основана на более ранней версии общих правил процентного кодирования URI,[4] с рядом модификаций, таких как новая линия нормализация и замена пробелов на + вместо %20. В тип СМИ данных, закодированных таким образом, приложение / x-www-form-urlencoded, и в настоящее время он определен в HTML и XForms технические характеристики. В дополнение CGI Спецификация содержит правила того, как веб-серверы декодируют данные этого типа и делают их доступными для приложений.

Когда данные HTML-формы отправляются в запросе HTTP GET, они включаются в компонент запроса URI запроса с использованием того же синтаксиса, который описан выше. При отправке в HTTP ПОЧТОВЫЙ запрос или по электронной почте, данные помещаются в тело сообщения, и приложение / x-www-form-urlencoded включен в заголовок Content-Type сообщения.

Смотрите также

Рекомендации

  1. ^ RFC 1738 §2.2; RFC 2396 §2.4; RFC 3986 §1.2.1, 2.1, 2.5
  2. ^ «Спецификация языка ECMAScript® 2017 (ECMA-262, 8-е издание, июнь 2017 г.)». Ecma International®.
  3. ^ Поддержка пользовательского агента для электронной почты на основе HTML отправка формы с использованием mailto URL как действие формы, было предложено в RFC 1867 раздел 5.6, в эпоху HTML 3.2. Различные веб-браузеры реализовали это, вызвав отдельную почтовую программу или используя свои рудиментарные SMTP возможности. Хотя иногда он был ненадежным, он был недолго популярен как простой способ передачи данных формы без использования веб-сервера или CGI скрипты.
  4. ^ Бернерс-Ли, Т. (июнь 1994 г.). «RFC 1630». Инструменты IETF. IETF. Получено 29 июн 2016.

внешняя ссылка

Все следующие спецификации обсуждают и определяют зарезервированные символы, незарезервированные символы и процентное кодирование в той или иной форме: