Procentní kódování - Percent-encoding

Procentní kódování , známé také jako kódování URL , je metoda kódování libovolných dat v identifikátoru URI ( Uniform Resource Identifier ) pomocí pouze omezených znaků US-ASCII, které jsou v rámci URI legální. Ačkoli je známé jako kódování URL, používá se také obecněji v rámci hlavní sady URI ( Uniform Resource Identifier ), která zahrnuje jak URL ( Uniform Resource Locator ), tak Uniform Resource Name (URN). Jako takový se také používá při přípravě dat application/x-www-form-urlencoded typu média , jak se často používá při odesílání dat formuláře HTML v požadavcích HTTP .

Procentuální kódování v URI

Typy znaků URI

Znaky povolené v identifikátoru URI jsou buď vyhrazené, nebo nevyhrazené (nebo znak procent jako součást kódování procent). Vyhrazené znaky jsou znaky, které někdy mají zvláštní význam. Například lomítko znaky se používají k oddělení jednotlivých částí adresy URL (nebo obecněji URI). Nezasloužené postavy nemají žádný takový význam. Použitím procentního kódování jsou vyhrazené znaky reprezentovány pomocí speciálních posloupností znaků. Sady vyhrazených a nevyhrazených znaků a okolnosti, za nichž mají určité vyhrazené znaky zvláštní význam, se při každé revizi specifikací, které upravují URI a schémata URI, mírně změnily.

Ostatní znaky v identifikátoru URI musí být kódovány v procentech.

Vyhrazené postavy

Pokud má znak z vyhrazené množiny („vyhrazený znak“) v určitém kontextu zvláštní význam („vyhrazený účel“) a schéma URI říká, že je nutné použít tento znak k jinému účelu, pak znak musí být kódován procenty . Procentuální kódování vyhrazeného znaku zahrnuje převedení znaku na jeho odpovídající bajtovou hodnotu v ASCII a následnou reprezentaci této hodnoty jako dvojice hexadecimálních číslic. Číslice, kterým předchází znak procenta ( %), který se používá jako únikový znak , se poté použijí v identifikátoru URI místo vyhrazeného znaku. (U znaku jiného než ASCII se obvykle převádí na bajtovou sekvenci v UTF-8 a poté je každá hodnota bajtu reprezentována výše.)

Vyhrazený znak /, například pokud je použit v komponentě „cesta“ identifikátoru URI , má zvláštní význam jako oddělovač mezi segmenty cesty. Pokud podle daného schématu URI /musí být v segmentu cesty, pak v segmentu místo surového musí být použity tři znaky %2Fnebo . %2f/

Vyhrazené znaky, které nemají v určitém kontextu vyhrazený účel, mohou být také kódovány v procentech, ale nejsou sémanticky odlišné od těch, které nejsou.

V komponentě " dotaz " URI (část po znaku?) Je například /stále považována za vyhrazený znak, ale obvykle nemá vyhrazený účel, pokud konkrétní schéma URI nestanoví jinak. Znak nemusí být kódován v procentech, pokud nemá vyhrazený účel.

Identifikátory URI, které se liší pouze tím, zda je vyhrazený znak zakódován v procentech, nebo se objevují doslova, jsou obvykle považovány za ne rovnocenné (označující stejný zdroj), pokud nelze určit, že dotyčné vyhrazené znaky nemají vyhrazený účel. Toto určení závisí na pravidlech stanovených pro vyhrazené znaky jednotlivými schématy URI.

Nevyhrazené postavy

Znaky z nerezervované sady nikdy nemusí být kódovány procenty.

Identifikátory URI, které se liší pouze tím, zda je bezvýhradný znak zakódován v procentech nebo se jeví doslova, jsou podle definice ekvivalentní, ale procesory URI v praxi nemusí vždy tuto rovnocennost rozpoznat. Například spotřebitelé URI by neměli zacházet %41odlišně od Anebo %7Eodlišně od ~, ale někteří ano. Pro maximální interoperabilitu jsou producenti URI odrazováni od procentního kódování nevyhrazených znaků.

Procentní charakter

Protože znak procenta ( %) slouží jako indikátor pro procenta zakódované oktety, musí být kódován v procentech, %25aby byl tento oktet použit jako data v rámci URI.

Libovolná data

Většina schémat URI zahrnuje reprezentaci libovolných dat, jako je adresa IP nebo cesta systému souborů , jako součásti identifikátoru URI. Specifikace schématu URI by měly, ale často neposkytují, poskytovat explicitní mapování mezi znaky URI a všemi možnými hodnotami dat reprezentovanými těmito znaky.

Binární data

Od vydání RFC 1738 v roce 1994 bylo specifikováno, že schémata, která zajišťují reprezentaci binárních dat v URI, musí rozdělit data na 8bitové bajty a procentní kódování každého bajtu stejným způsobem jako výše. %0FBajtová hodnota 0x0F by například měla být reprezentována , ale bajtová hodnota 0x41 může být reprezentována A, nebo %41. Obvykle se upřednostňuje použití nekódovaných znaků pro alfanumerické a jiné nezarezervované znaky, protože vede ke kratším adresám URL.

Údaje o postavách

Postup pro procentní kódování binárních dat byl často extrapolován, někdy nevhodně nebo bez toho, aby byl zcela specifikován, aby se vztahoval na data založená na znaku. Ve formativních letech World Wide Web , kdy se zabývalo datovými znaky v repertoáru ASCII a používalo jejich odpovídající bajty v ASCII jako základ pro určování procentuálně kódovaných sekvencí, byla tato praxe relativně neškodná; pouze se předpokládalo, že znaky a bajty mapovaly jedna k jedné a byly zaměnitelné. Potřeba reprezentovat znaky mimo rozsah ASCII však rychle rostla a schémata a protokoly URI často neposkytovaly standardní pravidla pro přípravu znakových dat pro zahrnutí do URI. Webové aplikace následně začaly používat různá vícebajtová, stavová a jiná kódování nekompatibilní s ASCII jako základ pro procentní kódování, což vedlo k nejednoznačnostem a obtížnému interpretování URI.

Například mnoho schémat a protokolů URI založených na RFC 1738 a 2396 předpokládá, že datové znaky budou převedeny na bajty podle nějakého nespecifikovaného kódování znaků, než budou v URI reprezentovány nezarezervovanými znaky nebo procentně zakódovanými bajty. Pokud schéma neumožňuje identifikátoru URI poskytnout nápovědu k tomu, jaké kódování bylo použito, nebo pokud je kódování v konfliktu s použitím ASCII pro kódování procent vyhrazených a nevyhrazených znaků, pak identifikátor URI nelze spolehlivě interpretovat. Některá schémata vůbec neberou ohled na kódování a místo toho jen navrhují, aby se datové znaky mapovaly přímo na znaky URI, což ponechává na implementacích, aby rozhodly, zda a jak procentuálně kódovat datové znaky, které nejsou ani ve vyhrazených, ani v nerezervovaných sadách.

Libovolná znaková data jsou někdy procentuálně kódována a používána v situacích, které nejsou identifikátory URI, například v programech pro obfuskaci hesel nebo jiných systémově specifických překladových protokolech.

Současný standard

Obecná syntaxe URI doporučuje, aby nová schémata URI, která zajišťují reprezentaci znakových dat v URI, ve skutečnosti představovala znaky z nerezervované sady bez překladu a měla by převádět všechny ostatní znaky na bajty podle UTF-8 a poté procentní kódování těchto hodnot. Tento návrh byl zaveden v lednu 2005 vydáním dokumentu RFC 3986. Schémata URI zavedená před tímto datem nejsou ovlivněna.

Aktuální specifikace neřeší, co dělat s kódovanými znakovými daty. Například v počítačích se znaková data na určité úrovni projevují v kódované podobě, a proto by při mapování na znaky URI mohla být považována za binární nebo znaková data. Pravděpodobně je na specifikacích schématu URI, aby tuto možnost zohlednily a vyžadovaly jedno nebo druhé, ale v praxi to ve skutečnosti dělá jen málo, pokud vůbec nějaké.

Nestandardní implementace

Existuje nestandardní kódování znaků Unicode :, kde xxxx je jednotka kódu UTF-16 reprezentovaná čtyřmi hexadecimálními číslicemi. Toto chování není specifikováno žádným RFC a bylo odmítnuto W3C. Osmý vydání ECMA-262 stále obsahuje funkce, která používá tuto syntaxi, společně s a funkce, které se uplatňují UTF-8 kódování na řetězec, pak procento-uniknout výsledných bajtů. %uxxxxescapeencodeURIencodeURIComponent

Typ application/x-www-form-urlencoded

Když jsou odeslána data, která byla zadána do formulářů HTML , jsou názvy a hodnoty polí formuláře zakódovány a odeslány na server ve zprávě požadavku HTTP pomocí metody GET nebo POST , nebo historicky prostřednictvím e -mailu . Výchozí kódování je založeno na rané verzi obecných pravidel pro kódování procenta URI s řadou úprav, jako je normalizace nového řádku a nahrazení mezer +místo %20. Takto kódovaný typ média je application/x-www-form-urlencodeda je aktuálně definován ve specifikacích HTML a XForms . Kromě toho CGI specifikace obsahuje pravidla pro to, jak webové servery dekódovat data tohoto typu a aby byl k dispozici pro aplikace.

Když jsou data formuláře HTML odeslána v požadavku HTTP GET, jsou zahrnuta do komponenty dotazu URI požadavku pomocí stejné syntaxe popsané výše. Při odeslání v požadavku HTTP POST nebo e-mailem jsou data umístěna v těle zprávy a application/x-www-form-urlencodedjsou obsažena v záhlaví typu obsahu zprávy.

Viz také

• Internacionalizovaný identifikátor zdroje
• Punycode
• Kódování binárního textu na srovnání různých kódovacích algoritmů
• Shellcode

Reference

externí odkazy

• DevPal URL encoder - online vývojářské nástroje, které podporují kódování URL.

Následující specifikace všechny diskutují a definují vyhrazené znaky, nevyhrazené znaky a procentuální kódování v nějaké formě:

• RFC  3986 / STD 66 (plus errata ), aktuální obecná specifikace syntaxe URI.
• RFC  2396 (zastaralé, plus errata ) a RFC 2732 (plus errata ) společně obsahovaly předchozí verzi obecné specifikace syntaxe URI.
• URL Encode and Decode - Online - web s různými možnostmi převodu souborů nebo textů do formátu zakódovaného URL.
• RFC  1738 (většinou zastaralé) a RFC 1808 (zastaralé), které definují adresy URL .
• RFC  1630 (zastaralý), první obecná specifikace syntaxe URI.
• Pokyny W3C k pojmenování a adresování: URI, URL, ...
• W3C vysvětlení UTF-8 v URI
• W3C HTML tvoří typy obsahu