Decodificare una URL

Non esiste nessuna regola che la risolva guardando solo la stringa. `application/x-www-form-urlencoded` — cioè quello che invia un modulo HTML, e quello che in pratica sono quasi tutte le query string — scrive uno spazio come `+`. La codifica percentuale in sé quella regola non ce l’ha, quindi in un percorso `+` è semplicemente un più.

Così gli stessi caratteri si decodificano in due modi a seconda di dove sono stati presi, e questo lo sai solo tu. Per una query string «spazio» è quasi sempre la scelta giusta; per un percorso, o per un valore che può legittimamente contenere un più — un numero di telefono in formato internazionale, una ricerca su `C++` — non lo è.

Decodificare non è una tabella che traduce `%41` in `A`. Ogni sequenza nomina un byte, e i byte insieme formano caratteri UTF-8: `%C3%A0` è una `à` sola costruita con due sequenze, e un emoji ne richiede quattro. Un decodificatore che lavori sequenza per sequenza produce due caratteri sbagliati dove ne serviva uno.

È anche il motivo per cui una sequenza incompleta non si può semplicemente saltare. `%E0%A4` sono i primi due byte di un carattere che ne vuole tre; non c’è nessuna uscita corretta, solo un’ipotesi. Qui viene segnalata come malformata invece di essere indovinata, che è la differenza fra sapere che l’input era troncato e credere tranquillamente a una risposta sbagliata.

Se il risultato contiene ancora delle sequenze percentuali, la stringa era stata codificata due volte e ne hai tolto uno strato. La firma è `%2520`: è `%20` il cui `%` era stato a sua volta codificato come `%25`. Decodificando una volta ottieni `%20`, decodificando di nuovo ottieni lo spazio.

Vale la pena notarlo invece di decodificare due volte per abitudine, perché la doppia codifica è un difetto a monte — di solito un framework che protegge un valore e un template che lo riprotegge. Il sintomo che vede una persona è un `Ciao%20mondo` nel titolo di una pagina, e a quel punto è già a due o tre sistemi di distanza da dove è nato.

Un indirizzo decodificato non è più utilizzabile come indirizzo, e non è un dettaglio estetico. Se il valore di un parametro conteneva una `&` protetta come `%26`, dopo la decodifica quella `&` separa due parametri: la URL è diversa, e la differenza la nota solo chi la riusa.

Per questo la decodifica è un passo di lettura e non un passo di trasformazione. Se ti serve capire cosa c’è dentro una URL, decodifica e leggi; se ti serve la URL, tieni quella originale. Rimetterla insieme ricodificando pezzo per pezzo si può fare, ma è un lavoro diverso e la pagina di analisi delle URL è il posto migliore per cominciarlo.

Tutto quello che segue il `#` non viene inviato in nessuna richiesta HTTP, quindi in un log di accesso non lo troverai mai. Se stai decodificando la riga di un log e ti aspettavi un frammento, non è stato tolto da qualcuno: non è mai partito.

La conseguenza si vede al contrario quando si legge una URL copiata dalla barra degli indirizzi, dove il frammento invece c’è. Due stringhe che descrivono la stessa pagina possono quindi essere diverse a seconda della loro provenienza, e sapere quale delle due si ha in mano evita mezz’ora di confronti su una differenza che non è mai stata una differenza.

Una URL presa da un log porta con sé molto più della pagina visitata: termini di ricerca, identificatori di sessione, a volte un indirizzo email in un parametro di login e, con una frequenza che non dovrebbe esistere, un token in chiaro. I parametri sono la parte di una URL in cui finisce quello che nessuno aveva deciso di far finire lì.

Da qui discende la regola pratica: le URL nei log vanno trattate come dati personali, non come metadati tecnici. Ed è anche il motivo per cui i token non vanno mai messi in una query string — finiscono nei log del server, in quelli del proxy, nell’intestazione `Referer` verso terzi e negli export di statistiche, cioè in quattro posti che nessuno ripulisce.

`utm_source`, `utm_medium`, `utm_campaign` e i loro fratelli sono etichette per l’analisi del traffico, non identificatori: dicono da quale campagna arriva la visita, non chi sei. Sono la cosa che si trova più spesso decodificando una URL, e sono anche la meno interessante.

I parametri che meritano attenzione sono altri e si riconoscono dalla forma: una stringa lunga e casuale in un parametro chiamato `id`, `token`, `sid` o `ref` è quasi sempre un identificatore di persona o di sessione. Distinguere le due famiglie a colpo d’occhio è l’abilità utile quando si guarda un log, e la decodifica serve proprio a rendere leggibile la differenza.

La pagina non visita l’indirizzo, non fa nessuna richiesta verso il dominio che compare nella stringa e non ne mostra un’anteprima. È una decisione, non una funzione mancante: una richiesta automatica verso una URL presa da un log farebbe arrivare a un terzo il fatto che quella riga è stata guardata, e con essa tutti i parametri.

C’è anche un motivo più banale: le URL che si decodificano sono spesso destinazioni di redirect, link di reimpostazione password e chiamate di webhook. Aprirne una può consumare un token a uso singolo o innescare un’azione. Uno strumento che mostra il testo e basta è l’unico che non possa far succedere niente.

Se una URL contiene un identificatore di sessione o un indirizzo email, è un dato personale a tutti gli effetti, e passarla a un servizio online per leggerla sarebbe una comunicazione a un terzo con tutto quello che comporta. Qui la decodifica è aritmetica fatta nella scheda, quindi quella comunicazione non avviene.

È anche la ragione per cui non c’è nessuna cronologia delle stringhe decodificate. Sarebbe utile una volta su venti e vorrebbe dire conservare proprio il materiale che è meglio non conservare: chiudere la scheda cancella tutto perché non c’è nient’altro da cancellare.