Dois-je utiliser de caractères accentués dans les Url?

Question

Quand on crée du contenu web dans des langues différentes de l'anglais au problème de moteur de recherche optimisé et convivial Url émerger.

Je me demande si c'est la meilleure pratique consiste à utiliser de caractères accentués dans les Url -- risquer que certains mots ont un sens complètement différent avec et sans certains accents -- ou il est préférable de s'en tenir à l'utilisation de caractères non anglais le cas échéant sacrifier la lisibilité de ces Url en moins avancés environnements (par exemple, MSIE, afficher la source).

"Exotiques", les lettres apparaissent n'importe où: dans les titres des documents, des étiquettes, dans les noms d'utilisateur, etc, de sorte qu'ils ne sont pas toujours sous la supervision complète du responsable du site.

Une approche possible serait d'être suppléant -- non accentuées -- Url en tant que bien qui serait le point de destination d'origine, mais je voudrais savoir votre avis sur l'utilisation de accentués Url en tant que principal des identifiants de documents.

Answer 1

Il n'y a pas d'ambiguïté ici: RFC3986 dit pas, c'est Uri ne peut pas contenir de caractères unicode, seulement ASCII.

Une question entièrement différente est la manière dont les navigateurs représentent des caractères encodés lors de l'affichage d'un URI, par exemple, certains navigateurs afficheront un espace dans l'URL au lieu de '%20'. C'est de cette façon IDN marche aussi: punycoded les chaînes de caractères sont codés et décodés par les navigateurs à la volée, donc si vous visitez café.com, vous êtes vraiment la visite xn--caf-dma.com. Ce qui semble être des caractères unicode dans les Url est vraiment seulement visuel de sucre " de la part du navigateur: si vous utilisez un navigateur qui ne supporte pas les IDN ou unicode, la version encodée ne fonctionnera pas parce que la définition de l'Url tout simplement ne le supporte pas, donc pour qu'il fonctionne de manière cohérente, vous avez besoin d' % de l'encodage.

Answer 2

Lorsqu'ils sont confrontés à un problème similaire, j'ai profité de la réécriture d'URL pour permettre à ces pages pour être accessible par les accents ou de caractères non accentués. L'URL réelle serait quelque chose comme

http://www.mysite.com/myresume.html

Et une réécriture de caractère+la traduction de fonction permet à cette référence

http://www.mysite.com/myresumé.html

pour charger la même ressource. Donc, pour répondre à votre question, comme le principal identificateur de ressource, je me limiterai à l'0-9, A-Z, a-z et, à l'occasion de trait d'union.

Answer 3

Compte tenu des Url avec des accents souvent tendance à finir par ressembler à cela :

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

...ce qui n'est pas agréable... je pense que nous serons toujours à l'aide de accentués Url pour un certain temps.

Cependant, les choses devraient aller mieux, comme accentués Url sont maintenant reconnus par les navigateurs web, il me semble.

Firefox 3.5, je suis actuellement à l'aide affiche l'URL de la belle manière, et non pas avec de l' %trucs, d'ailleurs ; ce qui semble être la "nouvelle" depuis firefox 3.0 (voir Firefox 3: support UTF-8 dans la barre d'adresse) ; donc, pas probablement pas pris en charge dans IE 6, au moins -- et il y a encore pas trop de gens à l'aide de celui-ci :-(

Peut-être que l'URL sans les accents ne sont pas à la recherche du meilleur qui puisse être ; mais, la encore, les gens sont habitués à eux, et semblent généralement les comprendre assez bien.

Answer 4

Vous devriez éviter les caractères non-ASCII dans les Url qui peut être saisi dans le navigateur manuellement par les utilisateurs. C'est ok pour les liens profonds pré-codée par le serveur.

Nous avons constaté que le navigateur peut encoder l'URL de différentes façons et il est très difficile de comprendre à quel encodage il utilise. Voir ma question sur ce problème,

http://stackoverflow.com/questions/1233076/handling-character-encoding-in-uri-on-tomcat

Answer 5

Il y a plusieurs zones dans une URL complète, et chacun pouvait a des règles différentes. Le protocole ASCII. L'entrée DNS est régie par IDN (Noms de Domaine International) des règles, et peut contenir (la plupart) des caractères Unicode. Le chemin d'accès (après le premier /), le nom d'utilisateur et le mot de passe peut de nouveau être tout. Ils se sont échappés (en %XX), mais ce sont juste des octets. Qu'est-ce que l'encodage de ces octets est difficile de savoir (est interprété par le serveur http). Les paramètres de la partie (après le premier ?) est passé "comme il est" (après l' %XX unescapeing) pour certaines application côté serveur chose (php, asp, jsp, cgi), et comment interpréter les octets est une autre histoire). Il est recommandé que le chemin d'accès/utilisateur/mot de passe/les arguments sont en utf-8, mais pas obligatoire, et pas tout le monde le respecte.

Donc, vous devriez certainement permettre aux non-ASCII (nous ne sommes pas dans les années 80 plus), mais exactement ce que vous faites avec ce peut être difficile. Essayez d'utiliser Unicode et de rester loin de l'héritage des pages de code, de marquer votre contenu avec le bon encodage/charset si vous le pouvez (à l'aide de meta dans le code html, le langage des directives asp/jsp, etc.)