URL

Normalizzata

Cos'è il Normalizzatore URL?

Due URL che sono "la stessa" ma che, confrontate, risultano diverse per maiuscole/minuscole o ordine della query è uno di quei bug che ti porta via mezzo pomeriggio. HTTPS://Example.com/page e https://example.com/page puntano alla stessa risorsa, ma un confronto di stringhe dice che sono diverse. Il normalizzatore prende una URL e produce la sua forma canonica secondo la RFC 3986 §6 e il WHATWG URL Standard, così due URL che significano la stessa cosa producono la stessa stringa.

Le normalizzazioni sono le noiose-ma-importanti: schema e host in minuscolo (per la RFC 3986 §6.2.2.1 sono case-insensitive), rimozione delle porte predefinite (:443 su https, :80 su http), decodifica dei caratteri non riservati codificati in percentuale (%41 → A), ordinamento alfabetico dei parametri di query per chiave, eliminazione del fragment vuoto (# senza nulla dopo) e risoluzione dei segmenti di path . / ... Il JSON in output include la URL normalizzata, l'originale e un array changes che elenca esattamente cosa è stato riscritto — così vedi perché due URL apparentemente diverse sono in realtà la stessa.

Tutto gira nel tuo browser usando le API URL standard e URLSearchParams — niente server, niente log. Se l'input è già canonico, l'array changes è vuoto e quella è la risposta: niente da fare. Comodo come controllo prima di pubblicare una sitemap o di impostare <link rel="canonical">.

Come usare il Normalizzatore URL

Tre passaggi. Ognuno corrisponde a un pulsante in questa pagina.

Incolla una URL o carica l'esempio

Butta una URL nel pannello di sinistra. Clicca Esempio per caricare una URL realisticamente sporca — schema e host in maiuscolo, porta predefinita, ordine della query mescolato, spazio percent-encoded, fragment vuoto. URL di esempio:

HTTPS://API.Shop.Example.com:443/v1/orders/?status=active&customer=Ava%20Chen&page=2#

I nomi di dominio internazionalizzati (IDN) vengono convertiti in Punycode dal costruttore URL — è la forma che viaggia davvero sulla rete, in base alle regole di normalizzazione degli URI. La parte userinfo (user:pass@host) viene preservata se presente.

Leggi l'output

Il pannello di destra mostra JSON con tre campi: normalized (la URL canonica), original (quello che hai incollato, ripulito) e changes — un array di voci { rule, from, to } con ogni riscrittura. Se changes è vuoto, la URL era già canonica.

Copia o scarica

Clicca Copia per mandare il JSON negli appunti, o Scarica per salvarlo come file .json. Minifica compatta il JSON in una riga. Usa Pulisci sul pannello di input per ricominciare.

Quando lo userai davvero

Chiavi di cache e dedup analytics

La tua dashboard analytics vede Example.com/page e example.com/page come due righe diverse. Anche la cache del CDN. Normalizza in ingresso e il duplicato sparisce. Stesso trucco se stai costruendo un URL shortener o un dedup di bookmark — salva la forma normalizzata come chiave di lookup.

URL canoniche per la SEO

I motori di ricerca penalizzano contenuti duplicati quando la stessa pagina è raggiungibile da più URL. Il tuo tag <link rel="canonical"> e le URL della tua sitemap.xml devono corrispondere a una singola forma normalizzata. La guida alla canonicalizzazione di Google illustra le regole; questo strumento è il modo più veloce per applicarle a mano.

Confrontare due URL per uguaglianza

Stai scrivendo un rilevatore di redirect-loop o stai testando un webhook. Due URL sono "uguali" se le loro forme normalizzate coincidono. Confronta le stringhe dopo aver normalizzato — non improvvisare una funzione di uguaglianza basata su URL.toString(), perché non ordina i parametri di query e non rimuove le porte predefinite.

Pulire URL prima di salvarle o mostrarle

Un utente incolla HTTPS://www.SHOP.com:443/cart/?b=2&a=1# nel tuo form. Non vuoi salvarla così nel database, e di sicuro non vuoi rimandargliela via email. Normalizza prima, poi salva la forma pulita. Le URL viste dai clienti diventano prevedibili.

Domande frequenti

E se la mia URL è già canonica?

Vedrai la stessa URL in normalized e in original e l'array changes sarà vuoto ("changes": []). Quella è la risposta — non c'era niente da riscrivere. La pagina non lancia eccezioni né mostra errori in quel caso.

Tocca il path oltre alla rimozione dello slash finale dalla root?

Quasi mai. I segmenti di path . e .. vengono risolti (lo fa il costruttore URL automaticamente — la RFC 3986 §5.2.4 chiama questa operazione "remove dot segments"). Gli slash finali vengono rimossi solo quando il path è solo /; /v1/orders/ rimane /v1/orders/ perché la RFC 3986 dice che gli slash finali possono essere significativi. Alcuni framework server li trattano come route diverse.

Perché i miei parametri di query vengono ordinati? L'ordine mi serviva.

Nella RFC 3986 l'ordine della query non è semanticamente significativo — ?a=1&b=2 e ?b=2&a=1 sono equivalenti a livello di URL. Ordinare alfabeticamente dà una forma canonica stabile, così due URL equivalenti corrispondono byte per byte. Se la tua applicazione dipende davvero dall'ordine dei parametri (non dovrebbe, ma i sistemi legacy lo fanno), questo normalizzatore romperà quell'ipotesi — non normalizzare URL che vanno a un server a cui interessa l'ordine.

Perché %20 a volte diventa + dopo la normalizzazione?

Sia %20 sia + significano uno spazio dentro una query string (per le regole di application/x-www-form-urlencoded, che è ciò che URLSearchParams usa per serializzare). Quando l'oggetto URLSearchParams ri-serializza la query, usa +. Sono semanticamente identici per qualunque parser URL conforme agli standard; se il tuo server li tratta diversamente, è un bug del server.

Cosa succede ai domini internazionalizzati come café.example?

Il costruttore URL converte l'host in Punycode — caf%C3%A9.example diventa xn--caf-dma.example. È la forma con cui la URL verrebbe effettivamente inviata via DNS, ed è quanto specificano la RFC 3987 / la spec WHATWG. La voce di Wikipedia sulla normalizzazione URI spiega in dettaglio la gestione degli IDN.

È sicuro con URL contenenti credenziali (user:pass@host)?

Il parsing avviene interamente nel tuo browser — nulla viene mandato da nessuna parte. Userinfo viene preservato durante la normalizzazione. Se sia opportuno passare credenziali in una URL è un altro discorso — la maggior parte dei browser e dei client HTTP oggi rimuove o segnala userinfo per i rischi di sicurezza, e di solito è meglio un header Authorization.

Rimuove parametri di query duplicati?

No. ?tag=red&tag=red rimane ?tag=red&tag=red. Le chiavi ripetute possono essere significative (alcune API le usano per gli array) e rimuovere i duplicati cambierebbe la semantica. L'ordinamento è stabile, quindi all'interno della stessa chiave l'ordine originale viene preservato.

Altri strumenti URL e JSON

Normalizzare è un'operazione. Ecco cosa ci sta naturalmente vicino: