Quelle est la bonne façon d'encoder les caractères Unicode par URL?

Je connais le schéma non standard% uxxxx mais cela ne semble pas être un choix judicieux puisque le schéma a été rejeté par le W3C.

Quelques exemples intéressants:

Le caractère du cœur. Si je tape ceci dans mon navigateur:

http://www.google.com/search?q=♥

Puis copiez et collez-le, je vois cette URL

http://www.google.com/search?q=%E2%99%A5

ce qui donne l'impression que Firefox (ou Safari) le fait.

urllib.quote_plus(x.encode("latin-1"))
'%E2%99%A5'

ce qui a du sens, sauf pour les choses qui ne peuvent pas être encodées en Latin-1, comme le caractère triple point.

…

Si je tape l'URL

http://www.google.com/search?q=…

dans mon navigateur puis copiez et collez, j'obtiens

http://www.google.com/search?q=%E2%80%A6

arrière. Ce qui semble être le résultat de

urllib.quote_plus(x.encode("utf-8"))

ce qui a du sens puisque… ne peut pas être encodé avec Latin-1.

Mais alors ce n'est pas clair pour moi comment le navigateur sait s'il doit décoder avec UTF-8 ou Latin-1.

Puisque cela semble ambigu:

In [67]: u"…".encode('utf-8').decode('latin-1')
Out[67]: u'\xc3\xa2\xc2\x80\xc2\xa6'

fonctionne, donc je ne sais pas comment le navigateur détermine s'il faut décoder cela avec UTF-8 ou Latin-1.

Quelle est la bonne chose à faire avec les caractères spéciaux avec lesquels je dois traiter?

Je coderais toujours en UTF-8. À partir de la page Wikipedia sur l'encodage en pourcentage :

La syntaxe générique d'URI exige que les nouveaux schémas d'URI qui fournissent la représentation des données de caractère dans un URI doivent, en effet, représenter les caractères de l'ensemble non réservé sans traduction, et doivent convertir tous les autres caractères en octets selon UTF-8, puis encodez en pourcentage ces valeurs. Cette exigence a été introduite en janvier 2005 avec la publication de la RFC 3986 . Les schémas d'URI introduits avant cette date ne sont pas affectés.

Il semble que, comme il y avait d'autres méthodes acceptées d'encodage d'URL dans le passé, les navigateurs tentent plusieurs méthodes de décodage d'un URI, mais si c'est vous qui faites l'encodage, vous devriez utiliser UTF-8.

La règle générale semble être que les navigateurs encodent les réponses au formulaire en fonction du type de contenu de la page à partir de laquelle le formulaire a été diffusé. C'est une supposition que si le serveur nous envoie "text / xml; charset = iso-8859-1", alors il attend des réponses dans le même format.

Si vous entrez simplement une URL dans la barre d'URL, le navigateur n'a pas de page de base sur laquelle travailler et n'a donc qu'à deviner. Donc, dans ce cas, il semble faire utf-8 tout le temps (puisque vos deux entrées ont produit des valeurs de forme de trois octets).

La triste vérité est qu'AFAIK il n'y a pas de norme pour quel jeu de caractères les valeurs d'une chaîne de requête, ou en fait les caractères de l'URL, doivent être interprétés comme. Au moins dans le cas des valeurs dans la chaîne de requête, il n'y a aucune raison de supposer qu'ils nécessairement faire correspondent aux caractères.

Il est un problème connu que vous devez dire à votre cadre de serveur qui le caractère que vous définissez vous attendez la chaîne de requête à coder comme --- par exemple, dans Tomcat, vous devez appeler request.setEncoding () (ou une méthode similaire) avant que vous appelez l'une des méthodes request.getParameter (). Le manque de documentation sur ce sujet reflète probablement le manque de conscience du problème chez de nombreux développeurs. (Je demande régulièrement aux interviewés Java quelle est la différence entre un Reader et un InputStream, et j'ai régulièrement des regards vides)

IRI ( RFC 3987 ) est la dernière norme qui remplace les normes URI / URL ( RFC 3986 et plus anciennes). URI / URL ne prend pas en charge nativement Unicode (enfin, la RFC 3986 ajoute des dispositions pour les futurs protocoles basés sur URI / URL pour la prendre en charge, mais ne met pas à jour les RFC passées). Le schéma "% uXXXX" est une extension non standard pour autoriser Unicode dans certaines situations, mais n'est pas universellement implémenté par tout le monde. IRI, d'autre part, prend entièrement en charge Unicode et nécessite que le texte soit encodé en UTF-8 avant d'être ensuite encodé en pourcentage.

Les IRI ne remplacent pas les URI, car seuls les URI (en fait, ASCII) sont autorisés dans certains contextes, y compris HTTP.

Au lieu de cela, vous spécifiez un IRI et il est transformé en URI lors de la sortie sur le fil.

La première question est quels sont vos besoins? L'encodage UTF-8 est un assez bon compromis entre la prise de texte créé avec un éditeur bon marché et la prise en charge d'une grande variété de langues. En ce qui concerne le navigateur identifiant le codage, la réponse (du serveur Web) doit indiquer au navigateur le codage. Pourtant, la plupart des navigateurs tenteront de deviner, car cela est manquant ou erroné dans de nombreux cas. Ils devinent en lisant une partie du flux de résultats pour voir s'il y a un caractère qui ne rentre pas dans l'encodage par défaut. Actuellement, tous les navigateurs (? Je n'ai pas vérifié cela, mais c'est assez proche de vrai) utilisent utf-8 par défaut.

Utilisez donc utf-8 à moins que vous n'ayez une raison impérieuse d'utiliser l'un des nombreux autres schémas d'encodage.