Pourquoi devrais-je utiliser urlencode?
J'écris une application web et j'apprends à urlencoder des liens html ...
Toutes les questions d'urlencode ici (voir la balise ci-dessous) sont "Comment ...?" des questions.
Ma question n'est pas "Comment?" mais pourquoi?".
Même l'article de wikipedia ne traite que des mécanismes de celui-ci:
http://en.wikipedia.org/wiki/Urlencode mais pas pourquoi je devrais utiliser urlencode dans ma demande du tout.
Quelles sont les implications de sécurité de l'utilisation (ou plutôt de la non-utilisation) du code url?
Comment un échec d'utilisation de l'urlencode peut-il être exploité ?
Quels types de bogues ou d'échecs peuvent surgir avec des URL non codées?
Je demande parce que même sans urlencode, un lien vers mon site Web de développement d'application comme le suivant fonctionne comme prévu: http://myapp/my%20test/ée/ràé
Pourquoi devrais-je utiliser l'urlencode?
Ou une autre façon de le dire:
Quand dois-je utiliser le code url? Dans quel genre de situations?
Mise à jour: Il y a une explication encore meilleure (imo) plus haut:
Un URI est représenté comme une séquence de caractères, pas comme une séquence d'octets. En effet, l'URI peut être "transporté" par des moyens qui ne passent pas par un réseau informatique, par exemple, imprimés sur du papier, lus par la radio, etc.
et
Pour les séquences de caractères originales qui contiennent des caractères non ASCII, cependant, la situation est plus difficile. Les protocoles Internet qui transmettent des séquences d'octets destinés à représenter des séquences de caractères devraient fournir un moyen d'identifier le jeu de caractères utilisé, s'il peut y en avoir plusieurs [RFC2277]. Cependant, il n'y a actuellement aucune disposition dans la syntaxe générique URI pour effectuer cette identification. Un schéma d'URI individuel peut nécessiter un seul jeu de caractères, définir un jeu de caractères par défaut ou fournir un moyen d'indiquer le jeu de caractères utilisé.
Parce qu'il est indiqué dans le RFC :
2.4. Séquences d'échappement
Les données doivent être échappées si elles n'ont pas de représentation utilisant un caractère non réservé; cela inclut les données qui ne correspondent pas à un caractère imprimable du jeu de caractères codé US-ASCII, ou qui correspondent à tout caractère US-ASCII qui n'est pas autorisé, comme expliqué ci-dessous.
et
2.4.2. Quand s'échapper et s'échapper
Un URI est toujours sous une forme "échappée", car échapper ou échapper un URI terminé peut changer sa sémantique. Normalement, le seul moment où les encodages d'échappement peuvent être effectués en toute sécurité est lorsque l'URI est créé à partir de ses composants; chaque composant peut avoir son propre jeu de caractères qui sont réservés, donc seul le mécanisme responsable de la génération ou de l'interprétation de ce composant peut déterminer si échapper ou non un caractère changera sa sémantique. De même, un URI doit être séparé en ses composants avant que les caractères échappés de ces composants puissent être décodés en toute sécurité.
Dans certains cas, les données qui pourraient être représentées par un caractère non réservé peuvent sembler échappées; par exemple, certains des caractères "marque" non réservés sont automatiquement échappés par certains systèmes. Si le schéma d'URI donné définit un algorithme de canonisation, alors les caractères non réservés peuvent être non échappés selon cet algorithme. Par exemple, "% 7e" est parfois utilisé au lieu de "~" dans un chemin d'URL http, mais les deux sont équivalents pour une URL http.
Étant donné que le caractère de pourcentage "%" a toujours pour but réservé d'être l'indicateur d'échappement, il doit être échappé en tant que "% 25" afin d'être utilisé comme données dans un URI. Les implémenteurs doivent veiller à ne pas échapper ou à ne pas échapper la même chaîne plus d'une fois, car le fait de ne pas échapper une chaîne déjà non échappée peut entraîner une mauvaise interprétation d'un pourcentage de données comme un autre caractère échappé, ou vice versa dans le cas de l'échappement d'une chaîne déjà échappée.
La raison principale est essentiellement que échappe caractères à inclure dans l'URL de votre page Web.
Supposons qu'un utilisateur entre un champ de formulaire utilisateur sous la forme "& joe" et que nous souhaitons rediriger vers une page qui contient ce nom dans l'URL, en utilisant le codage d'URL, ce serait alors, par exemple:
localhost/index.php?name=%26joe //note how the ampersand is escaped
Si vous n'avez pas utilisé le codage url, vous vous retrouvez avec:
localhost/index.php?name=&joe
et que l'esperluette causerait toutes sortes d'imprévisibilité
Il existe des RFC ( http://www.faqs.org/rfcs/rfc1738.html et similaires) qui définissent le format des URL, et les développeurs de navigateurs/serveurs Web s'appuient sur cela comme standard pour interpréter les données. Si vous ne vous conformez pas, les résultats peuvent être imprévisibles.
L'URL HTTP a sa spécification et indique que pratiquement tous les caractères non latins doivent être encodés.
Deux raisons auxquelles je pouvais penser:
- Cela dépend vraiment de la façon dont vous analysez votre côté serveur de requêtes. Par exemple. le passage de paramètres à l'aide de la requête GET de HTTP aura des problèmes s'il y a des caractères comme
&à l'intérieur d'un paramètre. - Il vous permet de gérer les caractères non-ansi comme vous le souhaitez (vous dictez l'encodage). Sinon, le navigateur pourrait les passer dans un encodage aléatoire (ne pensez pas qu'il est vraiment défini dans une norme; corrigez-moi si je me trompe).
Comment allez-vous distinguer si vos deux chemins sont comme ça
http://myapp/my%20test/
et
http://myapp/my test/
Notez que l'espace &% 20 fait partie de l'URL.