Ce este codificarea URL (percent-encoding)?
Răspuns rapid: Codificarea URL traduce caracterele cu sens special în URL-uri (spații, ampersand, semnul egal) într-un format acceptat global: semnul procent (%) urmat de două cifre hexazecimale.
Arhitectura internetului cere ca Uniform Resource Locator (URL) să fie transmis prin HTTP în setul US-ASCII. Dacă un URL conține caractere în afara acestui alfabet — spații, emoji sau text chirilic — browserul sau serverul interpretează greșit ruta.
Ca să transmiți date complexe într-un query string, aplici codificarea URL (percent-encoding). Algoritmul convertește caracterele nesigure într-un simbol % urmat de reprezentarea hexazecimală a valorii ASCII/UTF-8.
De exemplu, spațiul devine %20, iar ampersand-ul (&) devine %26. Datele ajung intacte la server.
De ce contează encodeURI() față de encodeURIComponent()
Răspuns rapid: encodeURI() codifică un URL complet fără să strice structura (de exemplu http://). encodeURIComponent() codifică parametri de date (o căutare), pentru că encodează agresiv slash-urile și semnele egal.
Un bug frecvent în JavaScript este alegerea funcției greșite de codificare URL. Diferența evită erorile 404 și cererile API rupte.
- encodeURI(): Presupune că transmiți un URL complet și valid. Codifică spațiile și caracterele străine, dar nu codifică caracterele cu rol structural, precum
?, =, &, / sau :.
- encodeURIComponent(): Presupune că codifici o bucată de date pe care o inserezi în query string. Codifică agresiv aproape tot, inclusiv slash-uri și ampersand-uri. Folosește-o când iei input de la utilizator și îl adaugi ca parametru URL.
Codificatorul URL din Utiliome folosește strict semantica encodeURIComponent(), ca payload-urile de dezvoltator să fie escape-uite în siguranță.
Riscul de confidențialitate la decodificarea URL-urilor online
Răspuns rapid: Multe URL-uri conțin tokenuri de autentificare, hash-uri de resetare a parolei sau e-mailuri de clienți în query. Lipirea lor într-un decodificator din cloud le expune în jurnale. Utiliome procesează totul 100% local.
Dezvoltatorii decodifică adesea șiruri URL ca să depaneze redirecționări OAuth sau payload-uri de webhook (de exemplu ?email=user%40example.com&token=abc%3D%3D).
Dacă lipești acest șir într-o unealtă SEO generică, URL-ul pleacă într-o cerere HTTP POST către un server la distanță. Administratorul poate jurnaliza tokenuri OAuth, ID-uri de sesiune și date cu caracter personal.
Utiliome lucrează local, fără încredere implicită în server. Matematica de decodificare rulează în RAM-ul browserului. Poți decodifica chei API de producție știind că datele nu ating o rețea externă.
Emoji și Unicode în URL-uri
Răspuns rapid: Algoritmele moderne de codificare URL suportă caractere Unicode pe mai mulți octeți. Un emoji precum 🚀 este mapat mai întâi la octeții UTF-8, apoi fiecare octet este codificat cu procent.
La început, URL-urile erau strict ASCII englezesc. Astăzi conțin limbi globale, scriere arabă și emoji complexe.
Standardul modern (RFC 3986) cere ca caracterele străine să fie convertite întâi într-o secvență de octeți UTF-8. Fiecare octet este apoi codificat cu procent.
Emoji-ul rachetă (🚀) cere patru octeți în UTF-8. Trecut prin codificatorul Utiliome, devine matematic %F0%9F%9A%80. Orice server backend poate ruta și decodifica emoji-ul, indiferent de limba principală.
Caractere rezervate și nerezervate
Răspuns rapid: Standardele URL definesc caractere „nerezervate” (litere, cifre, cratimă, punct) care nu trebuie codificate. Caracterele „rezervate” (?, =, &) sunt comenzi structurale și trebuie codificate agresiv dacă apar ca date brute.
Ca să stăpânești codificarea URL, trebuie să cunoști clasificarea din RFC 3986.
- Caractere nerezervate:
A-Z, a-z, 0-9, -, _, . și ~. Sunt sigure în mod inerent. Codificatoarele le lasă neschimbate.
- Caractere rezervate:
! * ' ( ) ; : @ & = + $ , / ? # [ ]. Ele sunt „sintaxa” internetului. De exemplu, & separă variabilele. Dacă datele conțin un ampersand (de exemplu „M&M Candy”), trebuie codificat ca %26, ca serverul să nu taie valoarea în două.
De ce spațiul poate fi și %20, și plus (+)
Răspuns rapid: Istoric, spațiile din datele de formular erau codificate ca plus (+), iar spațiile din URL-uri standard ca %20. API-urile JavaScript moderne standardizează %20, ca să evite confuzia și să asigure compatibilitatea.
O confuzie frecventă este de ce spațiul este uneori %20 și uneori simbolul +.
Vine din arhitectura veche a internetului. Specificația application/x-www-form-urlencoded (folosită la trimiterea formularelor HTML) cerea ca spațiile să devină plus, ca să economisească bandă.
În căile URL standard și în query-urile API moderne, spațiul trebuie codificat strict ca %20. Utiliome urmează specificația modernă encodeURIComponent() și convertește spațiile în %20, ca să evite erorile de decodificare în API-uri REST.