Collez votre URL cassée ici et cliquez sur "Réparer l'URL !!" pour la réparerSaisir une URL cassée

Qu'est-ce que le Réparateur d'URL ?

Vous avez copié un lien depuis un e-mail, un document Word, un message Slack ou une page Confluence — et il est maintenant entouré de guillemets courbes (" au lieu de "), avec un tiret cadratin (–) à la place d'un trait d'union, sans https:// au début, ou avec un saut de ligne perdu qui a coupé l'URL en deux. Collez-la ici et récupérez une URL qui marche. Le Réparateur d'URL nettoie les dégâts syntaxiques laissés par le copier-coller, en suivant les règles du standard URL du WHATWG et du RFC 3986.

Le réparateur gère ce qu'une expression régulière devrait traiter en cas particulier pour toujours : guillemets typographiques, tirets typographiques, doubles slashs accidentels dans le chemin, percent-encoding mixte ou doublé (donc %2520 redevient %20 quand c'est manifestement un double encodage), espaces non encodés et caractères CR/LF/tab tombés dans l'URL parce que quelqu'un a tapé Entrée au mauvais moment. Il n'invente pas de nom d'hôte, ne change pas vos paramètres de requête et n'ajoute pas de segment de chemin qui n'était pas là. La sortie est ensuite validée selon les règles de l'API URL du navigateur, donc vous savez qu'elle sera bien parsée à l'autre bout. Les noms d'hôtes internationalisés (Unicode, IDN) sont préservés selon le RFC 3987.

Votre URL part vers le backend pour que la réparation puisse s'exécuter, puis revient directement. Nous ne journalisons pas l'entrée — les URL transportent souvent des jetons de session, des identifiants client ou d'autres choses que vous ne voulez pas voir traîner dans un fichier de log. Si votre URL contient un véritable secret (un lien S3 signé, un jeton d'authentification à usage unique), faites-le tourner après l'avoir collé n'importe où — y compris ici.

Comment utiliser le Réparateur d'URL

Trois étapes. Chacune correspond à un bouton de cette page — rien n'est caché.

Collez l'URL cassée ou chargez l'exemple

Déposez votre URL cassée dans l'éditeur de gauche. Cliquez sur URL d'exemple pour charger un cas volontairement cassé avec des guillemets typographiques, un tiret cadratin, un schéma manquant et un espace non encodé — le genre de truc que vous collez vraiment depuis un e-mail. Exemple d'URL cassée :

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

Guillemets typographiques venant d'un Word, tiret cadratin dans le segment de chemin, pas de schéma et un espace littéral dans la valeur de requête. Quatre problèmes distincts dans une seule petite ligne.

Cliquez sur Réparer l'URL !!

Appuyez sur le bouton vert Réparer l'URL !!. Le réparateur retire les guillemets autour, remplace le tiret cadratin par un trait d'union, ajoute https:// en tête et encode l'espace pour que le résultat respecte le RFC 3986.

Copiez l'URL réparée

Le panneau de droite affiche l'URL nettoyée. Survolez-la, copiez-la, collez-la dans votre navigateur, votre appel fetch(), votre README ou le test qui plantait. Si vous voulez voir l'URL décomposée en ses différentes parties, passez-la ensuite dans notre Analyseur d'URL.

Quand vous l'utiliseriez vraiment

Liens collés depuis un e-mail ou Word

Outlook et Word transforment silencieusement les guillemets droits en guillemets courbes et les traits d'union en tirets cadratins. L'URL a l'air bien dans le message, et casse à la seconde où vous la collez dans un terminal. Le réparateur défait cette autocorrection « intelligente » pour que le lien refonctionne.

URL entourées de guillemets par un logger

Les logs applicatifs au format JSON adorent imprimer les URL comme "https://api.example.com/v1/orders?id=ORD-1001". Quand vous l'attrapez pour un curl rapide, les guillemets viennent avec. Le réparateur les enlève et vous arrêtez de vous demander pourquoi votre shell râle sur un guillemet non fermé.

Sauts de ligne en plein milieu de l'URL par Slack ou Jira

Les URL longues dans Slack, Jira ou Confluence se replient et embarquent souvent un \n perdu quand vous les copiez. Le chemin a l'air correct mais fetch() rejette l'URL avec une erreur de parsing. Le réparateur aplatit les sauts de ligne pour que l'URL redevienne une chaîne continue.

Chaînes de requête doublement encodées

Quand une URL passe par deux systèmes qui font tous deux du percent-encoding, vous vous retrouvez avec %2520 là où il devrait y avoir %20. Le réparateur ramène les doubles encodages évidents à une seule couche — utile quand vous déboguez des chaînes de redirections ou des payloads de webhooks.

Questions fréquentes

Mon URL est-elle stockée ou envoyée quelque part que je ne vois pas ?

Votre URL part vers notre backend pour que la réparation puisse s'exécuter, puis revient tout de suite. Nous ne journalisons pas l'entrée elle-même — les URL transportent souvent des jetons de session ou des PII dans le chemin/la requête. On enregistre qu'une réparation a eu lieu, pas ce qui a été réparé. Si l'URL contient un véritable secret (lien signé, jeton d'authentification), considérez-le comme exposé dès que vous le collez dans un outil tiers — y compris celui-ci — et faites-le tourner.

Quels types d'erreurs d'URL sont vraiment corrigés ?

Les courants : schéma manquant (par défaut https://), guillemets courbes/typographiques autour de l'URL, tiret cadratin ou demi-cadratin à la place d'un trait d'union, // accidentel dans le chemin, double percent-encoding (%2520 → %20 quand le double encodage est évident), espaces non encodés dans les valeurs de requête, caractères tab/CR/LF glissés dans l'URL par un traitement de texte, et chevrons autour comme <https://example.com> issus de liens Markdown.

Va-t-il modifier mon chemin, ma requête ou les valeurs de fragment ?

Non. Le réparateur est volontairement conservateur. Il n'invente pas d'hôte, ne devine pas un TLD manquant, n'ajoute ni ne retire de segments de chemin, n'ajoute ni ne retire de paramètres, ne change pas l'ordre des paramètres et ne supprime pas le fragment. Il ne touche qu'aux caractères syntaxiquement incorrects. Si customer=Ava Chen entre, customer=Ava%20Chen ressort — même valeur, simplement encodée correctement selon le RFC 3986.

Prend-il en charge les noms de domaine internationaux (Unicode) ?

Oui. Les caractères Unicode dans l'hôte ou le chemin sont conservés sous forme d'identifiants de ressources internationalisés (forme IRI). Si votre application a besoin de la forme punycode (ASCII) pour l'hôte, passez l'URL nettoyée dans la bibliothèque URL de votre langage — le module url de Node, le paquet idna de Python ou le constructeur URL natif du navigateur vous donneront les deux formes.

Et pour des URL vraiment longues ?

Il y a un plafond de 64 Ko sur l'entrée — soit environ 64 000 caractères. Les vraies URL font presque toujours moins de 2 000 caractères ; si la vôtre est plus grosse, c'est généralement parce que quelque chose a été doublement encodé en un gros pâté, ou qu'il y a une charge binaire dans la chaîne de requête qui devrait être dans un corps de POST. Le réparateur vous dira que l'entrée est trop grosse ; raccourcissez ou restructurez d'abord.

Il a renvoyé une erreur au lieu d'une URL réparée. Et maintenant ?

Certaines entrées sont trop abîmées — par exemple, une URL où l'hôte manque complètement, ou une dont la structure est tellement déformée que le modèle ne peut pas deviner ce qui était voulu. Dans ce cas, regardez l'URL, corrigez à la main les évidences (l'hôte et le schéma sont les suspects habituels) et relancez. Vous pouvez aussi déposer le résultat dans notre Validateur d'URL pour voir exactement ce que le parseur d'URL reproche.

D'autres outils URL dont vous pourriez avoir besoin

Réparer l'URL n'est qu'une étape. Une fois qu'elle parse proprement, ces outils vous emmènent jusqu'au bout :