URL

Normalisert

Hva er URL-normalisereren?

To URL-er som er "samme", men som ved sammenligning blir ulike på grunn av store/små bokstaver eller spørringsrekkefølge, er en av de feilene som spiser opp en halv ettermiddag. HTTPS://Example.com/page og https://example.com/page peker på samme ressurs, men en strengsammenligning sier at de er forskjellige. Normalisereren tar en URL og produserer dens kanoniske form etter RFC 3986 §6 og WHATWG URL Standard, slik at to URL-er som betyr det samme gir den samme strengen.

Normaliseringene er de kjedelige-men-viktige: små bokstaver i skjema og vert (etter RFC 3986 §6.2.2.1 er de skift-uavhengige), fjern standardporter (:443 på https, :80 på http), dekod prosentkodede ikke-reserverte tegn (%41 → A), sorter spørringsparametere alfabetisk på nøkkel, fjern tomt fragment (# uten noe bak) og løs ./..-stisegmenter. Utdata-JSON inneholder den normaliserte URL-en, originalen og en changes-array som lister opp nøyaktig hva som ble skrevet om — slik at du ser hvorfor to URL-er som så forskjellige ut faktisk er like.

Alt kjører i nettleseren din ved hjelp av standard-URL-APIet og URLSearchParams — ingen server, ingen logging. Hvis inndataen din allerede er kanonisk, er changes-arrayen tom, og det er svaret: ingenting å gjøre. Nyttig som rask sjekk før du publiserer et sitemap eller setter <link rel="canonical">.

Slik bruker du URL-normalisereren

Tre trinn. Hvert trinn tilsvarer en knapp på denne siden.

Lim inn en URL eller last inn eksemplet

Slipp en URL i venstre panel. Klikk på Eksempel for å laste inn en realistisk rotete URL — skjema og vert i store bokstaver, standardport, rotete spørringsrekkefølge, prosentkodet mellomrom, tomt fragment. Eksempel-URL:

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

Internasjonaliserte domenenavn (IDN) konverteres til Punycode av URL-konstruktøren — det er formen som faktisk sendes over nettet, etter reglene for URI-normalisering. Userinfo (user:pass@host) bevares hvis det finnes.

Les utdataen

Høyre panel viser JSON med tre felt: normalized (den kanoniske URL-en), original (det du limte inn, trimmet) og changes — en array av { rule, from, to }-oppføringer som lister hver omskriving. Hvis changes er tom, var URL-en allerede kanonisk.

Kopier eller last ned

Klikk på Kopier for å sende JSON til utklippstavlen, eller Last ned for å lagre den som en .json-fil. Minifiser komprimerer JSON til én linje. Bruk Tøm i inndatapanelet for å starte på nytt.

Når du faktisk kommer til å bruke dette

Cache-nøkler og dedup i analytics

Analytics-dashbordet ditt ser Example.com/page og example.com/page som to forskjellige rader. CDN-cachen din også. Normaliser ved inngangen, og duplikatet forsvinner. Samme triks hvis du bygger en URL-forkorter eller en bokmerke-dedup — lagre den normaliserte formen som oppslagsnøkkel.

Kanoniske URL-er for SEO

Søkemotorer straffer duplisert innhold når samme side er tilgjengelig på flere URL-er. <link rel="canonical">-taggen og URL-ene i sitemap.xml bør matche én normalisert form. Googles canonicalization-veiledning staver ut reglene; dette verktøyet er den raskeste måten å anvende dem manuelt på.

Sammenligne to URL-er for likhet

Du skriver en redirect-loop-detektor eller tester en webhook. To URL-er er "samme" hvis de normaliserte formene matcher. Sammenlign strenger etter normalisering — ikke lag din egen likhetsfunksjon basert på URL.toString(), for den verken sorterer spørringsparametere eller fjerner standardporter.

Rens URL-er før lagring eller visning

En bruker limer inn HTTPS://www.SHOP.com:443/cart/?b=2&a=1# i skjemaet ditt. Det vil du ikke ha lagret slik i databasen, og definitivt ikke sende tilbake på e-post. Normaliser først, lagre så den rene formen. URL-er kunden ser blir forutsigbare.

Vanlige spørsmål

Hva om URL-en min allerede er kanonisk?

Du ser samme URL i normalized som i original, og changes-arrayen blir tom ("changes": []). Det er svaret — det var ingenting å skrive om. Siden kaster ikke unntak og viser ingen feil i det tilfellet.

Rører den stien utover å fjerne avsluttende skråstrek fra roten?

Stort sett ikke. .- og ..-stisegmenter løses (URL-konstruktøren gjør det automatisk — RFC 3986 §5.2.4 kaller det "remove dot segments"). Avsluttende skråstreker fjernes bare når stien er bare /; /v1/orders/ forblir /v1/orders/ fordi RFC 3986 sier at avsluttende skråstreker kan være signifikante. Server-rammeverk kan behandle dem som forskjellige ruter.

Hvorfor sorteres spørringsparametrene mine? Rekkefølgen var viktig.

I RFC 3986 er spørringsrekkefølgen ikke semantisk signifikant — ?a=1&b=2 og ?b=2&a=1 er ekvivalente på URL-nivå. Alfabetisk sortering gir en stabil kanonisk form slik at to ekvivalente URL-er matcher byte-for-byte. Hvis applikasjonen din faktisk avhenger av parameter-rekkefølgen (den burde ikke, men legacy-systemer gjør det), bryter denne normalisereren den antagelsen — ikke normaliser URL-er som går inn i en server som bryr seg om rekkefølgen.

Hvorfor blir %20 noen ganger til + etter normalisering?

Både %20 og + betyr et mellomrom inne i en spørringsstreng (etter reglene for application/x-www-form-urlencoded, som URLSearchParams bruker for serialisering). Når URLSearchParams-objektet reserialiserer spørringen, bruker det +. De er semantisk identiske for enhver standardkompatibel URL-parser; hvis serveren din behandler dem forskjellig, er det en bug i serveren.

Hva skjer med internasjonaliserte domener som café.example?

URL-konstruktøren konverterer verten til Punycode — caf%C3%A9.example blir xn--caf-dma.example. Det er formen URL-en faktisk ville bli sendt i over DNS, og det er det RFC 3987 / WHATWG-spesifikasjonen spesifiserer. Wikipedias artikkel om URI-normalisering går gjennom IDN-håndteringen hvis du vil ha detaljene.

Er det trygt for URL-er med legitimasjon (user:pass@host)?

Parsing skjer fullstendig i nettleseren din — ingenting sendes noe sted. Userinfo bevares gjennom normaliseringen. Om du i det hele tatt bør sende legitimasjon i en URL er et annet spørsmål — de fleste nettlesere og HTTP-klienter fjerner i dag userinfo eller advarer om det på grunn av sikkerhetsrisikoen, og en Authorization-header er som regel mye bedre.

Fjerner den dupliserte spørringsparametere?

Nei. ?tag=red&tag=red forblir ?tag=red&tag=red. Gjentatte nøkler kan ha betydning (noen API-er bruker dem for arrays), og å fjerne duplikater ville endre semantikken. Sorteringen er stabil, så innenfor samme nøkkel bevares den opprinnelige rekkefølgen.

Andre URL- og JSON-verktøy

Normalisering er én operasjon. Her er det som naturlig hører sammen med det: