Відсоткове кодування англ Percent encoding також відоме як URL кодування механізм для кодування інформації в уніфіковано

Відсоткове кодування (англ. Percent-encoding, також відоме як URL-кодування) — механізм для кодування інформації в уніфікованому ідентифікаторі ресурсів (URI), який використовується для кодування певних символів у вигляді %xx, де x — цифра чи буква від «a» до «f» (цифри в шістнадцятковій системі числення). Часто це кодування називають «URL-кодуванням» (URL — уніфікований локатор ресурсів), хоча воно використовується в URI, яке окрім URL містить також URN (уніфіковані імена ресурсів). Кодування також використовується при підготовці даних типу application/x-www-form-urlencoded, які застосовуються при передачі даних HTML-форм та HTTP-запитів.

Відсоткове кодування в URI

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

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

Зарезервовані символи

! * ' ( ) ; : @ & = + $ , / ? # [ ]

Незарезервовані символи

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, і запис цього значення в шістнадцятковій системі числення двома цифрами після знаку %. Знак відсотка і дві шістнадцядкові цифри після нього трактуються як керувальна послідовність, яка використовується в URI на місці зарезервованого символу. Символи що не належать до ASCII, переводяться до їх байтового значення в UTF-8 і після цього таким самим чином їхнє шістнадцяткове представлення записується після знака відсотка.

Наприклад, зарезервований символ / використовується в URI як розділювач сегментів локатора ресурсів. Тому якщо, відповідно до даної схеми URI, коса риска має бути простим символом всередині сегменту, то замість просто символу / слід вставити послідовність з трьох символів %2F.

`!`	`#`	`$`	`%`	`&`	`'`	`(`	`)`	`*`	`+`	`,`	`/`	`:`	`;`	`=`	`?`	`@`	`[`	`]`
`%21`	`%23`	`%24`	`%25`	`%26`	`%27`	`%28`	`%29`	`%2A`	`%2B`	`%2C`	`%2F`	`%3A`	`%3B`	`%3D`	`%3F`	`%40`	`%5B`	`%5D`

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

В компоненті URI, який називається «query» (запит), і який починається після символу ?, символ / і досі вважається зарезервованим, хоча в цій частині URI не має жодного спеціального значення (якщо інше не вказане в схемі URI). Символ необов'язково закодовувати відсотковим кодуванням там, де він не має спеціального значення.

Уніфіковані ідентифікатори ресурсів, які відрізняються лише тим чи зарезервований символ закодований відсотковим кодуванням чи ні, зазвичай вважаються нееквівалентними, хоча і можуть вказувати на той самий ресурс. Якщо в схемі URI зарезервований символ вказується як такий, що не має спеціального значення, то тоді уніфіковані ідентифікатори ресурсів з цим символом закодованим і незакодованим вважаються еквівалентними.

Відсоткове кодування незарезервованих символів

Не існує потреби в закодовуванні незарезервованих символів. Попри це, все ж існує можливість закодовування незарезервованих символів, хоча це не рекомендується. Уніфіковані ідентифікатори ресурсів, які відрізняються лише тим чи незарезервований символ закодований відсотковим кодуванням чи ні, вважаються еквівалентними за визначенням. Але на практиці, деякі обробники URI можуть не визнавати цієї еквівалентності. В теорії, обробники URI повинні ставитися до %41 так само як і до A або до %7E так само як і до ~.

Відсоткове кодування символа відсотка

Оскільки знак відсотка використовується як показник початку закодованого символа, то для включення до URI самого знаку відсотка потрібно використовувати послідовність %25.

Відсоткове кодування інших даних

Більшість схем URI включають в себе представлення інших даних, таких як IP-адреси або адреси у файлових системах, як компоненти URI. Специфікації схем URI мали би задавати, але на практиці не задають, однозначну відповідність між символами URI та всіма можливими значеннями даних які би представлялись цими символами.

Із запровадженням стандарту RFC 1738 в 1994 році, було визначено, що схеми які забезпечують представлення двійкових даних в URI повинні розділяти дані на байти і закодовувати кожен з них за допомогою відсоткового кодування. Таким чином, наприклад, байтове значення 0x0F повинне зашифровуватись як %0F, а значення 0x41 як A або %41. Використання незакодованих символів для позначення буквенно-цифрових та інших незарезервованих символів використовується набагато частіше, оскільки результатом застосування такого варіанту є більш короткі URL.

Процедура відсоткового кодування бінарних даних часто використовувалась, іноді некоректно або без належного опису, для кодування символьних даних. Під час ранніх років існування всесвітнього павутиння, коли символам завжди відповідав їх ASCII-код, така практика не створювала багато проблем. Тоді просто вважалось що символи та байти прив'язані одне до одного і можна перетворювати одне на інше. Однак, швидко зростала необхідність представлення символів не з ASCII, і схеми та протоколи URI часто не мали стандартизованих правил для підготовки символьних даних до включення в URI. Внаслідок цього вебдодатки почали застосовувати різні багатобайтові, станові та інші кодування що могли працювати з не-ASCII символами як основу для відсоткового кодування, що призвело до складнощів та двузначностей в інтерпритації деяких URI.

Зокрема, схеми та протоколи URI, які базуються на стандартах RFC 1738 та RFC 2396, передбачають що символьні дані мають бути переведені в байти відповідно до якогось алгоритму кодування, перед тим як бути включеними до URI у вигляді незарезервованих символів або відсоткових послідовностей. Якщо схема не дозволяє URI вказати яке саме кодування було застосоване або якщо кодування конфліктує з відсотковим кодуванням ASCII-символів, то URI не може бути надійно інтерпретоване. Деякі схеми взагалі не застосовують кодування, замість цього вважаючи що символи даних прямо відповідають символам URI, і цим покладають відсоткове кодування ASCII-символів на конкретні імплементації схеми.

Найчастіше використовувані символи (ASCII або UTF-8)
`Новий рядок`	`Пропуск`	`"`	`%`	`-`	`.`	`<`	`>`	`\`	`^`	`_`	`	`{`	`\|`	`}`	`~`
`%0A` або `%0D` або `%0D%0A`	`%20`	`%22`	`%25`	`%2D`	`%2E`	`%3C`	`%3E`	`%5C`	`%5E`	`%5F`	`%60`	`%7B`	`%7C`	`%7D`	`%7E`

Відсоткове кодування літер української абетки

Кириличні символи, зокрема і літери української абетки, не належать до ASCII, тому мають закодовуватись відсотковим кодуванням перед тим як бути включеними до URI. Наприклад, хоч переважна більшість сучасних браузерів і показує кириличні символи замість відсоткових послідовностей в адресному рядку, технічно, справжньою URL-адресою цієї статті є https://uk.wikipedia.org/wiki/%D0%92%D1%96%D0%B4%D1%81%D0%BE%D1%82%D0%BA%D0%BE%D0%B2%D0%B5_%D0%BA%D0%BE%D0%B4%D1%83%D0%B2%D0%B0%D0%BD%D0%BD%D1%8F.

Коди для українських літер йдуть поспіль (код наступної літери = код попередньої + 1), окрім літер «ґ», «є», «і» та «ї», коди яких не вписуються в послідовність, а також окрім декількох проміжків, де наступний код є збільшенням попереднього більше ніж на 1. Це все тому, що в UTF-8 спочатку задаються літери російської абетки (крім «ё»), а лише потім літери інших кириличних абеток (зокрема і української), які не входять до російської абетки. Тому для літер російської абетки, на відміну від української, всі коди (крім «ё») йдуть поспіль.

А	%D0%90
Б	%D0%91
В	%D0%92
Г	%D0%93
Ґ	%D2%90
Д	%D0%94
Е	%D0%95
Є	%D0%84
Ж	%D0%96
З	%D0%97
И	%D0%98
І	%D0%86
Ї	%D0%87
Й	%D0%99
К	%D0%9A
Л	%D0%9B
М	%D0%9C
Н	%D0%9D
О	%D0%9E
П	%D0%9F
Р	%D0%A0
С	%D0%A1
Т	%D0%A2
У	%D0%A3
Ф	%D0%A4
Х	%D0%A5
Ц	%D0%A6
Ч	%D0%A7
Ш	%D0%A8
Щ	%D0%A9
Ь	%D0%AC
Ю	%D0%AE
Я	%D0%AF
а	%D0%B0
б	%D0%B1
в	%D0%B2
г	%D0%B3
ґ	%D2%91
д	%D0%B4
е	%D0%B5
є	%D1%94
ж	%D0%B6
з	%D0%B7
и	%D0%B8
і	%D1%96
ї	%D1%97
й	%D0%B9
к	%D0%BA
л	%D0%BB
м	%D0%BC
н	%D0%BD
о	%D0%BE
п	%D0%BF
р	%D1%80
с	%D1%81
т	%D1%82
у	%D1%83
ф	%D1%84
х	%D1%85
ц	%D1%86
ч	%D1%87
ш	%D1%88
щ	%D1%89
ь	%D1%8C
ю	%D1%8E
я	%D1%8F
'	%27

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

Коли відправляються дані, що були введені до HTML-форми, назви і значення змінних форми закодовуються і відсилаються до сервера у вигляді HTTP-запита через метод POST або через метод GET, або, історично, через електронний лист. Кодування що використовується за замовчуванням засноване на ранній версії основних правил відсоткового кодування URI, які були декілька разів доповнені, наприклад нормалізацією символе нового рядка або кодуванням пробілу як + а не %20. Типом даних для закодованих таким чином даних є application/x-www-form-urlencoded, і він наразі визначений (хоча і досі в застарілій формі) в специфікаціях HTML та XForms. До того ж, специфікація CGI містить правила щодо того як вебсервери повинні декодовувати дані цього типу і робити їх доступними для додатків.

Коли дані з HTML-форми відсилаються GET-запитом, вони включаються в компонент «query» в URI використовуючи синтаксис, який описаний вище. Коли дані відсилаються методом POST або електронним листом, вони включаються в тіло повідомлення і до заголовку «Content-Type» записується application/x-www-form-urlencoded.

Див. також

Посилання

RFC 3986 / STD 66 — поточна специфікація загального синтаксису URI.
RFC 2396 (застарілий) та RFC 2732 разом визначають попередню версію специфікації загального синтаксису URI.
RFC 1738 (переважно застарілий) та RFC 1808 (застарілий), які визначають URL.
RFC 1630 (застарілий), перша загальна специфікація синтаксису URI.
Інструкції від W3C щодо імен та адрес, що використовуються в URI та URL [ 26 квітня 2021 у Wayback Machine.]
Роз'яснення від W3C щодо використання UTF-8 в URI [ 25 лютого 2021 у Wayback Machine.]
W3C типи контенту у формах HTML [ 22 квітня 2021 у Wayback Machine.]