Codificarea procentuală (în ), cunoscută și sub denumirea de codificare URL (în ), este o metodă de codificare a datelor arbitrare într-un identificator uniform de resurse (URI), utilizând numai caracterele US-ASCII permise într-un URI. Codificarea procentuală este utilizată pentru a împiedica caracterele speciale să interfereze cu structura și interpretarea URI-ului. Caracterele speciale sunt înlocuite cu semnul procent (%) urmat de două cifre hexazecimale care reprezintă valoarea în octeți a caracterului. De exemplu, un spațiu este codificat de obicei ca %20:

original: http://example.com/my file.txt codificat: http://example.com/my%20file.txt

Deși este cunoscută sub denumirea de codificare URL, aceasta este utilizată și mai general în cadrul ansamblului principal de identificatori uniformi de resurse (URI), care cuprinde atât localizatorii uniformi de resurse (URL), cât și numele uniforme de resurse (URN). Prin urmare, este utilizată și la pregătirea datelor de tip media application/x-www-form-urlencoded, folosit frecvent la trimiterea datelor din formulare HTML în cereri HTTP. Codificarea procentuală nu face distincție între literele mari și mici.

Codificarea procentuală într-un URI

Caracterele permise într-un URI sunt fie rezervate, fie nerezervate (sau un semn procent care face parte dintr-o codificare procentuală). Caracterele rezervate sunt acele caractere care pot avea, în anumite situații, o semnificație specială. De exemplu, caracterele bară oblică sunt utilizate pentru a separa diferite părți ale unui URL (sau, mai general, ale unui URI). Caracterele nerezervate nu au asemenea semnificații. Prin codificarea procentuală, caracterele rezervate sunt reprezentate prin secvențe speciale de caractere. Mulțimile de caractere rezervate și nerezervate, precum și situațiile în care anumite caractere rezervate au o semnificație specială, s-au modificat ușor cu fiecare revizuire a specificațiilor care reglementează URI-urile și schemele URI.

+RFC 3986, secțiunea 2.2, Caractere rezervate (ianuarie 2005) ! # $ & ' ( ) * + , / : ; = ? @ [ ]

+RFC 3986, secțiunea 2.3, Caractere nerezervate (ianuarie 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 - . _ ~

Celelalte caractere dintr-un URI trebuie codificate procentual.

Caractere rezervate Atunci când un caracter din mulțimea rezervată (un „caracter rezervat”) are o semnificație specială (un „scop rezervat”) într-un anumit context, iar o schemă URI impune utilizarea caracterului respectiv într-un alt scop, caracterul trebuie codificat procentual. Codificarea procentuală a unui caracter rezervat presupune convertirea caracterului în valoarea sa corespunzătoare în octeți din ASCII, iar apoi reprezentarea valorii respective ca o pereche de cifre hexazecimale (dacă există o singură cifră hexazecimală, se adaugă un zero inițial). Cifrele, precedate de un semn procent (%) folosit drept caracter escape, sunt apoi utilizate în URI în locul caracterului rezervat. (Un caracter care nu aparține ASCII este, de regulă, convertit în secvența sa de octeți în UTF-8, după care fiecare valoare de octet este reprezentată conform procedeului de mai sus.)

Caracterul rezervat /, de exemplu, atunci când este utilizat în componenta „cale” a unui URI, are semnificația specială de delimitator între segmentele căii. Dacă, potrivit unei anumite scheme URI, / trebuie să se afle în interiorul unui segment al căii, atunci trebuie utilizate cele trei caractere %2F sau %2f în locul unui / necodificat.

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

Caracterele rezervate care nu au un scop rezervat într-un anumit context pot fi, de asemenea, codificate procentual, însă din punct de vedere semantic nu diferă de cele necodificate.

În componenta „interogare” a unui URI (partea aflată după caracterul ?), de exemplu, / este considerat în continuare un caracter rezervat, dar, în mod normal, nu are un scop rezervat, cu excepția cazului în care o anumită schemă URI prevede contrariul. Caracterul nu trebuie codificat procentual atunci când nu are un scop rezervat.

URI-urile care diferă numai prin faptul că un caracter rezervat este codificat procentual sau apare literal nu sunt, în mod normal, considerate echivalente (ca desemnând aceeași resursă), cu excepția cazului în care se poate stabili că respectivele caractere rezervate nu au un scop rezervat. Această determinare depinde de regulile stabilite pentru caracterele rezervate de fiecare schemă URI în parte.

Caractere nerezervate Caracterele din mulțimea nerezervată nu trebuie niciodată codificate procentual.

URI-urile care diferă numai prin faptul că un caracter nerezervat este codificat procentual sau apare literal sunt echivalente prin definiție, însă programele care procesează URI-uri pot să nu recunoască întotdeauna această echivalență în practică. De exemplu, acestea nu ar trebui să trateze %41 diferit de A sau %7E diferit de ~, însă unele o fac. Pentru a asigura interoperabilitatea maximă, se recomandă ca producătorii de URI-uri să nu codifice procentual caracterele nerezervate.

Semnul procent Deoarece semnul procent (%) este utilizat pentru a indica octeții codificați procentual, acesta trebuie la rândul său codificat procentual sub forma %25 atunci când este utilizat ca dată în interiorul unui URI.

Date arbitrare Majoritatea schemelor URI presupun reprezentarea unor date arbitrare, precum o adresă IP sau o cale dintr-un sistem de fișiere, sub forma unor componente ale unui URI. Specificațiile schemelor URI ar trebui să ofere, deși adesea nu o fac, o corespondență explicită între caracterele URI și toate valorile posibile ale datelor reprezentate prin aceste caractere.

Date binare De la publicarea RFC 1738 în 1994, s-a specificat că schemele care permit reprezentarea datelor binare într-un URI trebuie să împartă datele în octeți de 8 biți și să codifice procentual fiecare octet în același mod ca mai sus.RFC 1738, secțiunea 2.2RFC 2396, secțiunea 2.4RFC 3986, secțiunile 1.2.1, 2.1 și 2.5 Valoarea de octet 0x0F, de exemplu, trebuie reprezentată prin %0F, în timp ce valoarea de octet 0x41 poate fi reprezentată prin A sau %41. Utilizarea caracterelor necodificate pentru caracterele alfanumerice și pentru celelalte caractere nerezervate este, de regulă, preferată, deoarece produce URL-uri mai scurte.

Date de tip caracter Procedura de codificare procentuală a datelor binare a fost adesea extinsă, uneori în mod necorespunzător sau fără o specificare completă, pentru a fi aplicată datelor bazate pe caractere. În perioada de formare a World Wide Web-ului, când erau utilizate caractere din repertoriul ASCII, iar octeții corespunzători acestora în ASCII serveau drept bază pentru determinarea secvențelor codificate procentual, această practică era relativ inofensivă; se presupunea pur și simplu că între caractere și octeți exista o corespondență unu-la-unu și că acestea erau interschimbabile. Necesitatea reprezentării caracterelor din afara intervalului ASCII a crescut însă rapid, iar schemele și protocoalele URI nu ofereau adesea reguli standard pentru pregătirea datelor de tip caracter în vederea includerii într-un URI. În consecință, aplicațiile web au început să utilizeze diferite codificări multioctet, cu stare și alte codificări incompatibile cu ASCII ca bază pentru codificarea procentuală, ceea ce a dus la ambiguități și dificultăți în interpretarea fiabilă a URI-urilor.

De exemplu, numeroase scheme și protocoale URI bazate pe RFC 1738 și RFC 2396 presupun că datele de tip caracter vor fi convertite în octeți potrivit unei codificări de caractere nespecificate, înainte de a fi reprezentate într-un URI prin caractere nerezervate sau octeți codificați procentual. Dacă schema nu permite URI-ului să indice ce codificare a fost utilizată sau dacă respectiva codificare intră în conflict cu utilizarea ASCII pentru codificarea procentuală a caracterelor rezervate și nerezervate, URI-ul nu poate fi interpretat în mod fiabil. Unele scheme nu iau deloc în considerare codificarea și sugerează pur și simplu ca datele de tip caracter să fie asociate direct caracterelor URI, lăsând implementărilor sarcina de a decide dacă și cum trebuie codificate procentual caracterele care nu fac parte nici din mulțimea rezervată, nici din cea nerezervată.

+ Caractere comune după codificarea procentuală (pe baza ASCII sau UTF-8)␣"%- . < > \ ^ _ ` { | } ~ £ €%20%22%25%2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E %C2%A3 %E2%82%AC

Datele arbitrare de tip caracter sunt uneori codificate procentual și utilizate în situații care nu implică URI-uri, precum programe de disimulare a parolelor sau alte protocoale de conversie specifice anumitor sisteme.

Standardul actual Sintaxa URI generică recomandă ca noile scheme URI care permit reprezentarea datelor de tip caracter într-un URI să reprezinte, în practică, fără conversie caracterele din mulțimea nerezervată, iar toate celelalte caractere să fie convertite în octeți potrivit UTF-8, după care valorile respective să fie codificate procentual. Această recomandare a fost introdusă în ianuarie 2005, odată cu publicarea RFC 3986. Schemele URI introduse înainte de această dată nu sunt afectate.

Specificația actuală nu stabilește modul în care trebuie tratate datele de tip caracter deja codificate. De exemplu, în calculatoare, datele de tip caracter se manifestă, la un anumit nivel, într-o formă codificată și, prin urmare, ar putea fi tratate fie ca date binare, fie ca date de tip caracter atunci când sunt asociate caracterelor URI. În principiu, specificațiile schemelor URI ar trebui să țină cont de această posibilitate și să impună una dintre cele două variante, însă, în practică, puține dintre ele, dacă există vreuna, fac acest lucru.

Implementări nestandard Există o codificare nestandard pentru caracterele Unicode: %uxxxx, unde xxxx reprezintă o unitate de cod UTF-16 exprimată prin patru cifre hexazecimale. De exemplu, ediția a XIII-a a ECMA-262 include o funcție escape care utilizează această sintaxă. Totuși, acest comportament nu este specificat de niciun RFC și a fost respins de W3C.

Note

Legături externe (ghid) (explicația W3C privind UTF-8 în URI-uri; pagina nu mai este întreținută și poate conține informații inexacte) (tipurile de conținut ale formularelor HTML conform W3C)

Categorie:Standarde Internet Categorie:Motoare de căutare