Oser l'UTF-8

"Pourquoi encore s'obstiner à devoir remplacer des caractères accentués par des choses comme à, é, è ou & ? " Euh... pourquoi ne pas écrire simplement et avec iso-8859-1* ? C'est quoi cette mode WYSIWYG-ienne de coder tous les caractères "spéciaux" à coup d'entité.

Je m'en sors très bien en écrivant mes accents avec l'iso-8859-1

[#1] Ecrit le mardi 29 mars 2005 (19h12) par Olivier

Que je sache, l'usage des caractères spéciaux, accentués, etc... sans encodage est simplement supporté par les navigateurs afin de ne pas casser des tas de pages, mais que ce n'est pas vraiment la norme. En clair, c'est toléré mais pas plus. Conclusion, un internaute qui n'a pas *ton* charset aura des soucis. UTF8, c'est réglé, tout le monde l'a.

[#2] Ecrit le mardi 29 mars 2005 (20h09) par Cédric

Ahh... j'ai pourtant cru lire quelque part que justement le fait d'utiliser les entités été du fait de la mauvaise compréhension de l'encodage.

Normalement, quelque soit le navigateur client, quelque soit son encodage choisi, la page s'affiche avec l'encodage choisi lors de la création du document justement...

Sinon, le même problème se pose avec UTF-8, je suis en iso sur mon navigateur, alors ça va pas restituer l'utf... étrange comme raisonnement. Enfin, je veux bien te croire, j'ai pas une grande expérience dans le domaine, mais ça me parait TRES étrange. As tu des ressources à consulter ?

(Le filtre anti spam, faudrait peut être le documenter, parceque "compléter 'trente*cinq'", j'ai pas compris ce que ça voulais dire... c'est une devinette, une charade ? Obligé de reloader 3 fois la page pour trouver une question à laquelle je puisse répondre (je dois être atardé sur les bords... j'ai eu du mal à compter 30 fois 10... en base 10 ou 6 ? lol ;))

[#3] Ecrit le mardi 29 mars 2005 (20h38) par Olivier

> Que je sache, l'usage des caractères spéciaux, accentués, etc... sans encodage est simplement supporté par les > navigateurs afin de ne pas casser des tas de pages, mais que ce n'est pas vraiment la norme. > En clair, c'est toléré mais pas plus.

Au contraire. La norme HTTP définit clairement qu'un document texte est en ISO-8859-1 si rien ne spécifie le contraire. On peut donc tout à fait utiliser les accents sans les coder théoriquement, d'après la norme. Ce sont justement les navigateurs qui posent problèmes parfois alors qu'ils ne devraient pas, et qui ont incité la norme HTML à promouvoir l'utilisation d'un <meta> pour spécifier explicitement le codage caractère.

> Conclusion, un internaute qui n'a pas *ton* charset aura des soucis. UTF8, c'est réglé, tout le monde l'a.

bof, il y a plus de gens qui supportent l'ISO-8859-1 (souvent le défaut sur les protocoles réseaux et formats de données) que de gens qui supportent l'UTF-8.D'autant plus que l'UTF-8 pose plein de problèmes de compatibilité avec les applications qui ne sont pas prévues pour (le problème du "un caractère peut prendre plus d'un octet").

Le résultat c'est que quasi toutes les applications qui ont une connaissance du problème "jeu de caractères" savent utiliser l'ISO-8859-1, au pire elles sauront faire transiter la donnée sans la casser. Ce n'est pas vrai avec UTF-8.

D'ailleurs, puisqu'on en est à parler de ce genre de problèmes, conseiller UTF-8 en PHP c'est bien, mais n'oubliez pas qu'il vous faudra alors oublier les fonction strlen(), strpos() et une bonne partie de tout ce qui traite les chaines de caractères. Il vous faudra utiliser à la place les fonctions du module mbstring, qui malheureusement n'est pas si souvent intégré sur les hébergeurs (grand public ou professionnels). Il vous faudra aussi penser que certains caractères peuvent s'écrire de plusieurs manières (accent+lettre ou directement lettre accentuée) et donc qu'il vous faudra normaliser les chaines avant de pouvoir les convertir entre elles. Il vous faudra aussi penser à utiliser un support de stockage qui "comprend" UTF-8 pour que les tailles des chaînes et des données veuilles dire quelque chose (donc par exemple pas de mysql 3.23 ou mysql 4.0).

(ceci dit je vous conseille effectivement d'utiliser UTF-8 pour vos applications, ça vous évitera des prises de tête futures quand vous voudrez étendre votre application à l'international)

[#4] Ecrit le mardi 29 mars 2005 (20h44) par Eric Daspet

Ahh, Eric me rassure ^^ C'est bien ce que je pensais :D

[#5] Ecrit le mardi 29 mars 2005 (22h35) par Olivier

Faut-il conseiller l'UTF8 ? Je ne sais pas. Comme beaucoup, je me suis lancé à la découverte de l'UTF8 plus par curiosité que par nécessité.

Sur Uzine.net un article suggère que l'UTF-8 serait le mécanisme qu’il aurait fallu adopter dès le départ à la place de tous les autres jeux de caractères. Mais encore une fois, il s'agit d'un article rédigé par un non-spécialiste.

En attendant, de plus en plus d'applications proposent l'UTF8. Autant de raisons sans doute de oser s'y intéresser, quitte ensuite à s'en passer...

[#6] Ecrit le mardi 29 mars 2005 (22h40) par dash

UTF-8 c'est très simple en théorie. Les dizaines de miliers de glyphes disponibles en UTF-8 permettent de taper directement des caractères chinois, russes, arabes, japonais, norvégiens et même... français. C'est très pratique pour un site acceptant des entrées utilisateurs (commentaires, livre d'or...), ou pour quand les noms de domaines accentuées seront vraiment répandus.

UTF-8 ça se complique un peu dans la pratique. Tous les fichiers à inclure comprenant du texte à afficher sur le site : includes PHP, Javascript externes, et même CSS avec les pseudo-classes devront être encodés en UTF-8.

Il y également des détails à retenir concernant XHTML. Le prologue XML doit être ajouté si on utilise un encodage différent de UTF-8. Hors, ajouter le prologue XML fait baculer IE6 en mode quirks. Donc pour se passer du prologue (pour IE6) et rester "conforme" il faut utiliser UTF-8.

Comme souligné dans l'article il faut aussi faire attention au contenu de la base de données. J'ai fait l'expérience de passer une base ISO-8859-1 en UTF-8, j'ai du retaper tous les accents (en fait j'ai automatisé la procédure), car les "é" étaient devenus des "@A" ou quelque chose comme ça.

Il faut aussi savoir que Notepad et WordPad sous Windows ne supportent pas l'UTF-8, donc vous ne pourrez pas créer des documents UTF-8, et les documents UTF-8 ouverts avec ces logiciels afficheront mal les accents.

Ceci dit (il y aurait enore beaucoup à dire) je suis totallement conquis par UTF-8 et je suis certain que c'est une solution d'avenir (bien qu'elle ne soit pas nouvelle). Une fois que tout est en place, UTF-8 permet de ne plus jamais se soucier des accents ou caractères spéciaux.

De plus tous les navigateurs modernes (même IE5 si je ne m'abuse) supportent UTF-8.

[#7] Ecrit le jeudi 21 avril 2005 (15h12) par ghola

Et Unicode ? Il n'était pas sensé être là pour faire exactement la même chose ? La norme ISO-10646 à été créée pour ça, qu'est-ce que UTF-8 apporte de plus ? (j'ai dans mon éditeur de texte les fonctions de conversion Unicode -> UTF-8 et UTF-8 -> Unicode, donc apparemment ce n'est pas la même chose...)

[#8] Ecrit le lundi 30 mai 2005 (10h57) par fuzzy

@fuzzy:

UTF-8 *est* de l'unicode, c'est une des représentations possible de l'Unicode.

Unicode c'est une table (ou jeu) de caractères, une conversion lettre=>nombre, la liste des lettres/symboles dispo.

Après on utilise un codage caractère pour savoir comment stocker ces nombres en binaire. C'est important parce que dans la plupart des applications un octet avec uniquement des 0 est interdit dans une chaîne, donc on ne peut pas bêtement mettre tout sur X bits et concaténer. On a une forme qui utilise deux octets et qui s'appelle UTF16 (en fait deux formes, UTF16LE et UTF16BE), encore une qui code sur quatre octets (UTF-32, elle aussi avec deux variantes), et une qui code sur un nombre variable d'octets (UTF-8, de 1 à 6 octets). L'avantage de cette dernière c'est qu'elle est compatible ASCII, le défaut c'est que les caractères sont de taille variable.

[#9] Ecrit le mardi 31 mai 2005 (21h21) par Eric Daspet

UTF-8 est simplement une manière de coder l'Unicode par chunks de 8 bits. l'UTF-16 est bien aussi, bien que peu compatible avec les fichiers du web.
Dans les faits, quand vous codez en unicode, l'entité HTML &eacute; est traduite en Unicode; quand vous codez en ISO-8859-1, elle est traduite en ISO-8859-1. La notation "textuelle" a pour avantage de ne pas être dépendante de l'encodage que vous utilisez, et c'est justement pour cela que les gens la privilégient :).
En ce qui concerne le prologue, il peut autant être utilisé en UTF-8 qu'en UTF-16, et si IE ne le gère pas, c'est qu'il est mal codé: firefox rulez.
De plus il est possible d'utiliser les fonctions monooctets de PHP si et seulement si les chaines UTF-8 que vous passez ne contiennent pas de caractètes multioctets. UTF-8 est quand même conçu pour être compatible avec ASCII: profitez-en ce n'est pas le cas de UTF-16 ;)
C'était juste quelques mots sur UTF-8.

[#10] Ecrit le mardi 14 juin 2005 (14h39) par Valdo

Allez voir un excellent cours sur les caractères, avant de dire n'importe quoi : cherchez dans google "joelonsoftware" et sur son site (absolument génial de par sa simplicité), vous trouverez (dans les pages traduites en Français en plus), un cours expliquant qui vient de quoi et comment c'est géré.

[#11] Ecrit le mardi 28 mars 2006 (18h23) par Toutsimple

Jamais lu autant d'idioties, et écrire un tel article article sans la moindre connaissance du sujet est vraiment une preuve de stupidité caractérisée. Essayez d'ouvrir vos pages "utf-8" sur un mac par exemple, et regardez comment seront vos fameux caracteres accentués...

[#12] Ecrit le jeudi 08 juin 2006 (18h16) par Zazou

Grâce à l'UTF-8, terminé les &eacute; et autres &egrave; ! C'est quand même bien le progrès, non ?

c'est bien joli l'UTF8 mais dans ton exemple, moi je vois pas les accents mais des caracteres bizarres... preuve que c'est pas bien interprété partout

[#13] Ecrit le lundi 04 septembre 2006 (21h12) par jaye