Войти
Процентное -кодирование, также известное как Кодирование URL - это метод кодирования информации в унифицированном идентификаторе ресурса (URI) при определенных обстоятельствах.
Хотя это называется кодировкой URL-адресов, на самом деле она используется более широко в основном наборе Uniform Resource Identifier (URI), который включает в себя оба Uniform Resource Locator (URL) и Универсальное имя ресурса (URN). Таким образом, он также используется при подготовке данных для application/x-www-form-urlencodedтипа носителя, как это часто бывает при отправке HTML. формирует данные в HTTP запросах.
Допустимые символы URI либо зарезервированы, либо не зарезервированы (или символ процента как часть процентного кодирования). Зарезервированные символы - это те символы, которые иногда имеют особое значение. Например, символы косой черты используются для разделения различных частей URL-адреса (или, в более общем смысле, URI). Незарезервированные символы не имеют такого значения. При использовании процентного кодирования зарезервированные символы представляются с помощью специальных последовательностей символов. Наборы зарезервированных и незарезервированных символов, а также обстоятельства, при которых определенные зарезервированные символы имеют особое значение, незначительно менялись с каждым пересмотром спецификаций, управляющих URI и схемами URI.
! | * | ' | ( | ) | ; | : | @ | | = | + | $ | , | / | ? | # | [ | ] |
A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | |
a | b | c | d | e | f | g | h | i | j | k | l | m | n | o | p | q | r | s | t | u | v | w | x | y | z | |
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | - | _ | . | ~ | |||||||||||||
Другие символы в 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 |
Зарезервированные символы, которые не имеют зарезервированной цели в конкретном контексте, также могут быть закодированы в процентах, но семантически не отличаются от тех, которые не имеют.
В компоненте «query » URI (часть после символа?), Например, /по-прежнему считается зарезервированным символом, но обычно имеет нет зарезервированной цели, если в конкретной схеме URI не указано иное. Символ не нужно кодировать в процентах, если он не имеет зарезервированной цели.
URI, которые различаются только тем, является ли зарезервированный символ закодированным в процентах или отображается буквально, обычно считаются не эквивалентными (обозначающими один и тот же ресурс), если не может быть определено, что рассматриваемые зарезервированные символы не имеют зарезервированной цели. Это определение зависит от правил, установленных для зарезервированных символов отдельными схемами URI.
Символы из незарезервированного набора никогда не нуждаются в процентном кодировании.
URI, которые отличаются только тем, является ли незарезервированный символ закодированным в процентах или выглядит буквально, эквивалентны по определению, но процессоры URI на практике могут не всегда распознавать эту эквивалентность. Например, потребители URI не должны обрабатывать % 41иначе, чем Aили % 7Eиначе, чем ~, но некоторые это делают. Для максимальной совместимости производителям URI не рекомендуется использовать процентное кодирование незарезервированных символов.
Поскольку символ процента (%) служит индикатором для октетов с процентным кодированием, он должен быть закодирован в процентах как % 25, чтобы этот октет использовался в качестве данных в URI.
Большинство схем URI включают представление произвольных данных, таких как IP-адрес или путь к файловой системе, как компоненты URI. Спецификации схемы URI должны, но часто этого не делать, предоставлять явное сопоставление между символами URI и всеми возможными значениями данных, представленными этими символами.
С момента публикации RFC 1738 в 1994 году было указано, что схемы, которые обеспечивают представление двоичных данных в URI должен разделить данные на 8-битные байты и закодировать каждый байт в процентах таким же образом, как указано выше. Например, байтовое значение 0x0F должно быть представлено как % 0F, а байтовое значение 0x41 может быть представлено как Aили % 41. Использование незакодированных символов для буквенно-цифровых и других незарезервированных символов обычно является предпочтительным, поскольку это приводит к более коротким URL-адресам.
Процедура процентного кодирования двоичных данных часто экстраполировалась, иногда неправильно или не полностью, для применения к символьным данным. В годы становления World Wide Web при работе с символами данных в репертуаре ASCII и использовании соответствующих им байтов в ASCII в качестве основы для определения последовательностей, закодированных в процентах, эта практика была относительно безвредной; просто предполагалось, что символы и байты отображаются взаимно однозначно и взаимозаменяемы. Однако потребность в представлении символов вне диапазона ASCII быстро росла, и схемы и протоколы URI часто не обеспечивали стандартных правил подготовки символьных данных для включения в URI. Следовательно, веб-приложения начали использовать различные многобайтовые кодировки, с отслеживанием состояния и другие несовместимые с ASCII кодировки в качестве основы для процентного кодирования, что привело к неоднозначности и трудностям при надежной интерпретации URI.
Например, многие схемы и протоколы URI, основанные на RFC 1738 и 2396, предполагают, что символы данных будут преобразованы в байты в соответствии с некоторой неопределенной кодировкой символов перед тем, как они будут представлены в URI незарезервированным символов или байтов, закодированных в процентах. Если схема не позволяет URI предоставлять подсказку о том, какая кодировка использовалась, или если кодировка конфликтует с использованием ASCII для процентного кодирования зарезервированных и незарезервированных символов, то URI не может быть надежно интерпретирован. В некоторых схемах вообще не учитывается кодирование, и вместо этого просто предлагается, чтобы символы данных отображались непосредственно на символы URI, что оставляет на усмотрение реализации решать, следует ли и как кодировать символы данных в процентах, которые не входят ни в зарезервированные, ни в незарезервированные наборы.
новая строка | пробел | " | % | - | . | < | > | \ | ^ | _ | ` | { | | | } | ~ | £ | 円 |
% 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: % uxxxx, где xxxx - это код UTF-16 единица измерения представлена четырьмя шестнадцатеричными цифрами. Это поведение не определено никакими RFC и было отклонено W3C. Восьмое издание ECMA-262 по-прежнему включает функцию escape, которая использует этот синтаксис, а также функции encodeURIи encodeURIComponent, которые применяются UTF-8 кодирование в строку, затем процентное экранирование результирующих байтов.
Когда данные, которые были введены в HTML формы, имена и значения полей формы кодируются и отправляются на сервер в сообщении HTTP-запроса с использованием метода GET или POST, или, исторически, через по электронной почте. Кодировка, используемая по умолчанию, основана на ранней версии общих правил процентного кодирования URI с рядом модификаций, таких как нормализация новой строки и замена пробелов на +вместо % 20. тип носителя данных, закодированных таким образом, - это application / x-www-form-urlencoded, и в настоящее время он определен в спецификациях HTML и XForms. Кроме того, спецификация CGI содержит правила того, как веб-серверы декодируют данные этого типа и делают их доступными для приложений.
Когда данные HTML-формы отправляются в запросе HTTP GET, они включаются в компонент запроса URI запроса с использованием того же синтаксиса, который описан выше. При отправке в запросе HTTP POST или по электронной почте данные помещаются в тело сообщения, а application / x-www-form-urlencodedвключается в содержимое сообщения. -Тип заголовка.
Все следующие спецификации обсуждают и определяют зарезервированные символы, незарезервированные символы и процентное кодирование в той или иной форме:
