Caractères Unicode dans les URL


135

En 2010, diffuseriez-vous des URL contenant des caractères UTF-8 dans un grand portail Web?

Les caractères Unicode sont interdits selon la RFC sur les URL (voir ici ). Ils devraient être codés en pourcentage pour être conformes aux normes.

Mon point principal, cependant, est de servir les caractères non codés dans le seul but d'avoir de belles URL, donc le codage en pourcentage est éliminé.

Tous les principaux navigateurs semblent analyser ces URL, peu importe ce que dit la RFC. Mon impression générale, cependant, est que cela devient très instable lorsque vous quittez le domaine des navigateurs Web:

  • URL à copier-coller dans des fichiers texte, des courriels, même des sites Web avec un codage différent
  • Bibliothèques clientes HTTP
  • Navigateurs exotiques, lecteurs RSS

Mon impression est-elle correcte qu'il faut s'attendre à des problèmes ici, et donc ce n'est pas (encore) une solution pratique si vous servez un public non technique et qu'il est important que tous vos liens fonctionnent correctement même s'ils sont cités et transmis?

Existe-t-il un moyen magique de proposer de jolies URL en HTML?

http://www.example.com/düsseldorf?neighbourhood=Lörick

qui peut être copié + collé avec les caractères spéciaux intacts, mais fonctionne correctement lorsqu'il est réutilisé dans des clients plus anciens?


16
De son côté, Firefox affiche les caractères Unicode dans sa barre d'URL mais les envoie au serveur en pourcentage encodé. De plus, lorsqu'un utilisateur copie l'URL de la barre d'URL, Firefox s'assure que l'URL codée en pourcentage est copiée dans le presse-papiers.
Siddhartha Reddy

Réponses:


126

Utilisez le codage en pourcentage. Les navigateurs modernes prendront en charge les problèmes d'affichage et de collage et le rendront lisible par l'homme. Par exemple. http://ko.wikipedia.org/wiki/ 위키 백과: 대문

Edit: lorsque vous copiez une telle URL dans Firefox, le presse-papiers contiendra la forme codée en pourcentage (ce qui est généralement une bonne chose), mais si vous n'en copiez qu'une partie, elle restera non codée.


Wow, en fait tu as raison! Si vous coupez et collez une URL codée en%, Firefox la transformera en la bonne chose pour l'affichage.
Dean Harding

Wow, je n'étais pas au courant de ça. Il y a de fortes chances que ce soit la meilleure solution!
Pekka

33
@Dean c'est un changement assez récent - en 2005, tous les wikipédias internationaux ressemblaient à un vrai% 6D% 65% 73% 73.
Roman Starkov le

2
Vous pouvez désormais utiliser les URL UTF-8 non codées, à savoir les IRI , dans les documents HTML5 . Si vous faites cela, tous les principaux navigateurs le comprendront et l'afficheront correctement dans leur barre d'adresse.
Oliver

À quels octets les navigateurs modernes envoient-ils aux serveurs de la ligne de requête GET /images/logo.png HTTP/1.1? Encodent-ils toujours l'URL en pourcentage?
Flimm le

87

Ce que Tgr a dit. Contexte:

http://www.example.com/düsseldorf?neighbourhood=Lörick

Ce n'est pas un URI. Mais il est un IRI .

Vous ne pouvez pas inclure un IRI dans un document HTML4; le type d'attributs comme hrefest défini comme URI et non IRI. Certains navigateurs gèrent de toute façon un IRI ici, mais ce n'est pas vraiment une bonne idée.

Pour encoder un IRI dans un URI, prenez le chemin et les parties de requête, encodez-les en UTF-8 puis encodez en pourcentage les octets non ASCII:

http://www.example.com/d%C3%BCsseldorf?neighbourhood=L%C3%B6rick

S'il y a des caractères non ASCII dans la partie nom d'hôte de l'IRI, par exemple. http://例え.テスト/, ils ont été encodés en utilisant Punycode à la place.

Vous avez maintenant un URI. C'est un URI laid. Mais la plupart des navigateurs cacheront cela pour vous: copiez-le et collez-le dans la barre d'adresse ou suivez-le dans un lien et vous le verrez s'afficher avec les caractères Unicode d'origine. Wikipédia l'utilise depuis des années, par exemple:

http://en.wikipedia.org/wiki/ɸ

Le seul navigateur dont le comportement est imprévisible et n'affiche pas toujours la jolie version IRI est ...

...bon tu sais.


31
Je connais. Un jour, quelqu'un doit prendre un grand club et frapper ces développeurs Lynx sur la tête. Merci pour l'excellente information de fond.
Pekka

2
@bobince Et le seul bot (avance rapide jusqu'en 2013) qui ne peut pas non plus gérer les URI non IRI est ... ... eh bien, vous savez: bingbot! Allez comprendre.
Tom Harrison

1
HTML5 prend enfin en charge les IRI. Plus d'informations sur le sujet peuvent être trouvées dans cette réponse à une question connexe .
Oliver

5
Re: IE n'affiche pas toujours de jolis IRI - ils protègent les utilisateurs contre les attaques de phishing basées sur les homographes. Consultez w3.org/International/articles/idn-and-iri (en particulier la section «Noms de domaine et phishing») et blogs.msdn.com/b/ie/archive/2006/07/31/684337.aspx
codingoutloud

2
Les noms de domaine n'ont rien à voir avec cela. Tous les navigateurs interdisent un large éventail de caractères pour empêcher le phishing. L'affichage de caractères non ASCII dans le chemin ou la partie de chaîne de requête ne crée pas une vulnérabilité similaire. IE n'a tout simplement pas pris la peine de l'implémenter. (Et Firefox est le seul qui l'a implémenté également pour la partie fragment.)
Tgr

16

En fonction de votre schéma d'URL, vous pouvez rendre la partie encodée UTF-8 "non importante". Par exemple, si vous regardez les URL de Stack Overflow, elles se présentent sous la forme suivante:

http://stackoverflow.com/questions/2742852/unicode-characters-in-urls

Cependant, le serveur ne se soucie pas vraiment si vous obtenez la partie après l'identifiant incorrect, donc cela fonctionne également:

http://stackoverflow.com/questions/2742852/ こ れ は 、 こ れ を 日本語 の テ キ ス ト で す

Donc, si vous aviez une mise en page comme celle-ci, vous pourriez potentiellement utiliser UTF-8 dans la partie après l'identifiant et cela n'aurait pas vraiment d'importance s'il était déformé. Bien sûr, cela ne fonctionne probablement que dans des circonstances quelque peu spécialisées ...


Hmmm, réflexion très intelligente! Il pourrait encore que certains clients étouffent sur les personnages , peu importe où ils se trouvent dans la chaîne, mais il serait d' éliminer tous les problèmes avec garbling ordinaire quand copier + coller une URL, qui je pense est la partie la plus importante. Je n'avais pas encore regardé l'URL de SO de cette façon. Merci!
Pekka

Eh bien, cela laisse toujours le mot "questions" non traduit, en plus il y a des trucs après le hash #, qui suit toute l'url, très belle astuce cependant !!
Evgeny

4
自動 翻 訳 機 を 使 っ て そ の 日本語 の URL を 作 っ た ね。
Glutexo

6

Je ne sais pas si c'est une bonne idée, mais comme mentionné dans d'autres commentaires et tel que je l'interprète, de nombreux caractères Unicode sont valides dans les URL HTML5 .

Par exemple, les hrefdocuments disent http://www.w3.org/TR/html5/links.html#attr-hyperlink-href :

L'attribut href sur les éléments a et area doit avoir une valeur qui est une URL valide potentiellement entourée d'espaces.

Ensuite, la définition de «URL valide» pointe vers http://url.spec.whatwg.org/ , qui définit les points de code URL comme:

ASCII alphanumérique, "!", "$", "&", "'", "(", ")", "*", "+", ",", "-", ".", "/" , ":", ";", "=", "?", "@", "_", "~" et les points de code dans les plages U + 00A0 à U + D7FF, U + E000 à U + FDCF , U + FDF0 à U + FFFD, U + 10000 à U + 1FFFD, U + 20000 à U + 2FFFD, U + 30000 à U + 3FFFD, U + 40000 à U + 4FFFD, U + 50000 à U + 5FFFD, U +60000 à U + 6FFFD, U + 70000 à U + 7FFFD, U + 80000 à U + 8FFFD, U + 90000 à U + 9FFFD, U + A0000 à U + AFFFD, U + B0000 à U + BFFFD, U + C0000 à U + CFFFD, U + D0000 à U + DFFFD, U + E1000 à U + EFFFD, U + F0000 à U + FFFFD, U + 100000 à U + 10FFFD.

Le terme "points de code URL" est alors utilisé dans quelques parties de l'algorithme d'analyse, par exemple pour l' état du chemin relatif :

Si c n'est pas un point de code URL et non "%", une erreur d'analyse.

De plus, le validateur http://validator.w3.org/ passe pour les URL comme "你好", et ne passe pas pour les URL avec des caractères comme des espaces"a b"

Connexes: quels caractères rendent une URL invalide?


Mais les deux URL ( "你好"et "a b") doivent être codées en pourcentage lors de la demande HTTP, n'est-ce pas?
Utku

@Utku pour "a b"je suis presque sûr que oui car l'espace n'est pas dans la liste autorisée ci-dessus. Car "你好"c'est certainement la meilleure idée d'encoder en pourcentage, mais je ne sais pas si c'est juste une question de "les implémentations ne sont pas assez bonnes" ou si le "standard le dit". La norme HTML semble autoriser ces caractères. Mais je pense que cela est spécifié par la norme HTTP, pas par HTML. Voir aussi: stackoverflow.com/questions/912811/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Oui, je pensais au standard HTTP, pas au HTML.
Utku

5

Comme tous ces commentaires sont vrais, vous devez noter qu'en ce qui concerne les caractères arabes (persans) et chinois approuvés par l' ICANN pour être enregistrés comme nom de domaine, toutes les sociétés de création de navigateurs (Microsoft, Mozilla, Apple, etc.) doivent prend en charge Unicode dans les URL sans aucun encodage, et celles-ci devraient être consultables par Google, etc.

Donc, ce problème sera résolu dès que possible.


2
@Nasser: Vrai - nous avons aussi des caractères spéciaux dans les domaines allemands maintenant - mais ceux-ci sont encodés en caractères ASCII en utilisant Punycode . Bien qu'ils soient sûrs de fonctionner dans les principaux navigateurs, il faudra beaucoup de temps avant que chaque bibliothèque cliente HTTP et application exotique ne puisse gérer les caractères Unicode non codés.
Pekka

@Pekka, je ne suis pas sûr, mais comme je l'ai entendu, tous les navigateurs doivent prendre en charge l'URL Unicode au 4ème trimestre 2010. (Je ne suis pas sûr)
Nasser Hadjloo

Le problème est compliqué par le fait que tous les agents utilisateurs ne sont pas des navigateurs Web. Le plus grand exemple est Google lui-même: il n'utilise pas de navigateurs Web courants pour effectuer son exploration. Il en serait de même pour de nombreuses bibliothèques pour l'interaction API, etc., etc. - Les URL sont presque littéralement partout, pas seulement sur le WWW. Probablement même sur votre système de fichiers en ce moment.
Cornelius

1

Utilisez une forme codée en pourcentage . Certains ordinateurs (principalement anciens) exécutant Windows XP par exemple ne prennent pas en charge Unicode, mais plutôt des encodages ISO. C'est la raison pour laquelle les URL codées en pourcentage ont été inventées. De plus, si vous donnez une URL imprimée sur papier à un utilisateur, contenant des caractères qui ne peuvent pas être facilement saisis, cet utilisateur peut avoir du mal à le saisir (ou simplement l'ignorer). La forme codée en pourcentage peut même être utilisée dans la plupart des machines les plus anciennes qui aient jamais existé (bien qu'elles ne prennent pas en charge Internet bien sûr).

Il y a cependant un inconvénient, car les caractères codés en pourcentage sont plus longs que les caractères originaux, ce qui peut entraîner des URL très longues. Mais essayez simplement de l'ignorer ou utilisez un raccourcisseur d'URL (je recommanderais goo.gl dans ce cas, ce qui crée une URL de 13 caractères). De plus, si vous ne souhaitez pas vous inscrire à un compte Google, essayez bit.ly (bit.ly crée des URL légèrement plus longues, avec une longueur de 14 caractères).


Pourquoi voudrais-je prendre en charge les ordinateurs obsolètes qui utilisent toujours Windows XP?
Mateus Felipe le

0

Pour moi, c'est la bonne façon, cela a juste fonctionné:

    $linker = rawurldecode("$link");
    <a href="<?php echo $link;?>"   target="_blank"><?php echo $linker ;?></a>

Cela a fonctionné, et maintenant les liens s'affichent correctement:

http://newspaper.annahar.com/article/121638 -معرض - جوزف-حرب-في-غاليري-جانين-ربيز-لوحاته-الجدية-تبحث-وتكتشف-وتفامض-الاحته

Lien trouvé sur:

http://www.galeriejaninerubeiz.com/newsite/news


2
"les liens sont affichés correctement" - sauf que l'analyseur de démarques StackOverflow n'interprète pas les URL comme prévu!
MrWhite
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.