Decodifica URL

Che cosa fa un decodificatore di URL

Un URL codificato è illeggibile apposta: i caratteri che confonderebbero un parser sono stati sostituiti da sequenze %, e tutto quello che sta fuori dall’ASCII è diventato i suoi byte UTF-8. Un decodificatore annulla entrambi i passaggi, così https%3A%2F%2Fexample.com%2Fcaff%C3%A8 ridiventa https://example.com/caffè e si vede a cosa puntava davvero il link.

Conta soprattutto quando l’URL ne trasporta un altro. Parametri di redirect, callback OAuth, wrapper di tracciamento e flussi di consenso annidano un indirizzo dentro l’altro, a volte due volte, e l’unico modo di sapere dove porta un link è decodificarlo. Farlo in una pagina che gira sulla tua macchina è meglio che incollare una callback firmata nel server di uno sconosciuto.

Come si usa

• Incolla tutto l’URL oppure solo il pezzo che ti interessa. Funzionano entrambi: al decodificatore non serve un URL valido, serve una stringa.
• Leggi la tabella dei parametri quando c’è una query string, ogni parametro compare con il valore già decodificato. Di solito è la risposta per cui eri venuto.
• Scegli la modalità la modalità form legge il + come spazio: giusta per il corpo di un form inviato, sbagliata per tutto il resto.
• Decodifica due volte quando serve se il risultato contiene ancora sequenze %XX era codificato due volte. Rimandalo su e decodifica ancora.
• Rimanda su sposta il risultato nell’input: è così che si sbuccia un URL annidato uno strato alla volta.

I casi difficili

Una sequenza malformata ferma tutta la decodifica, ed è corretto più che scomodo. %zz non è un byte, e un decodificatore che lo saltasse restituirebbe una stringa silenziosamente diversa dall’originale. Lo strumento nomina invece la sequenza che si è rotta, e di solito basta per riconoscere dietro di essa un copia-incolla troncato.

Un % isolato è la versione più comune di quel problema. «sconto 100%» incollato in un campo URL non è codifica valida: il parser legge «% s» come una sequenza, non trova cifre esadecimali e si arrende. Si risolve codificando prima il valore: un segno di percentuale letterale è %25.

E una stringa decodificata non è una stringa sicura. Decodificando, %3Cscript%3E ridiventa un tag script: si annulla una codifica, non si sanifica niente. Quello che farai dopo con il risultato ha bisogno del suo escape, adatto a dove andrà a finire.

Quando l’uscita sembra sbagliata

• Il risultato contiene ancora %20 l’input era codificato due volte. Decodifica di nuovo: ogni passaggio toglie uno strato.
• Gli accenti escono come caratteri strani le sequenze sono byte Latin-1, non UTF-8. Un vecchio sistema ha codificato la è come %E8 invece di %C3%A8, e non c’è modo di leggerla come UTF-8.
• I più sono diventati spazi sei in modalità form su una stringa che non è il corpo di un form. Cambia modalità: conta per i valori base64, che contengono + legittimamente.
• Un errore di sequenza incompleta un % non seguito da due cifre esadecimali: di solito un segno di percentuale letterale mai codificato, o un URL tagliato nel copia-incolla.
• Manca un parametro controlla se sta dopo il #. Il frammento non fa parte della query string e al server non arriva mai.

Come si chiamano i pezzi di un URL

• Query string tutto quello che segue il ?, come coppie nome=valore unite da &. L’ordine non è significativo e i nomi ripetuti sono ammessi, ed è per questo che i server non sono d’accordo su cosa voglia dire ?a=1&a=2.
• Frammento tutto quello che segue il #. Resta nel browser: non viene mai inviato al server, quindi non compare in nessun log.
• Segmento di percorso le parti tra le barre. Una / dentro un valore va codificata, altrimenti diventa un segmento nuovo.
• Sequenza percentuale il % più due cifre esadecimali. Non distingue maiuscole e minuscole, quindi %C3%A8 e %c3%a8 si decodificano uguale.
• Parametri UTM utm_source, utm_medium, utm_campaign e compagnia: normalissimi parametri di query che gli strumenti di analytics si accordano a leggere. Per l’URL in sé non hanno nulla di speciale.