URL

Normaliseret

Hvad er URL-normalisatoren?

To URL'er der er "ens", men i en sammenligning bliver ulige på grund af store/små bogstaver eller query-rækkefølge er én af de bugs der koster en halv eftermiddag. HTTPS://Example.com/page og https://example.com/page peger på samme ressource, men en strengsammenligning siger de er forskellige. Normalisatoren tager en URL og producerer dens kanoniske form efter RFC 3986 §6 og WHATWG URL Standard, så to URL'er der betyder det samme giver den samme streng.

Normaliseringerne er de kedelige-men-vigtige: små bogstaver i schema og host (efter RFC 3986 §6.2.2.1 er de skiftuafhængige), fjern standardporte (:443 på https, :80 på http), afkod procentkodede ikke-reserverede tegn (%41 → A), sortér query-parametre alfabetisk på nøgle, fjern tomt fragment (# uden noget bagved) og fold ./..-stisegmenter sammen. Output-JSON inkluderer den normaliserede URL, originalen og et changes-array, der lister præcis hvad der blev omskrevet — så du kan se hvorfor to URL'er der så forskellige ud i virkeligheden er ens.

Alt kører i din browser via standard-URL-API'et og URLSearchParams — ingen server, ingen logning. Hvis dit input allerede er kanonisk, er changes-arrayet tomt og det er svaret: intet at gøre. Nyttigt som sanity-tjek inden du udgiver et sitemap eller sætter <link rel="canonical">.

Sådan bruger du URL-normalisatoren

Tre trin. Hvert trin svarer til en knap på denne side.

Indsæt en URL eller indlæs eksemplet

Drop en URL i venstre panel. Klik på Eksempel for at indlæse en realistisk rodet URL — schema og host med store bogstaver, standardport, blandet query-rækkefølge, procentkodet mellemrum, tomt fragment. Eksempel-URL:

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

Internationaliserede domænenavne (IDN) konverteres til Punycode af URL-konstruktoren — det er den form der faktisk sendes over nettet, efter reglerne for URI-normalisering. Userinfo (user:pass@host) bevares hvis det findes.

Læs outputtet

Højre panel viser JSON med tre felter: normalized (den kanoniske URL), original (det du indsatte, trimmet) og changes — et array af { rule, from, to }-poster der lister hver omskrivning. Er changes tomt, var URL'en allerede kanonisk.

Kopiér eller download

Klik på Kopiér for at sende JSON til udklipsholderen, eller Download for at gemme det som .json-fil. Minificer presser JSON ned på én linje. Brug Ryd i input-panelet for at starte forfra.

Hvornår du faktisk kommer til at bruge dette

Cache-nøgler og dedup i analytics

Dit analytics-dashboard ser Example.com/page og example.com/page som to forskellige rækker. Det gør dit CDN-cache også. Normalisér ved indgangen, og duplikatet forsvinder. Samme trick hvis du bygger en URL-shortener eller en bogmærke-dedup — gem den normaliserede form som opslagsnøgle.

Kanoniske URL'er for SEO

Søgemaskiner straffer dubleret indhold når den samme side er tilgængelig på flere URL'er. Dit <link rel="canonical">-tag og URL'erne i din sitemap.xml bør matche én normaliseret form. Googles canonicalization-vejledning beskriver reglerne; dette værktøj er den hurtigste måde at anvende dem manuelt.

Sammenligne to URL'er for lighed

Du skriver en redirect-loop-detektor eller tester en webhook. To URL'er er "ens", hvis deres normaliserede former matcher. Sammenlign strenge efter normalisering — opfind ikke din egen lighedsfunktion baseret på URL.toString(), for den hverken sorterer query-parametre eller fjerner standardporte.

Rens URL'er før lagring eller visning

En bruger indsætter HTTPS://www.SHOP.com:443/cart/?b=2&a=1# i din formular. Det vil du ikke have liggende sådan i databasen, og slet ikke maile tilbage. Normalisér først, gem så den rene form. Kundevendte URL'er bliver forudsigelige.

Almindelige spørgsmål

Hvad hvis min URL allerede er kanonisk?

Du ser den samme URL i normalized som i original, og changes-arrayet bliver tomt ("changes": []). Det er svaret — der var intet at omskrive. Siden kaster ingen exception og viser ingen fejl i det tilfælde.

Rører den ved stien ud over at fjerne efterstillede skråstreger fra roden?

Stort set ikke. .- og ..-stisegmenter løses (URL-konstruktoren gør det automatisk — RFC 3986 §5.2.4 kalder det "remove dot segments"). Efterstillede skråstreger fjernes kun, når stien blot er /; /v1/orders/ forbliver /v1/orders/, fordi RFC 3986 siger, at efterstillede skråstreger kan være signifikante. Server-frameworks behandler dem nogle gange som forskellige ruter.

Hvorfor sorteres mine query-parametre? Rækkefølgen var vigtig.

I RFC 3986 er query-rækkefølgen ikke semantisk signifikant — ?a=1&b=2 og ?b=2&a=1 er ækvivalente på URL-niveau. Alfabetisk sortering giver en stabil kanonisk form, så to ækvivalente URL'er matcher byte-for-byte. Hvis din applikation faktisk afhænger af parameter-rækkefølgen (det burde den ikke, men legacy-systemer gør det), bryder denne normalisator den antagelse — normalisér ikke URL'er, der sendes til en server, der bekymrer sig om rækkefølgen.

Hvorfor bliver %20 nogle gange til + efter normalisering?

Både %20 og + betyder et mellemrum inde i en query-streng (efter reglerne for application/x-www-form-urlencoded, som URLSearchParams bruger til serialisering). Når URLSearchParams-objektet reserialiserer query, bruger det +. De er semantisk identiske for enhver standardkompatibel URL-parser; behandler din server dem forskelligt, er det en bug i serveren.

Hvad sker der med internationaliserede domæner som café.example?

URL-konstruktoren konverterer host til Punycode — caf%C3%A9.example bliver til xn--caf-dma.example. Det er den form URL'en faktisk ville blive sendt i over DNS, og det er det RFC 3987 / WHATWG-specifikationen specificerer. Wikipedias artikel om URI-normalisering gennemgår IDN-håndteringen, hvis du vil have detaljerne.

Er det sikkert til URL'er med legitimationsoplysninger (user:pass@host)?

Parsningen sker fuldstændig i din browser — intet sendes nogen steder hen. Userinfo bevares gennem normaliseringen. Om du overhovedet bør sende legitimationsoplysninger i en URL er en anden sag — de fleste browsere og HTTP-klienter fjerner i dag userinfo eller advarer om det på grund af sikkerhedsrisici, og man har som regel mere ud af en Authorization-header.

Fjerner den dublerede query-parametre?

Nej. ?tag=red&tag=red forbliver ?tag=red&tag=red. Gentagne nøgler kan have betydning (nogle API'er bruger dem til arrays), og at fjerne dubletter ville ændre semantikken. Sorteringen er stabil, så inden for samme nøgle bevares den oprindelige rækkefølge.

Andre URL- og JSON-værktøjer

Normalisering er én operation. Her er hvad der naturligt går hånd i hånd med det: