Lim inn den ødelagte URL-en her og klikk «Fiks URL!!» for å reparere denSkriv inn ødelagt URL

Hva er URL-fikseren?

Du har kopiert en lenke fra en e-post, et Word-dokument, en Slack-melding eller en Confluence-side — og nå har den krøllete anførselstegn rundt seg (" i stedet for "), en tankestrek (–) der det skulle vært en bindestrek, ingen https:// foran, eller et vill-farent linjeskift som har klippet URL-en i to. Lim den inn her og få en fungerende URL tilbake. URL-fikseren rydder opp i den syntaktiske skaden som copy-paste etterlater seg, etter reglene i WHATWG URL-standarden og RFC 3986.

Fikseren håndterer ting et regulært uttrykk måtte spesialhåndtere i evighet: typografiske anførselstegn, typografiske streker, utilsiktede doble skråstreker i stien, blandet eller dobbel prosentkoding (slik at %2520 blir %20 når det åpenbart er dobbeltkoding), ukodede mellomrom og CR/LF/tab-tegn som havnet inne i URL-en fordi noen trykket Enter på feil tidspunkt. Den finner ikke på et vertsnavn, endrer ikke spørringsparametrene dine, og legger ikke til et stisegment som ikke var der. Utdataene blir så validert mot reglene i nettleserens URL-API, så du vet at den faktisk vil bli parsed på den andre siden. Internasjonaliserte vertsnavn (Unicode, IDN) bevares i tråd med RFC 3987.

URL-en din går til backend så fikset kan kjøres, og kommer rett tilbake. Vi logger ikke input — URL-er bærer ofte sesjonstokens, kunde-ID-er eller andre ting du ikke har lyst til å la ligge i en loggfil. Hvis URL-en inneholder en ekte hemmelighet (en signert S3-lenke, et engangs-auth-token), så roter den etter at du har limt den inn et sted — også her.

Slik bruker du URL-fikseren

Tre steg. Hvert av dem tilsvarer en knapp på siden — ingenting er skjult.

Lim inn den ødelagte URL-en eller hent eksempelet

Slipp den ødelagte URL-en inn i editoren til venstre. Klikk Eksempel-URL for å hente et bevisst ødelagt eksempel med krøllete anførselstegn, en tankestrek, manglende skjema og et ukodet mellomrom — den typen ting du faktisk limer inn fra en e-post. Eksempel på en ødelagt URL:

"shop.example.com/orders/ORD–1001?customer=Ava Chen"

Krøllete anførselstegn fra et Word-dokument rundt URL-en, tankestrek inne i stisegmentet, ingen skjema, og et bokstavelig mellomrom i spørringsverdien. Fire forskjellige problemer på én kort linje.

Klikk Fiks URL!!

Trykk på den grønne Fiks URL!!-knappen. Fikseren tar bort anførselstegnene rundt, bytter ut tankestreken med en bindestrek, setter https:// foran og prosentkoder mellomrommet, slik at resultatet er i tråd med RFC 3986.

Kopier den fiksede URL-en

Høyre panel viser den oppryddede URL-en. Skum gjennom den, kopier den, lim den inn i nettleseren, i fetch()-kallet ditt, i README-en din eller i testen som feilet. Vil du se URL-en delt opp i komponenter, så send den videre gjennom URL-parseren vår.

Når du faktisk får bruk for dette

Lenker limt inn fra e-post eller Word

Outlook og Word gjør stille om rette anførselstegn til krøllete, og bindestreker til tankestreker. URL-en ser fin ut i meldingen og er ødelagt i samme øyeblikk du limer den inn i en terminal. Fikseren reverserer den «smarte» autokorreksen, slik at lenken virker igjen.

URL-er pakket inn i anførselstegn av en logger

JSON-formaterte applikasjonslogger elsker å skrive ut URL-er som "https://api.example.com/v1/orders?id=ORD-1001". Når du griper den til en kjapp curl, blir anførselstegnene med på lasset. Fikseren fjerner dem, og du slipper å lure på hvorfor skallet ditt klager på et uavsluttet anførselstegn.

Linjeskift midt i URL-en fra Slack eller Jira

Lange URL-er i Slack, Jira eller en Confluence-side blir ofte brutt og plukker opp et vill-farent \n når du kopierer dem. Stien ser riktig ut, men fetch() avviser URL-en med en parsefeil. Fikseren glatter ut linjeskiftene, slik at URL-en igjen er én sammenhengende streng.

Dobbeltkodede spørrestrenger

Når en URL går gjennom to systemer som begge prosentkoder den, ender du med %2520 der det skulle stå %20. Fikseren slår de åpenbare dobbeltkodingene tilbake til ett enkelt lag — nyttig når du feilsøker omdirigeringskjeder eller webhook-payloads.

Vanlige spørsmål

Blir URL-en min lagret eller sendt et sted jeg ikke ser?

URL-en din går til backenden vår så fikset kan kjøres, og kommer rett tilbake. Vi logger ikke selve input — URL-er bærer ofte sesjonstokens eller PII i sti/spørring. Vi logger at en fiks skjedde, ikke hva som ble fikset. Inneholder URL-en en ekte hemmelighet (en signert lenke, et auth-token), så betrakt den som eksponert i det øyeblikket du limer den inn i et tredjepartsverktøy — også dette — og roter den.

Hvilke URL-feil fikser den egentlig?

De hverdagslige: manglende skjema (default https://), krøllete/typografiske anførselstegn rundt URL-en, tankestrek eller en-strek der det skulle vært en bindestrek, utilsiktede // i stien, dobbel prosentkoding (%2520 → %20 når det åpenbart er dobbeltkodet), ukodede mellomrom i spørringsverdier, tab/CR/LF-tegn som en tekstbehandler har sluppet inn i URL-en, og omsluttende vinkelparenteser som <https://example.com> fra Markdown-lenker.

Vil den endre sti-, spørrings- eller fragmentverdier?

Nei. Fikseren er bevisst konservativ. Den finner ikke på en host, gjetter ikke et manglende TLD, legger ikke til eller fjerner stisegmenter, legger ikke til eller fjerner spørringsparametre, endrer ikke rekkefølgen på parametrene, og kaster ikke fragmentet. Den rører bare tegn som er syntaktisk feil. Går customer=Ava Chen inn, kommer customer=Ava%20Chen ut — samme verdi, bare korrekt kodet i tråd med RFC 3986.

Støtter den internasjonale (Unicode-)domenenavn?

Ja. Unicode-tegn i host eller sti bevares som Internationalized Resource Identifiers (IRI-form). Hvis applikasjonen din trenger punycode-formen (ASCII) til hosten, så kjør den oppryddede URL-en gjennom URL-biblioteket i ditt språk — Nodes url-modul, Pythons idna-pakke eller nettleserens innebygde URL-konstruktør gir deg begge former.

Hva med veldig lange URL-er?

Det er en grense på 64 KB for input — omtrent 64 000 tegn. Reelle URL-er ligger nesten alltid under 2 000 tegn; er din større, skyldes det som regel at noe har blitt dobbeltkodet til én stor klump, eller at det ligger en binær payload i spørrestrengen som egentlig hører hjemme i en POST-body. Fikseren forteller deg at input er for stor; kort ned eller restrukturer først.

Den ga en feil i stedet for en fikset URL. Hva nå?

Noen input er for langt borte — for eksempel en URL der hosten mangler helt, eller en hvor strukturen er så forvridd at modellen ikke kan se hva som var meningen. I så fall: se på URL-en, fiks det åpenbare for hånd (host og skjema er de vanligste synderne) og kjør den igjennom på nytt. Du kan også slippe resultatet inn i URL-validatoren vår for å se nøyaktig hva URL-parseren klager på.

Andre URL-verktøy du kanskje trenger

Å fikse URL-en er ett steg. Når den parser rent, tar disse verktøyene den hele veien: