URL

Normaliserad

Vad är URL-normaliseraren?

Två URL:er som är "samma" men vid jämförelse blir olika på grund av versaler eller query-ordning är en av de buggar som äter upp en hel eftermiddag. HTTPS://Example.com/page och https://example.com/page pekar på samma resurs, men en strängjämförelse säger att de skiljer sig. Normaliseraren tar en URL och producerar dess kanoniska form enligt RFC 3986 §6 och WHATWG URL Standard, så att två URL:er som betyder samma sak ger samma sträng.

Normaliseringarna är de tråkiga-men-viktiga: gemener på schema och värd (enligt RFC 3986 §6.2.2.1 är de skiftlägesoberoende), ta bort standardportar (:443 på https, :80 på http), avkoda procentkodade icke-reserverade tecken (%41 → A), sortera query-parametrar alfabetiskt på nyckel, ta bort tomt fragment (# utan något efter) och lösa ./..-sökvägssegment. Utdata-JSON innehåller den normaliserade URL:en, originalet och en changes-array som listar exakt vad som skrivits om — så du ser varför två URL:er som såg olika ut faktiskt är samma.

Allt körs i din webbläsare via standard-URL-API:t och URLSearchParams — ingen server, ingen loggning. Är din indata redan kanonisk är changes-arrayen tom och det är svaret: inget att göra. Användbart som sanity-check innan du publicerar en sitemap eller sätter <link rel="canonical">.

Så använder du URL-normaliseraren

Tre steg. Varje steg motsvarar en knapp på den här sidan.

Klistra in en URL eller ladda exemplet

Släpp en URL i vänsterpanelen. Klicka på Exempel för att läsa in en realistiskt rörig URL — schema och värd med versaler, standardport, blandad query-ordning, procentkodat blanksteg, tomt fragment. Exempel-URL:

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

Internationaliserade domännamn (IDN) konverteras till Punycode av URL-konstruktorn — det är formen som faktiskt skickas över nätet, enligt reglerna för URI-normalisering. Userinfo (user:pass@host) bevaras om det finns.

Läs utdatan

Högerpanelen visar JSON med tre fält: normalized (den kanoniska URL:en), original (det du klistrade in, trimmat) och changes — en array av { rule, from, to }-poster som listar varje omskrivning. Är changes tom var URL:en redan kanonisk.

Kopiera eller ladda ner

Klicka på Kopiera för att skicka JSON till urklipp, eller Ladda ner för att spara som .json-fil. Minifiera packar ihop JSON på en rad. Använd Rensa i indatapanelen för att börja om.

När du faktiskt kommer använda detta

Cache-nycklar och dedup i analytics

Din analytics-dashboard ser Example.com/page och example.com/page som två olika rader. Din CDN-cache likaså. Normalisera vid ingången och duplikatet försvinner. Samma trick om du bygger en URL-förkortare eller bokmärks-dedup — lagra den normaliserade formen som uppslagsnyckel.

Kanoniska URL:er för SEO

Sökmotorer straffar duplicerat innehåll när samma sida nås via flera URL:er. Din <link rel="canonical">-tagg och URL:erna i din sitemap.xml bör matcha en enda normaliserad form. Googles canonicalization-vägledning beskriver reglerna; det här verktyget är snabbaste sättet att tillämpa dem för hand.

Jämföra två URL:er på likhet

Du skriver en redirect-loop-detektor eller testar en webhook. Två URL:er är "samma" om deras normaliserade former matchar. Jämför strängar efter normalisering — bygg inte en egen likhetsfunktion på URL.toString(), för den sorterar varken query-parametrar eller tar bort standardportar.

Städa URL:er före lagring eller visning

En användare klistrar HTTPS://www.SHOP.com:443/cart/?b=2&a=1# i ditt formulär. Det vill du inte spara i databasen, och definitivt inte mejla tillbaka. Normalisera först, spara den rena formen sedan. Kund-vända URL:er blir förutsägbara.

Vanliga frågor

Vad händer om min URL redan är kanonisk?

Du ser samma URL i normalized som i original och changes-arrayen blir tom ("changes": []). Det är svaret — inget behövde skrivas om. Sidan kastar inget undantag och visar inget fel i det fallet.

Rör den sökvägen utöver att ta bort efterföljande snedstreck från roten?

Mest inte. .- och ..-sökvägssegment löses (URL-konstruktorn gör det automatiskt — RFC 3986 §5.2.4 kallar det "remove dot segments"). Efterföljande snedstreck tas bara bort när sökvägen är just /; /v1/orders/ förblir /v1/orders/ eftersom RFC 3986 säger att efterföljande snedstreck kan vara signifikanta. Server-ramverk kan behandla dem som olika rutter.

Varför sorteras mina query-parametrar? Ordningen var viktig.

I RFC 3986 är query-ordning inte semantiskt signifikant — ?a=1&b=2 och ?b=2&a=1 är ekvivalenta på URL-nivå. Att sortera alfabetiskt ger en stabil kanonisk form så att två ekvivalenta URL:er matchar byte-för-byte. Om din applikation faktiskt beror på parameterordning (det borde den inte, men legacy-system gör det), bryter den här normaliseraren det antagandet — normalisera inte URL:er som matas in i en server som bryr sig om ordning.

Varför blir %20 ibland + efter normalisering?

Både %20 och + betyder ett blanksteg inuti en query-sträng (enligt reglerna för application/x-www-form-urlencoded, som URLSearchParams använder vid serialisering). När URLSearchParams-objektet återserialiserar query använder det +. De är semantiskt identiska för varje standardkompatibel URL-parser; behandlar din server dem olika är det en bugg i servern.

Vad händer med internationaliserade domäner som café.example?

URL-konstruktorn konverterar värden till Punycode — caf%C3%A9.example blir xn--caf-dma.example. Det är formen URL:en faktiskt skulle skickas i över DNS, och det är vad RFC 3987 / WHATWG-specen anger. Wikipedias artikel om URI-normalisering går igenom IDN-hanteringen om du vill ha detaljerna.

Är det säkert för URL:er med inloggningsuppgifter (user:pass@host)?

Parsningen sker helt i din webbläsare — inget skickas någonstans. Userinfo bevaras genom normaliseringen. Om du över huvud taget bör skicka inloggningsuppgifter i en URL är en annan fråga — de flesta webbläsare och HTTP-klienter tar idag bort eller varnar för userinfo på grund av säkerhetsrisker, och en Authorization-header är generellt mycket bättre.

Tar den bort dubbletter av query-parametrar?

Nej. ?tag=red&tag=red förblir ?tag=red&tag=red. Upprepade nycklar kan vara meningsfulla (vissa API:er använder dem för arrayer) och att ta bort dubbletter skulle ändra semantiken. Sorteringen är stabil, så inom samma nyckel bevaras den ursprungliga ordningen.

Andra URL- och JSON-verktyg

Normalisering är en operation. Här är vad som naturligt går ihop med det: