URL

Normalisée

Qu'est-ce que le Normalisateur d'URL ?

Deux URLs qui sont « la même » mais qui ne se comparent pas comme égales à cause de la casse ou de l'ordre de la query, c'est le genre de bug qui vous fait perdre un après-midi. HTTPS://Example.com/page et https://example.com/page pointent vers la même ressource, mais une comparaison de chaînes dit qu'elles diffèrent. Le normalisateur prend une URL et produit sa forme canonique selon la RFC 3986 §6 et le WHATWG URL Standard, de sorte que deux URLs qui veulent dire la même chose produisent la même chaîne.

Les normalisations sont les opérations ennuyeuses mais essentielles : passer le schéma et l'hôte en minuscules (selon la RFC 3986 §6.2.2.1, ils sont insensibles à la casse), supprimer les ports par défaut (:443 sur https, :80 sur http), décoder les caractères non réservés encodés en pourcent (%41 → A), trier les paramètres de requête alphabétiquement par clé, retirer un fragment vide (# sans rien derrière), et résoudre les segments . et .. du chemin. Le JSON de sortie inclut l'URL normalisée, l'originale et un tableau changes qui liste exactement ce qui a été réécrit — vous voyez ainsi pourquoi deux URLs qui semblaient différentes sont en fait identiques.

Tout tourne dans votre navigateur via l'API URL standard et URLSearchParams — pas de serveur, pas de logs. Si votre entrée est déjà canonique, le tableau changes est vide et c'est la réponse : rien à faire. Pratique comme garde-fou avant de publier un sitemap ou de poser un <link rel="canonical">.

Comment utiliser le Normalisateur d'URL

Trois étapes. Chacune correspond à un bouton de cette page.

Collez une URL ou chargez l'exemple

Déposez une URL dans le panneau de gauche. Cliquez sur Exemple pour charger une URL réaliste et bien sale : schéma et hôte en majuscules, port par défaut, ordre des paramètres mélangé, espace encodé en pourcent, fragment vide. URL d'exemple :

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

Les noms de domaine internationalisés (IDN) sont convertis en Punycode par le constructeur URL — c'est la forme effectivement transmise sur le réseau, conformément aux règles de normalisation d'URI. La partie userinfo (user:pass@host) est préservée si elle est présente.

Lisez la sortie

Le panneau de droite affiche un JSON avec trois champs : normalized (l'URL canonique), original (ce que vous avez collé, espaces retirés) et changes — un tableau d'entrées { rule, from, to } listant chaque réécriture. Si changes est vide, l'URL était déjà canonique.

Copiez ou téléchargez

Cliquez sur Copier pour envoyer le JSON dans le presse-papiers, ou sur Télécharger pour l'enregistrer en fichier .json. Minifier compacte le JSON sur une seule ligne. Utilisez Effacer sur le panneau d'entrée pour repartir de zéro.

Quand vous allez vraiment vous en servir

Clés de cache et déduplication analytics

Votre tableau analytics voit Example.com/page et example.com/page comme deux lignes différentes. Votre cache CDN aussi. Normalisez à l'entrée et le doublon disparaît. Même astuce si vous montez un raccourcisseur d'URLs ou un dédoublonneur de signets : stockez la forme normalisée comme clé de recherche.

URLs canoniques pour le SEO

Les moteurs de recherche pénalisent le contenu dupliqué quand la même page est accessible via plusieurs URLs. Votre balise <link rel="canonical"> et les URLs de votre sitemap.xml doivent correspondre à une seule forme normalisée. Le guide de canonisation de Google détaille les règles ; cet outil est le moyen le plus rapide de les appliquer à la main.

Comparer deux URLs pour l'égalité

Vous écrivez un détecteur de boucles de redirection ou vous testez un webhook. Deux URLs sont « identiques » si leurs formes normalisées coïncident. Comparez les chaînes après normalisation — n'improvisez pas votre propre fonction d'égalité basée sur URL.toString(), parce qu'elle ne trie pas les paramètres et ne supprime pas les ports par défaut.

Nettoyer les URLs avant stockage ou affichage

Un utilisateur colle HTTPS://www.SHOP.com:443/cart/?b=2&a=1# dans votre formulaire. Vous ne voulez pas stocker ça dans votre base, et encore moins le renvoyer par email. Normalisez d'abord, puis enregistrez la version propre. Les URLs visibles côté client deviennent prévisibles.

Questions fréquentes

Et si mon URL est déjà canonique ?

Vous verrez la même URL dans normalized et dans original, et le tableau changes sera vide ("changes": []). C'est la réponse — il n'y avait rien à réécrire. La page ne plante pas et n'affiche pas d'erreur dans ce cas.

Touche-t-il au chemin au-delà du retrait de la barre oblique finale à la racine ?

Quasiment pas. Les segments . et .. sont résolus (le constructeur URL le fait automatiquement — la RFC 3986 §5.2.4 appelle ça « remove dot segments »). Les barres obliques finales ne sont retirées que lorsque le chemin est juste / ; /v1/orders/ reste /v1/orders/ parce que la RFC 3986 dit qu'une barre finale peut être significative. Certains frameworks serveurs les traitent comme des routes différentes.

Pourquoi mes paramètres de requête sont-ils triés ? L'ordre m'importait.

Dans la RFC 3986, l'ordre de la query n'est pas sémantiquement significatif — ?a=1&b=2 et ?b=2&a=1 sont équivalents au niveau de l'URL. Trier par ordre alphabétique vous donne une forme canonique stable pour que deux URLs équivalentes correspondent octet par octet. Si votre application dépend réellement de l'ordre des paramètres (elle ne devrait pas, mais certains systèmes hérités le font), ce normalisateur va casser cette hypothèse — ne normalisez pas les URLs que vous envoyez à un serveur qui se soucie de l'ordre.

Pourquoi %20 devient-il parfois + après normalisation ?

%20 et + représentent tous les deux un espace à l'intérieur d'une query string (selon les règles d'application/x-www-form-urlencoded, c'est ce qu'utilise URLSearchParams pour la sérialisation). Quand l'objet URLSearchParams ressérialise la query, il utilise +. Ils sont sémantiquement identiques pour tout parseur d'URL conforme aux standards ; si votre serveur les traite différemment, c'est un bug côté serveur.

Que se passe-t-il avec les domaines internationalisés comme café.example ?

Le constructeur URL convertit l'hôte en Punycode — caf%C3%A9.example devient xn--caf-dma.example. C'est la forme sous laquelle l'URL serait réellement envoyée via DNS, et c'est ce que spécifient la RFC 3987 et la spec WHATWG. L'article Wikipédia sur la normalisation d'URI explique le traitement des IDN si vous voulez les détails.

Est-ce sûr pour les URLs avec des identifiants (user:pass@host) ?

Le parsing se fait entièrement dans votre navigateur — rien n'est envoyé nulle part. Userinfo est conservé durant la normalisation. La question de savoir si vous devriez vraiment passer des identifiants dans une URL est une autre histoire — la plupart des navigateurs et clients HTTP suppriment ou alertent maintenant sur userinfo à cause des risques de sécurité, et un en-tête Authorization est généralement bien meilleur.

Supprime-t-il les paramètres de requête en double ?

Non. ?tag=red&tag=red reste ?tag=red&tag=red. Les clés répétées peuvent avoir un sens (certaines API les utilisent pour des tableaux) et les supprimer changerait la sémantique. Le tri est stable, donc à l'intérieur d'une même clé l'ordre d'origine est préservé.

Autres outils URL et JSON

Normaliser n'est qu'une opération. Voici ce qui s'accorde naturellement avec :