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

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

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

Процентное кодирование в URI [ править ]

Типы символов URI [ править ]

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

RFC 3986 раздел 2.2 Зарезервированные символы (январь 2005 г.)
!#$&'()*+,/:;=?@[]
RFC 3986 раздел 2.3 Незарезервированные символы (январь 2005 г.)
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
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иначе 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, что оставляет на усмотрение реализации решение о том, следует ли и как процентно кодировать символы данных, которые не входят ни в зарезервированные, ни в незарезервированные наборы.

Общие символы после процентного кодирования (на основе ASCII или UTF-8)
newlinespace"%-.<>\^_`{|}~£円
%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:, где xxxx - это кодовая единица UTF-16, представленная четырьмя шестнадцатеричными цифрами. Такое поведение не определено никакими RFC и было отклонено W3C. Восьмое издание ECMA-262 по- прежнему включает функцию, использующую этот синтаксис, а также функции и, которые применяют кодировку UTF-8 к строке, а затем экранируют полученные байты в процентах. [2]%uxxxxescapeencodeURIencodeURIComponent

Тип application / x-www-form-urlencoded [ править ]

При отправке данных, которые были введены в формы 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 сообщения.

См. Также [ править ]

  • Интернационализированный идентификатор ресурса
  • Punycode
  • Двоичное кодирование текста для сравнения различных алгоритмов кодирования
  • Шеллкод

Ссылки [ править ]

  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- формна основе электронной почтыс использованием URL - адреса mailtoв качестве действия формы была предложена в разделе 5.6 RFC 1867 в эпоху HTML 3.2. Различные веб-браузеры реализовали это, вызвав отдельную программу электронной почты или используя свои собственные элементарныевозможности SMTP . Хотя иногда он был ненадежным, он некоторое время пользовался популярностью как простой способ передачи данных формы без использования веб-сервера илисценариев CGI .
  4. ↑ Бернерс-Ли, Т. (июнь 1994 г.). «RFC 1630» . Инструменты IETF . IETF . Проверено 29 июня +2016 .

Внешние ссылки [ править ]

  • DevPal URL encoder - онлайн-инструменты для разработчиков, поддерживающие кодирование URL.

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

  • RFC 3986 / STD 66 (плюс исправления ), текущая общая спецификация синтаксиса URI.
  • RFC 2396 (устаревший, плюс исправления ) и RFC 2732 (плюс исправления ) вместе составляют предыдущую версию общей спецификации синтаксиса URI.
  • Кодирование и декодирование URL - Интернет - веб-сайт с различными вариантами преобразования файлов или текстов в формат с кодировкой URL.
  • RFC 1738 (в основном устаревший) и RFC 1808 (устаревший), которые определяют URL-адреса .
  • RFC 1630 (устаревший), первая универсальная спецификация синтаксиса URI.
  • Рекомендации W3C по именованию и адресации: URI, URL-адреса, ...
  • Объяснение W3C UTF-8 в URI
  • Типы содержимого HTML-форм W3C