Votre lien perd des données : corriger paramètres et fragments

Une page qui s’ouvre ne reçoit pas forcément les données prévues

Vous avez préparé un lien vers une recherche de café et de thé. La page s’ouvre, mais les résultats ne correspondent pas à votre intention. Avant d’accuser le serveur ou le raccourcisseur, examinez l’adresse exacte partagée. Dans notre exemple fictif, q=cafe&te ne représente pas une valeur unique cafe&te selon l’interprétation habituelle des paramètres de formulaire : & sépare les entrées. De plus, #precios marque un fragment. Remplacez example.invalid par votre propre page acceptant cette recherche avant de tester une adresse réelle.

Divisez le diagnostic en trois questions : quelle page ouvrir, quelles données doit-elle recevoir et quelle partie afficher ensuite ? Copiez l’URL du lien, pas seulement le libellé visible du bouton. Conservez une version de référence avant toute modification. Ce guide propose de vérifier les composants puis le résultat avec WikiURL ; il ne promet pas que chaque site reconnaisse q, ni qu’une réponse réussie signifie des résultats de recherche corrects.

https://example.invalid/buscar?q=cafe&te#precios

Si l’esperluette appartient au texte, ne l’utilisez pas comme séparateur

Pour rechercher littéralement cafe & te, l’esperluette fait partie de la valeur de q. Avec URLSearchParams, fournissez le texte non encodé ; la sérialisation représentera ce caractère par %26. MDN explique que cette interface applique l’encodage des formulaires lors de la conversion des paramètres en texte et représente les espaces par +. Cela ne signifie pas qu’il faut remplacer toutes les esperluettes d’une URL : certaines séparent volontairement des paramètres.

L’exemple JavaScript crée l’adresse à partir d’une base, définit la valeur de recherche puis ajoute le fragment séparément. Vous pouvez l’exécuter localement dans un environnement JavaScript pour observer le résultat sans envoyer de recherche au domaine fictif. Si vous ne programmez pas, utilisez le lien généré par votre page de recherche plutôt que de concaténer manuellement du texte. Comparez la valeur attendue aux résultats du site ; voir %26 ne suffit pas à connaître l’interprétation d’une application particulière.

const url = new URL("https://example.invalid/buscar");
url.searchParams.set("q", "cafe & te");
url.hash = "precios";
console.log(url.href);
// https://example.invalid/buscar?q=cafe+%26+te#precios

Le fragment n’est pas un paramètre reçu par le serveur

MDN indique que le fragment placé après # est traité par le client et n’est pas envoyé au serveur lors de la demande de la ressource. Une page peut l’utiliser pour atteindre une section comme precios ou pour un autre comportement applicatif. Ainsi, avec q=cafe#te, te ne complète pas la valeur reçue par le serveur dans cette requête. Si # doit faire partie du texte recherché, sa représentation dans la valeur sera %23, comme dans la troisième adresse.

Vérifiez séparément les deux effets : la recherche doit afficher les bons résultats et le fragment doit atteindre l’endroit souhaité. La section doit exister ou l’application reconnaître ce fragment. Un outil interrogeant le site depuis un serveur ne confirme pas à lui seul le déplacement du navigateur vers une section. Ne supprimez pas non plus tous les fragments comme solution universelle : vous pourriez retirer précisément la partie dont le destinataire avait besoin.

https://example.invalid/buscar?q=cafe%23te#precios

Encodez une fois la valeur, pas toute l’adresse

La norme RFC 3986 distingue les caractères délimitant les composants des données et déconseille d’encoder ou décoder plusieurs fois la même chaîne. Si vous fournissez cafe%26te comme texte déjà encodé à une fonction attendant une valeur non encodée, le pourcentage peut devenir %25 et produire %2526. Vous avez ajouté une couche, sans préserver automatiquement la recherche voulue. Les deux lignes de l’exemple permettent de repérer ce changement.

La correction dépend de l’origine des données. Si elles viennent d’un texte humain, transmettez-les sans encodage à l’interface qui construit les paramètres. Si elles viennent d’une URL complète déjà valide, ne traitez pas toute l’adresse comme une seule valeur à réencoder. Documentez ce que reçoit chaque fonction ou formulaire. Évitez les remplacements globaux de %, & ou # : ils pourraient modifier des délimiteurs corrects, des paramètres nécessaires ou des chemins non concernés.

q=cafe%26te
q=cafe%2526te

Utilisez WikiURL pour la réponse et le navigateur pour le contenu

Une fois l’adresse publique réelle obtenue, collez-la dans le vérificateur d’URL de WikiURL. Examinez le statut HTTP et la destination finale renvoyés. L’implémentation interroge depuis le serveur et suit les redirections ; cela aide à repérer une destination inattendue. Ne collez pas de liens de gestion, de mots de passe ou d’adresses contenant des données privées. Ne tentez pas de vérifier example.invalid : il sert ici de destination fictive.

Ouvrez aussi la version réelle dans votre navigateur et examinez la recherche et la section. Une réponse réussie peut charger la page sans appliquer le filtre prévu. En cas de redirection, comparez les paramètres à votre référence et observez le fragment dans le navigateur. Le vérificateur n’interprète pas la logique applicative, ne certifie pas la sécurité et ne prouve pas qu’un compte dispose de droits d’accès. Le but est d’associer les éléments de réponse à une vérification fonctionnelle.

Testez la copie que recevra une autre personne

Collez le lien final dans le canal de partage puis ouvrez cette copie avant une diffusion large. Vérifiez que vous n’avez pas inclus le point final de la phrase, perdu une partie lors de la copie ou confondu texte visible et destination. Si le contenu doit être public, testez sans dépendre de votre session administrateur. Pour un QR, vérifiez aussi l’adresse affichée lors du scan, en complément du fichier source.

Gardez un petit relevé : adresse originale, valeur de recherche attendue, fragment prévu, URL partagée et résultat observé. En cas d’échec, revenez au composant concerné et recommencez après correction. Publiez uniquement la version vérifiée. Vous distinguerez ainsi une construction incorrecte des paramètres, une redirection modifiant la destination et un comportement du navigateur, sans prendre l’ouverture du lien pour une garantie qu’il conserve toutes les données prévues.