Point-virgule comme séparateur de requêtes URL
Bien qu'il soit fortement recommandé ( source W3C , via Wikipedia ) pour les serveurs Web de prendre en charge le point-virgule comme séparateur des éléments de requête URL (en plus de l'esperluette), il ne semble pas à suivre généralement.
Par exemple, comparez
http://www.google.com/search?q=nemo&oe = utf-8
http://www.google.com/search?q=nemo;oe = utf-8
résultats. (Dans ce dernier cas, le point-virgule est, ou était au moment de la rédaction de ce texte , traité comme un caractère de chaîne ordinaire, comme si l'url était: - http://www.google.com/search?q=nemo% 3Boe = utf-8 )
Bien que la première bibliothèque d'analyse d'URL que j'ai essayée, se comporte bien:
>>> from urlparse import urlparse, query_qs
>>> url = 'http://www.google.com/search?q=nemo;oe=utf-8'
>>> parse_qs(urlparse(url).query)
{'q': ['nemo'], 'oe': ['utf-8']}
Quel est l'état actuel de l'acceptation du point-virgule comme séparateur, et quels sont les problèmes potentiels ou quelques notes intéressantes? (du point de vue du serveur et du client)
Recommandation W3C de 1999 est obsolète. L'état actuel, selon la Recommandation W3C 2014 , est que le point-virgule est maintenant illégal comme séparateur de paramètres:
Pour décoder les charges utiles application/x-www-form-urlencoded, l'algorithme suivant doit être utilisé. [...] La sortie de cet algorithme est une liste triée de paires nom-valeur. [...]
- Supposons que les chaînes soient le résultat d'un fractionnement strict de la charge utile de la chaîne sur les caractères U + 0026 AMPERSAND (&).
En d'autres termes, ?foo=bar;baz signifie que le paramètre foo aura la valeur bar;baz; tandis que ?foo=bar;baz=sna devrait se traduire par foo étant bar;baz=sna (bien que techniquement illégal depuis le deuxième = doit être échappé vers %3D).
Tant que votre serveur HTTP et votre application côté serveur acceptent les points-virgules comme séparateurs, vous devriez être prêt à partir. Je ne vois aucun inconvénient. Comme vous l'avez dit, la la spécification W3C est de votre côté :
Nous recommandons que les implémenteurs de serveur HTTP, et en particulier les implémenteurs CGI, prennent en charge l'utilisation de ";" à la place de "&" pour éviter aux auteurs d'avoir à échapper les caractères "&" de cette manière.
Je suis d'accord avec Bob Aman. La spécification W3C est conçue pour faciliter l'utilisation des liens hypertexte d'ancrage avec des URL qui ressemblent à des demandes GET de formulaire (par exemple, http://www.Host.com/?x=1&y=2). Dans ce contexte, l'esperluette entre en conflit avec le système de références d'entité de caractère, qui commencent toutes par une esperluette (par exemple, "). Le W3C recommande donc que les serveurs Web autorisent l'utilisation d'un point-virgule comme séparateur de champ au lieu d'une esperluette, pour faciliter l'écriture de ces URL. Mais cette solution nécessite que les auteurs se souviennent que l'esperluette doit être remplacée par quelque chose, et qu'un ; est un délimiteur de champ également valide, même si les navigateurs Web utilisent universellement des esperluettes dans l'URL lors de la soumission de formulaires. C'est sans doute plus difficile que de penser à remplacer l'esperluette par un & dans ces liens, comme ce serait le cas ailleurs dans le document.
Pour aggraver les choses, jusqu'à ce que tous les serveurs Web autorisent les points-virgules comme délimiteurs de champ, les rédacteurs d'URL ne peuvent utiliser ce raccourci que pour certains hôtes et doivent utiliser & pour les autres. Ils devront également modifier leur code plus tard si un hôte donné cesse d'autoriser les délimiteurs point-virgule. C'est certainement plus difficile que d'utiliser simplement &, qui fonctionnera pour chaque serveur pour toujours. Cela supprime à son tour toute incitation pour les serveurs Web à autoriser les points-virgules comme séparateurs de champs. Pourquoi, alors que tout le monde change déjà l'esperluette en & au lieu de ;?
En bref, le HTML est un gros gâchis (en raison de sa clémence), et l'utilisation de points-virgules aide à simplifier cela beaucoup. J'estime que lorsque je prends en compte les complications que j'ai trouvées, l'utilisation des esperluettes comme séparateur rend le processus complet environ trois fois plus compliqué que l'utilisation de points-virgules pour les séparateurs à la place!
Je suis un programmeur .NET et, à ma connaissance, .NET ne pas autorise intrinsèquement ';' séparateurs, j'ai donc écrit mes propres méthodes d'analyse et de gestion parce que je voyais une énorme valeur à utiliser des points-virgules plutôt que le système déjà problématique d'utiliser des esperluettes comme séparateurs. Malheureusement, des gens très respectables (comme @Bob Aman dans une autre réponse) ne voient pas la valeur pour laquelle l'utilisation des points-virgules est de loin supérieure et tellement plus simple que d'utiliser des esperluettes. Je partage donc maintenant quelques points pour peut-être persuader d'autres développeurs respectables qui ne reconnaissent pas encore la valeur d'utiliser des points-virgules à la place:
L'utilisation d'une chaîne de requête comme '? A = 1 & b = 2' dans une page HTML est incorrecte (sans le codage HTML au préalable), mais la plupart du temps cela fonctionne. Cependant, cela n'est dû qu'à la plupart des navigateurs qui sont tolérants, et cette tolérance peut entraîner des bogues difficiles à trouver lorsque, par exemple, la valeur de la paire de valeurs clés est publiée dans une URL de page HTML sans encodage approprié (directement sous la forme '? a = 1 & b = 2 'dans la source HTML). Une chaîne de requête comme "? Who = me + & + you" est également problématique.
Nous, les gens peuvent avoir biais et pouvons être en désaccord sur nos biais toute la journée, il est donc très important de reconnaître nos biais. Par exemple, je conviens que je pense simplement que séparer avec ';' semble "plus propre". Je conviens que mon opinion "plus propre" est purement un parti pris. Et un autre développeur peut avoir un biais tout aussi opposé et tout aussi valide. Donc, mon biais sur ce seul point n'est pas plus correct que le biais opposé.
Mais étant donné le soutien impartial du point-virgule qui facilite la vie de chacun à long terme, ne peut pas être contesté correctement lorsque l'ensemble de l'image est pris en compte. En bref, l'utilisation de points-virgules rend la vie plus simple pour tout le monde, à une exception près: un petit obstacle pour s'habituer à quelque chose de nouveau. C'est tout. Il est toujours plus difficile de changer quoi que ce soit. Mais la difficulté de faire le changement pâlit par rapport à la difficulté continue de continuer à utiliser &.
En utilisant ; en tant que séparateur QueryString, il est BEAUCOUP plus simple. Les séparateurs d'esperluette sont plus de deux fois plus difficiles pour coder correctement que si des points-virgules étaient utilisés. (Je pense) la plupart des implémentations ne sont pas codées correctement, donc la plupart des implémentations ne sont pas deux fois plus compliquées. Mais la recherche et la correction des bogues entraînent une perte de productivité. Ici, je souligne 2 étapes de codage distinctes nécessaires pour coder correctement une chaîne de requête lorsque & est le séparateur:
- Étape 1: l'URL code à la fois les clés et les valeurs de la chaîne de requête.
- Étape 2: concaténer les clés et les valeurs comme 'a = 1 & b = 2' après qu'elles ont été encodées en URL à l'étape 1.
- Étape 3: Ensuite, HTML code toute la chaîne de requête dans la source HTML de la page.
Un encodage spécial doit donc être effectué deux fois pour un encodage URL correct (sans bug), et pas seulement cela, mais les encodages sont deux types d'encodage distincts et différents. Le premier est un encodage URL et le second est un encodage HTML (pour le code source HTML). Si l'un d'eux est incorrect, je peux vous trouver un bug. Mais l'étape 3 est différente pour XML. Pour XML, alors l'encodage d'entité de caractère XML est nécessaire à la place (qui est presque identique). Mon point est que le dernier encodage dépend du contexte de l'URL, que ce soit dans une page Web HTML ou dans la documentation XML.
Maintenant, avec les séparateurs point-virgule beaucoup plus simples, le processus est comme on peut s'y attendre:
- 1: l'URL code les clés et les valeurs,
- 2: concaténer les valeurs ensemble. (Sans encodage pour l'étape 3.)
Je pense que la plupart des développeurs Web ignorent l'étape 3 car les navigateurs sont très indulgents. Mais cela conduit à des bogues et à plus de complications lors de la recherche de ces bogues ou des utilisateurs incapables de faire des choses si ces bogues n'étaient pas présents, ou de la rédaction de rapports de bogues, etc.
Une autre complication en utilisation réelle est lors de l'écriture du balisage de documentation XML dans mon code source à la fois en C # et VB.NET. Puisque & doit être encodé, c'est un véritable frein, littéralement, à ma productivité. Cette étape supplémentaire 3 rend également plus difficile la lecture du code source. Ce déficit plus difficile à lire s'applique donc non seulement au HTML et au XML, mais également à d'autres applications comme le code C # et VB.NET car leur documentation utilise la documentation XML. Ainsi, la complication d'encodage de l'étape 3 prolifère également dans d'autres applications.
Donc en résumé, en utilisant le; comme séparateur est simple parce que le processus (correct) lors de l'utilisation du point-virgule est la façon dont on s'attend normalement à ce que le processus soit: une seule étape d'encodage doit avoir lieu.
Ce n'était peut-être pas trop déroutant. Mais toute la confusion ou la difficulté est due à l'utilisation d'un caractère de séparation qui devrait être codé en HTML. Ainsi "&" est le coupable. Et le point-virgule soulage toutes ces complications.
(Je soulignerai que mon processus en 3 étapes vs 2 étapes ci-dessus est généralement combien d'étapes il faudrait pour la plupart applications. Cependant, pour un code complètement robuste, les 3 étapes sont nécessaires quel que soit le séparateur utilisé. Mais d'après mon expérience, les implémentations la plupart sont bâclées et peu robustes. Par conséquent, l'utilisation du point-virgule comme séparateur de chaîne de requête faciliterait la vie de plus de personnes avec moins de bogues de site Web et d'interopérabilité, si tout le monde a adopté le point-virgule par défaut au lieu de l'esperluette.)