Outils de développement · Encodeur et décodeur d'URL
Espaces dans les liens de téléchargement de fichiers : pourquoi %20, + et un espace brut ne sont pas identiques
· Pourquoi c'est important
encodage d'URL http flux de travail du développeur
Un fichier appelé « Rapport Q3 (final).pdf » peut être lié de trois manières différentes, et une seule est fiable de manière correcte. Cet article explique pourquoi les noms de fichiers rompent les liens de téléchargement et comment les encoder pour que chaque client soit d'accord.
Le téléchargement qui échoue pour certains utilisateurs et fonctionne pour d'autres : un nom de fichier avec des espaces et un signe plus
Les fichiers tels que « Rapport Q3.pdf » fonctionnent correctement lorsqu'ils sont stockés localement, mais échouent via les liens de téléchargement pour certains utilisateurs tandis que d'autres réussissent sans problème. Les espaces bruts ne sont pas valides dans les URL selon la spécification RFC 3986. Les navigateurs les tolèrent dans les barres d'adresse mais les clients HTTP les rejettent strictement. Comprendre %20, les signes plus et les espaces bruts est absolument essentiel pour une distribution fiable. La distinction entre les méthodes de codage affecte directement les taux de réussite des téléchargements sur différentes plates-formes, divers outils d'automatisation et les implémentations de clients HTTP dans le monde entier. Les développeurs doivent comprendre cette distinction lors de la création de systèmes de téléchargement. Le contexte est important pour les choix de codage et la compatibilité du système.
Les développeurs doivent choisir entre des espaces bruts, %20 ou des signes plus lors de la création de liens de téléchargement. Les tests avec curl, wget et Python révèlent quels clients appliquent la conformité RFC. Les téléchargements du navigateur réussissent en raison d'une récupération d'erreur, mais les intégrations d'API échouent lorsqu'elles rencontrent des espaces non codés.
Pourquoi un espace brut n'est pas valide dans une URL — et pourquoi les navigateurs le tolèrent dans la barre d'adresse mais pas les clients HTTP
Les espaces bruts dans les URL ont des racines historiques dans la conception des protocoles. Les URL traversent des systèmes traitant les espaces comme délimiteurs entre les jetons. Un espace dans une URL pourrait être interprété à tort comme son terminateur. Les clients HTTP lisant à partir des lignes de commande sont tronqués aux premiers espaces. Cette conception fondamentale reste dans les implémentations de protocoles et il est peu probable qu'elle change.
Les navigateurs tolèrent les espaces bruts grâce à une conversion silencieuse en %20 avant d'envoyer des requêtes HTTP. Ce comportement convivial masque les exigences de protocole aux utilisateurs finaux qui collent des URL dans les barres d'adresse. Les systèmes automatisés ne disposent pas de cette couche de récupération. Les scripts échouent sur les URL contenant des espaces bruts. Les clients de messagerie rencontrent des échecs en ouvrant de tels liens.
%20 versus + dans un segment de chemin — la convention de codage de formulaire qui ne s'applique pas aux chemins
%20 par rapport aux signes plus représente une distinction fondamentale dans les contextes de codage d'URL. Dans les segments de chemin, les espaces doivent être codés sous la forme %20 conformément à la RFC 3986. Le signe plus n'est pas un espace codé dans les chemins. Cette convention trouve son origine dans l'encodage de formulaire HTML où elle sert d'encodage d'espace dans les chaînes de requête. Les développeurs appliquent souvent de manière incorrecte les règles de formulaire aux chemins.
Les conventions de codage de formulaire autorisant les signes plus ne s'appliquent pas aux chemins ayant des exigences structurelles différentes. Dans les chaînes de requête, les esperluettes et les valeurs égales délimitent les paramètres. L'utilisation de plus pour les espaces dans les valeurs de requête ne crée aucune ambiguïté puisque plus n'est pas un délimiteur. Dans les chemins, le plus n'a pas de signification particulière. Les conventions de mixage créent des liens de téléchargement rompus.
Noms de fichiers non ASCII — UTF-8 clés de codage en pourcentage et de stockage d'objets qui stockent le nom brut
Les noms de fichiers non-ASCII nécessitent un encodage de UTF-8 pour cent avant une transmission sécurisée dans les URL. Un nom de fichier tel que « Über report.pdf » contient « Ü » (U+00DC) en dehors de la plage ASCII. L'encodage UTF-8 convertit cela en octets C3 9C. Ces octets sont codés en pourcentage sous la forme %C3%9C dans les URL. Chaque octet UTF-8 obtient son propre triplet, produisant des noms de fichiers codés plus longs.
Les services de stockage d'objets comme Amazon S3 présentent des cas intéressants pour les noms de fichiers non-ASCII. Certains systèmes autorisent UTF-8 octets bruts dans les clés tandis que d'autres nécessitent un codage en pourcentage. La stratégie d'encodage dépend des fournisseurs de stockage et de l'utilisation des URL. L'accès basé sur l'URL nécessite UTF-8 codé en pourcentage. Les développeurs doivent coordonner les couches de stockage et de génération d'URL.
Exemple pratique : encodage de « Über Q3 report (final)+notes.pdf » pour un chemin – la sortie exacte et pourquoi le + doit devenir %2B
Exemple concret : l'encodage "Über report (final)+notes.pdf" démontre l'encodage complet. Le nom de fichier contient des espaces, des caractères non-ASCII et un plus littéral. L'encodage UTF-8 de "Ü" produit %C3%9C. Dans l'encodage de chemin, les espaces deviennent %20 (contrairement à l'encodage de formulaire utilisant plus). Le plus littéral devient %2B. Les parenthèses sont codées sous la forme %28 et %29. Résultat : %C3%9CberQ3%20report%20%28final%29%2Bnotes.pdf.
Les tests avec l'encodeur et le décodeur d'URL montrent une transformation exacte. Coller le nom de fichier en mode valeur unique produit des segments codés en pourcentage corrects à l'aide de règles de chemin. L'outil préserve les délimiteurs de chemin tout en codant uniquement les composants de nom de fichier. La comparaison visuelle des entrées et des sorties rend les règles claires et vérifiables avant la production. Comparez cela avec le mode formulaire pour voir les différences de contexte.
Content-Disposition et le paramètre filename* — un encodage distinct pour l'invite de téléchargement, mentionné par souci d'exhaustivité Les paramètres
Content-Disposition et filename* représentent des couches d'encodage alternatives pour les invites de téléchargement. Les serveurs incluent des en-têtes Content-Disposition spécifiant les noms de fichiers pour les boîtes de dialogue de téléchargement. Le paramètre filename utilise le codage RFC 2183 tandis que filename* utilise RFC 5987 avec un codage en pourcentage. Les navigateurs interprètent ces en-têtes pour décider des noms de fichiers de sauvegarde. Le même nom de fichier est encodé deux fois avec des schémas différents.
Deux couches de codage créent des opportunités d'erreurs de transcodage. Les noms de fichiers codés en URL et en en-tête peuvent ne pas faire l'aller-retour correctement si les serveurs et les clients ne sont pas d'accord. Pour une compatibilité maximale, les développeurs doivent encoder les noms de fichiers dans les chemins d'URL en utilisant le codage en pourcentage %20 et UTF-8, et définir les en-têtes Content-Disposition avec les noms de fichiers décodés. Cela garantit que tous les clients et navigateurs HTTP fonctionnent correctement.
Ce que cela ne couvre pas : noms de fichiers réservés sur des systèmes d'exploitation spécifiques et bizarreries du fournisseur de stockage
Les noms de fichiers réservés sur des systèmes d'exploitation spécifiques ajoutent de la complexité au codage des URL. Windows réserve des noms tels que CON, PRN et AUX pour les appareils. Les fichiers littéralement nommés « CON.pdf » ne peuvent pas exister sur NTFS. macOS a des conventions de dénomination et des règles d'attributs étendues. Linux est sensible à la casse. Les noms de fichiers codés en URL valides peuvent ne pas être valides pour le stockage sur certains systèmes.
Les bizarreries des fournisseurs de stockage ajoutent de la complexité à la distribution multiplateforme. Amazon S3 accepte les clés UTF-8 et est sensible à la casse. Google Cloud Storage se comporte de la même manière avec des restrictions supplémentaires. Azure Blob Storage a des règles de caractère différentes. Les noms de fichiers fonctionnant sur S3 peuvent échouer sur Azure. Les architectes doivent vérifier la documentation du fournisseur et tester avec de vrais noms de fichiers non ASCII.
À retenir : encodez le segment, pas l'URL - comment le mode à valeur unique de l'encodeur et du décodeur d'URL produit un nom de fichier sécurisé pour le chemin
À retenir : codez le segment, pas l'URL : le mode à valeur unique de l'encodeur et du décodeur d'URL produit des noms de fichiers sécurisés. L'outil accepte les noms de fichiers bruts et produit des segments codés en pourcentage. Cela évite le double encodage et le mélange des contextes. L’utilisation du mode à valeur unique évite d’équilibrer les règles de codage de chemin, de requête et de fragment. Les segments générés peuvent être insérés en toute sécurité dans les URL.
Les meilleures pratiques encodent les noms de fichiers là où ils entrent dans la construction de l'URL. Ne présumez pas que les navigateurs résolvent les problèmes d’encodage. Testez avec les clients HTTP réels utilisés par les utilisateurs cibles : curl, wget, Python, Java httplib et les API de récupération du navigateur. Vérifiez que les noms de fichiers survivent aux allers-retours dans des systèmes entiers. L'encodeur et le décodeur d'URL sont le point de départ garantissant l'exactitude.