Dois-je utiliser des caractères accentués dans les URLs?
Lorsqu'on crée du contenu web dans des langues différentes de l'anglais, le problème des URLs optimisées et conviviales apparaît.
je me demande si c'est la meilleure pratique d'utiliser des lettres sans accents dans les URLs -- au risque que certains mots aient des significations complètement différentes avec et sans certains accents -- ou il est préférable de s'en tenir à l'utilisation de caractères non-anglais là où approprié sacrifiant la lisibilité de ces URLs dans moins avancé environnements (par exemple MSIE, view source).
les lettres "exotiques" peuvent apparaître n'importe où: dans les titres des documents, dans les étiquettes, dans les noms d'utilisateur, etc, de sorte qu'ils ne sont pas toujours sous la supervision complète du responsable du site.
bien sûr, une approche possible serait de mettre en place des URLs alternatives -- sans accent -- qui indiqueraient aussi la destination originale, mais je voudrais apprendre vos opinions sur l'utilisation D'URLs accentuées comme identificateurs de documents primaires .
5 réponses
face à un problème similaire, j'ai profité de URL rewriting pour permettre à de telles pages d'être accessibles par le caractère accentué ou non. L'URL actuelle serait quelque chose comme
http://www.mysite.com/myresume.html
et une fonction de rewriting+character translating permet cette référence
http://www.mysite.com/myresumé.html
pour charger la même ressource. Alors pour répondre à votre question, comme la primaire ressource identificateur, je me limite à 0-9, A-Z, A-z et le trait d'Union occasionnel.
il n'y a pas d'ambiguïté ici: RFC3986 dit non , C'est-à-dire que URIs ne peut pas contenir de caractères unicode, seulement ASCII.
il en va tout autrement de la façon dont les navigateurs représentent les caractères encodés lorsqu'ils affichent une URI, par exemple certains navigateurs afficheront un espace dans une URL au lieu de '%20'. C'est aussi comme ça que fonctionne IDN: les chaînes punycoded sont encodées et décodées par les navigateurs à la volée, donc si vous visitez café.com tu es vraiment en visite. xn--caf-dma.com. Ce qui semble être des caractères unicode dans les URLs n'est en réalité que du "sucre visuel" de la part du navigateur: si vous utilisez un navigateur qui ne supporte pas IDN ou unicode, la version encodée ne fonctionnera pas parce que la définition sous-jacente des URLs ne le supporte tout simplement pas, donc pour qu'il fonctionne de manière cohérente, vous devez coder%.
considérant les URL avec des accents ont souvent tendance à ressembler à ceci:
http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
...ce qui n'est pas que belle... Je pense que nous utiliserons toujours des URLs sans accents pendant un certain temps.
Bien que, les choses devraient aller mieux, comme accentués Url sont maintenant reconnus par les navigateurs web, il me semble.
le firefox 3.5 que j'utilise actuellement affiche l'URL de la bonne façon, et pas avec %stuff, btw ; cela semble être "nouveau" depuis firefox 3.0 (voir Firefox 3: soutien UTF-8 dans la barre de localisation ); donc, pas probablement pas pris en charge dans IE 6, au moins -- et il y a encore beaucoup trop de personnes utilisant celui-ci: - (
Peut-être que les URL sans accent ne sont pas à la recherche du meilleur qui pourrait être ; mais, encore, les gens sont habitués à eux, et semblent généralement les comprendre assez bien.
vous devez éviter les caractères non-ASCII dans les URLs qui peuvent être entrés dans le navigateur manuellement par les utilisateurs. C'est ok pour les liens intégrés pré-encodés par le serveur.
nous avons découvert que le navigateur peut encoder L'URL de différentes façons et il est très difficile de comprendre ce encodage il utilise. Voir ma question à ce sujet,
Manipulation de l'Encodage des Caractères dans URI sur Tomcat
il y a plusieurs zones dans une URL complète, et chacune peut avoir des règles différentes. Le protocole est simple ASCII. L'entrée DNS est régie par les règles IDN (International Domain Names) et peut contenir (la plupart) des caractères Unicode. Le chemin (après le premier /), Le nom d'utilisateur et le mot de passe peuvent à nouveau être tout. Ils sont échappés (en tant que %XX), mais ce ne sont que des octets. Le codage de ces octets est difficile à connaître (il est interprété par le serveur http). Les paramètres de la partie (après la première ?) est passé "tel quel" (après la désescalade de %XX) à quelque chose d'application côté serveur (php, asp, jsp, cgi), et la façon dont cela interprète les octets est une autre histoire). Il est recommandé que le chemin/utilisateur/mot de passe/arguments soient utf-8, mais pas obligatoire, et tout le monde ne respecte pas cela.
donc vous devriez certainement tenir compte de non-ASCII (nous ne sommes plus dans les années 80), mais exactement ce que vous faites avec cela pourrait être délicat. Essayez D'utiliser Unicode et restez à l'écart du code d'héritage pages, marquez votre contenu avec le codage/jeu de caractères approprié si vous le pouvez (en utilisant meta en html, les directives de langue pour asp/jsp, etc.)