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 du moteur de recherche optimisé et des URL conviviales apparaissent.

Je me demande s’il est préférable d’utiliser des lettres sans accent dans les URL – au risque que certains mots aient des significations complètement différentes avec et sans certains accents – ou il vaut mieux s’en tenir à l’utilisation de caractères non anglais il convient de sacrifier la lisibilité de ces URL dans des environnements moins avancés (par exemple, MSIE, vue source).

Les lettres “exotiques” peuvent apparaître n’importe où: dans les titres de 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.

Une approche possible serait bien sûr de configurer des URL alternatives – non accentuées – qui indiqueraient également la destination d’origine, mais j’aimerais connaître votre opinion sur l’utilisation des URL accentuées en tant qu’identificateurs de document principaux .

Face à un problème similaire, j’ai profité de la réécriture d’URL pour permettre à de telles pages d’être accessibles par le caractère accentué ou non accentué. L’URL actuelle 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’identificateur principal de ressource, je me limite à 0-9, AZ, az et au 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, mais uniquement ASCII.

Il en va tout autrement de la manière dont les navigateurs représentent les caractères encodés lors de l’affichage d’une URI. Par exemple, certains navigateurs affichent un espace dans une URL au lieu de «% 20». Voici comment fonctionnent les IDN: les chaînes codées sont encodées et décodées par les navigateurs à la volée. Si vous visitez café.com, vous visitez vraiment xn--caf-dma.com. Ce qui semble être des caractères unicodes dans les URL n’est en réalité qu’un «sucre visuel» de la part du navigateur: si vous utilisez un navigateur qui ne supporte pas l’IDN ou l’Unicode, la version codée ne fonctionnera pas. ne le supporte pas, donc pour qu’il fonctionne de manière cohérente, vous devez% encoder.

Considérer les URL avec des accents ont souvent tendance à ressembler à ceci:

 http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant 

… ce qui n’est pas si bien que je pense que nous utiliserons encore des URL sans accent 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 bien l’URL, et non pas avec% stuff, btw; cela semble être “nouveau” depuis Firefox 3.0 (voir Firefox 3: prise en charge UTF-8 dans la barre d’adresse ); donc, probablement pas supporté dans IE 6, du moins – et il y a encore trop de gens qui utilisent celui-ci 🙁

Peut-être que l’URL sans accent ne semble pas être la meilleure possible; mais, toujours, 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 URL qui peuvent être saisis manuellement dans le navigateur par les utilisateurs. C’est correct 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 manières et qu’il est très difficile de déterminer l’encodage utilisé. Voir ma question sur ce sujet,

Gestion de l’encodage des caractères dans l’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 clair 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. Qu’est-ce que l’encodage de ces octets est difficile à savoir (est interprété par le serveur http). La partie des parameters (après le premier?) Est transmise “tel quel” (après% XX unescapeing) à une 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 les non-ASCII (nous ne sums plus dans les années 80), mais exactement ce que vous faites avec cela pourrait être difficile. Essayez d’utiliser Unicode et éloignez-vous des anciennes pages de codes, étiquetez votre contenu avec le codage / jeu de caractères approprié si vous le pouvez (en utilisant méta en html, directives de langage pour asp / jsp, etc.)