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

Кодирование 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 г.)

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

%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-битные байты и процентно кодировать каждый байт таким же образом, как указано выше. Например, значение байта 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)

␣

"

%

-

.

<

>

\

^

_

`

{

|

}

~

£

€

%20

%22

%25

%2D

%2E

%3C

%3E

%5C

%5E

%5F

%60

%7B

%7C

%7D

%7E

%C2%A3

%E2%82%AC

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

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

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

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

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

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

Существует нестандартная кодировка символов Юникода: %uxxxx, где xxxx — это кодовая единица UTF-16, представленная четырьмя шестнадцатеричными цифрами. Такое поведение не указано ни в одном RFC и отклонено W3C . 13-е издание ECMA-262 по-прежнему включает escape функция, использующая этот синтаксис, которая применяет UTF-8 , а затем экранирует полученные байты в процентах. к строке кодировку

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

При отправке данных, введенных в 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 включается в заголовок Content-Type сообщения.

См. также

• Интернационализированный идентификатор ресурса
• Пуникод
• Кодирование двоичного текста в текст для сравнения различных алгоритмов кодирования.
• Шеллкод
• База64

Внешние ссылки

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

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

Различные реализации:

• Кодировщик URL-адресов DevPal — онлайн-инструменты разработчика, поддерживающие кодирование URL-адресов.
• Онлайн-кодер и декодер URL-адресов — кодирует или декодирует URL-адреса в браузере.
• URL Encoder онлайн – веб-сайт с различными опциями для преобразования файлов или текстов в формат, закодированный в URL.
• URL-кодирование и декодирование — онлайн — веб-сайт с различными вариантами преобразования файлов или текстов в формат, закодированный по URL-адресу.