URL-Reparatur
Kaputte URLs online reparieren – typografische Anführungszeichen, fehlendes https, doppelte Schrägstriche, gemischte Kodierung, aus Word oder Slack eingefügte Zeilenumbrüche.
Was ist die URL-Reparatur?
Du hast einen Link aus einer E-Mail, einem Word-Dokument, einer Slack-Nachricht oder einer Confluence-Seite kopiert – und jetzt steht er in geschwungenen Anführungszeichen (" statt "), hat einen Halbgeviertstrich (–), wo ein Bindestrich hingehört, kein https:// davor, oder einen verirrten Zeilenumbruch, der die URL in zwei Teile geschnitten hat. Hier einfügen, eine funktionierende URL zurückbekommen. Die URL-Reparatur räumt den syntaktischen Schaden auf, den Copy-and-paste hinterlässt, und folgt dabei den Regeln des WHATWG URL Standards und von RFC 3986.
Die Reparatur kümmert sich um Dinge, die ein regulärer Ausdruck ewig als Sonderfälle behandeln müsste: typografische Anführungszeichen, typografische Striche, versehentliche doppelte Schrägstriche im Pfad, gemischtes oder doppeltes Percent-Encoding (also wird %2520 zu %20, wenn es klar eine Doppelkodierung ist), nicht kodierte Leerzeichen und CR/LF/Tab-Zeichen, die in der URL gelandet sind, weil jemand zum falschen Zeitpunkt Enter gedrückt hat. Sie erfindet keinen Hostnamen, ändert deine Query-Parameter nicht und fügt kein Pfad-Segment hinzu, das vorher nicht da war. Die Ausgabe wird anschließend gegen die Regeln der URL-API des Browsers validiert, damit du weißt, dass sie auf der Gegenseite tatsächlich parst. Internationalisierte Hostnamen (Unicode, IDN) bleiben gemäß RFC 3987 erhalten.
Deine URL geht ans Backend, damit die Reparatur laufen kann, und kommt dann sofort zurück. Wir loggen die Eingabe nicht – URLs tragen oft Session-Tokens, Kunden-IDs oder andere Dinge, die du nicht in einer Logdatei sitzen sehen willst. Wenn deine URL ein echtes Geheimnis enthält (einen signierten S3-Link, ein Einmal-Auth-Token), dann rotiere es, nachdem du es irgendwo eingefügt hast – auch hier.
So benutzt du die URL-Reparatur
Drei Schritte. Jeder entspricht einem Button auf dieser Seite – nichts ist versteckt.
Kaputte URL einfügen oder das Beispiel laden
Wirf deine kaputte URL in den linken Editor. Klick auf Beispiel-URL, um ein absichtlich kaputtes Beispiel zu laden, mit geschwungenen Anführungszeichen, Halbgeviertstrich, fehlendem Schema und einem nicht kodierten Leerzeichen – genau die Sorte Sache, die du tatsächlich aus einer E-Mail einfügst. Beispiel einer kaputten URL:
"shop.example.com/orders/ORD–1001?customer=Ava Chen"Geschwungene Anführungszeichen aus einem Word-Dokument umgeben die URL, Halbgeviertstrich im Pfad-Segment, kein Schema und ein wörtliches Leerzeichen im Query-Wert. Vier verschiedene Probleme in einer kurzen Zeile.
Auf URL reparieren!! klicken
Drück den grünen Button URL reparieren!!. Die Reparatur entfernt die umschließenden Anführungszeichen, ersetzt den Halbgeviertstrich durch einen Bindestrich, setzt https:// davor und kodiert das Leerzeichen percent, sodass das Ergebnis konform mit RFC 3986 ist.
Reparierte URL kopieren
Das rechte Panel zeigt die bereinigte URL. Drüberfliegen, kopieren, in den Browser, in deinen fetch()-Aufruf, in dein README oder in den Test einfügen, der gerade gefehlschlagen ist. Wenn du die URL in ihre Bestandteile zerlegt sehen willst, schick sie als Nächstes durch unseren URL-Parser.
Wann du das wirklich brauchst
Aus E-Mail oder Word eingefügte Links
Outlook und Word verwandeln stille gerade Anführungszeichen in geschwungene und Bindestriche in Halbgeviertstriche. Die URL sieht in der Nachricht gut aus und ist in der Sekunde kaputt, in der du sie in ein Terminal einfügst. Die Reparatur dreht diese „intelligente" Autokorrektur zurück, damit der Link wieder funktioniert.
Von einem Logger in Anführungszeichen gepackte URLs
JSON-formatierte Anwendungslogs lieben es, URLs als "https://api.example.com/v1/orders?id=ORD-1001" auszugeben. Wenn du sie für ein schnelles curl rauskopierst, kommen die umschließenden Anführungszeichen mit. Die Reparatur entfernt sie, und du musst dich nicht mehr fragen, warum deine Shell über ein nicht geschlossenes Anführungszeichen meckert.
Mitten in der URL eingefügte Zeilenumbrüche durch Slack oder Jira
Lange URLs in Slack, Jira oder Confluence brechen oft um und schleppen beim Kopieren ein verirrtes \n mit. Der Pfad sieht richtig aus, aber fetch() lehnt die URL mit einem Parse-Fehler ab. Die Reparatur glättet die Zeilenumbrüche, sodass die URL wieder ein einziger zusammenhängender String ist.
Doppelt kodierte Querystrings
Wenn eine URL durch zwei Systeme läuft, die beide Percent-Encoding anwenden, landest du bei %2520 dort, wo eigentlich %20 stehen sollte. Die Reparatur reduziert offensichtliche Doppelkodierungen wieder auf eine einzige Schicht – nützlich beim Debuggen von Redirect-Ketten oder Webhook-Payloads.
Häufige Fragen
Wird meine URL irgendwo gespeichert oder hingeschickt, ohne dass ich es sehe?
Deine URL geht ans Backend, damit die Reparatur laufen kann, und kommt direkt zurück. Wir loggen die Eingabe selbst nicht – URLs tragen häufig Session-Tokens oder PII im Pfad/Query. Wir loggen, dass eine Reparatur stattgefunden hat, nicht was repariert wurde. Wenn die URL ein echtes Geheimnis enthält (signierter Link, Auth-Token), behandle es als kompromittiert, sobald du es in irgendein Drittanbieter-Tool einfügst – auch in dieses – und rotiere es.
Welche URL-Fehler korrigiert das wirklich?
Die alltäglichen: fehlendes Schema (Standard https://), geschwungene/typografische Anführungszeichen um die URL, Halb- oder Geviertstrich, wo ein Bindestrich hingehört, versehentliche // im Pfad, doppeltes Percent-Encoding (%2520 → %20, wenn klar eine Doppelkodierung), nicht kodierte Leerzeichen in Query-Werten, Tab-/CR-/LF-Zeichen, die ein Textverarbeitungsprogramm in die URL gelegt hat, und umschließende spitze Klammern wie <https://example.com> aus Markdown-Links.
Verändert es meinen Pfad, Query oder Fragment-Werte?
Nein. Die Reparatur ist absichtlich konservativ. Sie erfindet keinen Hostnamen, errät keine fehlende TLD, fügt keine Pfad-Segmente hinzu oder entfernt sie, fügt keine Query-Parameter hinzu oder entfernt sie, ändert die Parameter-Reihenfolge nicht und verwirft das Fragment nicht. Sie fasst nur Zeichen an, die syntaktisch falsch sind. Wenn customer=Ava Chen reingeht, kommt customer=Ava%20Chen raus – derselbe Wert, nur korrekt nach RFC 3986 kodiert.
Werden internationalisierte (Unicode-)Domainnamen unterstützt?
Ja. Unicode-Zeichen im Host oder Pfad bleiben als Internationalized Resource Identifiers (IRI-Form) erhalten. Wenn deine Anwendung die Punycode-Form (ASCII) für den Host braucht, schick die bereinigte URL durch die URL-Bibliothek deiner Sprache – Nodes url-Modul, Pythons idna-Paket oder der eingebaute URL-Konstruktor des Browsers liefern dir beide Formen.
Was ist mit wirklich langen URLs?
Es gibt eine Obergrenze von 64 KB für die Eingabe – das sind etwa 64 000 Zeichen. Echte URLs liegen fast immer unter 2 000 Zeichen; wenn deine größer ist, liegt das meistens daran, dass etwas in einen riesigen Klotz doppelkodiert wurde, oder dass ein Binär-Payload im Querystring sitzt, der eigentlich in einen POST-Body gehört. Die Reparatur sagt dir, dass die Eingabe zu groß ist; kürze oder strukturiere sie zuerst um.
Es kam ein Fehler statt einer reparierten URL zurück. Was jetzt?
Manche Eingaben sind zu weit weg vom Original – zum Beispiel eine URL, bei der der Host komplett fehlt, oder eine, deren Struktur so verstümmelt ist, dass das Modell nicht erkennen kann, was gemeint war. In dem Fall: schau dir die URL an, korrigier die offensichtlichen Stellen per Hand (Host und Schema sind die üblichen Verdächtigen) und lass es nochmal laufen. Du kannst das Ergebnis auch in unseren URL-Validator kippen, um genau zu sehen, worüber sich der URL-Parser beschwert.
Weitere URL-Tools, die du brauchen könntest
Die URL zu reparieren ist nur ein Schritt. Sobald sie sauber parst, übernehmen diese Tools den Rest: