Dois-je utiliser des caractères accentués dans les URL?
Lorsque l'on crée du contenu Web dans des langues différentes de l'anglais, le problème des URL optimisées pour les moteurs de recherche et conviviales émerge.
Je me demande si c'est la meilleure pratique d'utiliser des lettres sans accentuation dans les URL - risquant que certains mots aient des significations complètement différentes avec et sans certains accents - ou s'il est préférable de s'en tenir à l'utilisation de caractères non anglais où sacrifier la lisibilité de ces URL dans des environnements moins avancés (par exemple MSIE, voir la source).
Les lettres "exotiques" peuvent apparaître n'importe où: dans les titres des documents, dans les balises, dans les noms d'utilisateur, etc., elles ne sont donc pas toujours sous la supervision complète du responsable du site Web.
Une approche possible serait bien sûr de configurer des URL alternatives - non accentuées - qui pointeraient vers la destination d'origine, mais je voudrais connaître votre opinion sur l'utilisation des URL accentuées comme primaire identificateurs de document.
Face à un problème similaire, j'ai profité de réécriture d'URL pour permettre à ces pages d'être accessibles par le caractère accentué ou non accentué. L'URL réelle serait quelque chose comme
http://www.mysite.com/myresume.html
Et une fonction de réécriture + traduction de caractères permet cette référence
http://www.mysite.com/myresumé.html
pour charger la même ressource. Donc, pour répondre à votre question, en tant qu'identifiant de ressource principal , 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 les URI ne peuvent pas contenir de caractères Unicode, seulement ASCII.
Une toute autre question est de savoir comment les navigateurs représentent les caractères codés lors de l'affichage d'un URI, par exemple, certains navigateurs afficheront un espace dans une URL au lieu de '% 20'. C'est aussi ainsi que fonctionne l'IDN: les chaînes codées sont codées et décodées par les navigateurs à la volée, donc si vous visitez café.com, vous visitez vraiment xn--caf-dma.com. Ce qui semble être des caractères unicode dans les URL n'est en réalité que du `` sucre visuel '' de la part du navigateur: si vous utilisez un navigateur qui ne prend pas en charge l'IDN ou l'unicode, la version codée ne fonctionnera pas car la définition sous-jacente des URL est simplement ne le prend pas en charge, donc pour qu'il fonctionne de manière cohérente, vous devez% encoder.
Considérer les URL avec des accents a souvent tendance à ressembler à ceci:
http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant
... ce qui n'est pas si gentil ... Je pense que nous utiliserons encore des URL sans accentuation pendant un certain temps.
Cependant, les choses devraient s'améliorer, car les URL accentuées sont désormais acceptées par les navigateurs Web, semble-t-il.
Le firefox 3.5 que j'utilise actuellement affiche l'URL de la bonne manière, et non avec% stuff, btw; cela semble être "nouveau" depuis firefox 3.0 (voir Firefox 3: support UTF-8 dans la barre d'emplacement ); donc, probablement pas pris en charge dans IE 6, au moins - et il y a encore beaucoup trop de gens qui utilisent celui-ci :-(
Peut-être que l'URL sans accent n'est pas la meilleure qui puisse être; mais, encore, les gens y sont habitués et semblent généralement bien les comprendre.
Vous devez éviter les caractères non ASCII dans les URL qui peuvent être saisies manuellement dans le navigateur 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 coder l'URL de différentes manières et il est très difficile de déterminer quel codage il utilise. Voir ma question à ce sujet,
Il y a plusieurs zones dans une URL complète, et chacune peut avoir des règles différentes. Le protocole est tout simplement 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 (comme% XX), mais ce ne sont que des octets. Quel est le codage de ces octets est difficile à savoir (est interprété par le serveur http). La partie paramètres (après le premier?) Est passée "telle quelle" (après% XX unescapeing) à quelque chose d'application côté serveur (php, asp, jsp, cgi), et comment cela interprète les octets est une autre histoire). Il est recommandé que le chemin/utilisateur/mot de passe/arguments soit utf-8, mais pas obligatoire, et tout le monde ne le respecte pas.
Donc, vous devriez certainement autoriser le 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 éloignez-vous des pages de code héritées, étiquetez votre contenu avec l'encodage/charset approprié si vous le pouvez (en utilisant la méta en html, les directives de langue pour asp/jsp, etc.)