1630 sujets

Formats, encodage, internationalisation, XML

En 2014, faut il absolument convertir son site en UTF-8 ?

Salut à tous

J'ai un site web depuis maintenant 17 ans. Une bonne communauté. Le principal est du fait maison, et même du fait main. Site très rapide, qui ferait surement peur à un professionnel de la profession à l'examen du code (le modèle MVC moi par exemple ...) mais ça marche super et je m'amuse bien avec ça.

Alors, pourquoi ouvrir ce post ?
Pace que je me rends compte qu'avec spip, seul module de mon site qui n'est pas de moi et qui me permet de gérer toute une rubrique documentation, je me heurte à de petits soucis. Je suis en en encodage latin et quand par exemple un contributeur copie-colle son texte depuis word, il va se retrouver à l'édition suivante avec pas mal de trucs convertis en entités html. Moi ça ne me dérange pas, mais pour les non-initiés, ça surprend un peu ... Et pour le reste, c’est parfois pareil … ponctuellement je me heurte à de petites choses, toujours contournables, mais quand même … (par exemple les lettres grecques ou certains caractères particuliers)

J'ai beaucoup potassé ces dernières semaines. Je suis au top sur l’update apache / mysql et j'ai même écrit un script bash qui en une commande me convertirait toutes mes bases, tous mes fichiers iso->UTF8.
Là on croit que le boulot est fait quand on a lu les principaux tuto du web qui sortent sur une recherche google.
Et puis on fait un essai sur un site mineur autre et on se rend compte que ça beurre ... certaines fonctions ne répondant plus pareils ...
On fouille on fouille et on tombe alors sur ce bijou d'article : http://www.julp.fr/articles/3-php-et-utf-8.html
(aucun formulaire de contact sur ce site qui est brillantissime, si l'auteur à tout hasard lit ces lignes alors qu'il reçoive ma reconnaissance éternelle !)
Et là on en prend plein la tronche parce qu'on se rend compte que les tuto simplistes sur le sujet parlent de tout sauf de l'essentiel : les dizaines de fonctions touchant aux chaines de caractère et qui ne vont plus réagir comme il faut pour la plupart ...

Vous imaginez donc que ça refroidit. D'où la question en titre de ce message.
Peut-on en 2014 penser continuer encore longtemps avec un site encodé en Latin ?
Faut il faire l’effort (majeur) de reprendre tout son site pour passer en UTF-8 en se disant que cela sera fait et plus à faire ?
J’avoue que j’ai envie de me lancer, mais je sais qu’imparablement ou presque je vais introduire qqs bugs qui parfois ne me seront remontés que tardivement, même si j’essaye de faire ça avec la plus grande rigueur !

Merci pour votre avis, j’ai vraiment besoin de recueillir l’opinion de pro ou semi pro sur le sujet !

B.
J'ai été longtemps contre UTF-8 justement à cause du passage potentiellement douloureux que ça pouvait représenter. ET puis, si on fait les choses de base bien scrupuleusement dans l'ordre, ça se passe assez bien et sans heurs finalement.

L'article que du cites est une mine d'or, il y a plein de choses que je ne fais toujours pas correctement...

Mon point de vue sur la question est le suivant. à preuve du contraire, tous les navigateurs majeurs supportent encore parfaitement les encodages ISO-8859-X. Tant qu'on n'a pas besoin des apports spécifiques d'UTF-8 (en gros, multilinguisme hors europe de l'ouest), qu'on reste cohérent et qu'on ne commence pas de mélanger de l'ISO et de l'UTF-8 et de faire des conversions à tout bout de champ parce que telle ou telle fonction attend et retourne obligatoirement de l'UTF-8 alors que telle autre veut de l'ISO par exemple, alors il n'y a à mon avis pas de problème à rester en ISO.

Par contre, il y a quelques pièges bonus qui ne sont pas abordés dans l'article, et que j'ai déjà pu constater, quand on commence à s'amuser avec AJAX: certains navigateurs, en particulier IE, ont tendance à vouloir forcer l'UTF-8 dans certaines situations, quand bien même on spécifie correctement les encodages dans les en-têtes aussi bien côté client que côté serveur. ET parfois, ça ne se limite pas seulement à des "é" ou des "?" parasites mais ça conduit carrément à l'ignoreance ou l'échec de réception des requêtes, et sans avoir de messages d'erreurs clairs voire même pas d'erreur du tout. Donc si tu prévois d'utiliser intensivement AJAX, tu t'attireras beaucoup moins les foudres des navigateurs et tu t'épargneras des débogages fastidieux si tu optes pour UTF-8.

En fait, c'est en partie devant les problèmes insolubles que j'ai eu à cause d'AJAX en ISO que j'ai fini par plier et que je suis passé à UTF-8.
QuentinC a écrit :
J'ai été longtemps contre UTF-8 justement à cause du passage potentiellement douloureux que ça pouvait représenter. ET puis, si on fait les choses de base bien scrupuleusement dans l'ordre, ça se passe assez bien et sans heurs finalement.

L'article que du cites est une mine d'or, il y a plein de choses que je ne fais toujours pas correctement...

Mon point de vue sur la question est le suivant. à preuve du contraire, tous les navigateurs majeurs supportent encore parfaitement les encodages ISO-8859-X. Tant qu'on n'a pas besoin des apports spécifiques d'UTF-8 (en gros, multilinguisme hors europe de l'ouest), qu'on reste cohérent et qu'on ne commence pas de mélanger de l'ISO et de l'UTF-8 et de faire des conversions à tout bout de champ parce que telle ou telle fonction attend et retourne obligatoirement de l'UTF-8 alors que telle autre veut de l'ISO par exemple, alors il n'y a à mon avis pas de problème à rester en ISO. L'important, c'est surtout d'être cohérent et constant sur toute la ligne d'un bout à l'autre.

Par contre, il y a quelques pièges bonus qui ne sont pas abordés dans l'article, et que j'ai déjà pu constater, quand on commence à s'amuser avec AJAX: certains navigateurs, en particulier IE, ont tendance à vouloir forcer l'UTF-8 dans certaines situations, quand bien même on spécifie correctement les encodages dans les en-têtes aussi bien côté client que côté serveur. ET parfois, ça ne se limite pas seulement à des "é" ou des "?" parasites mais ça conduit carrément à l'ignoreance ou l'échec de réception des requêtes, et sans avoir de messages d'erreurs clairs voire même pas d'erreur du tout. Donc si tu prévois d'utiliser intensivement AJAX, tu t'attireras beaucoup moins les foudres des navigateurs et tu t'épargneras des débogages fastidieux si tu optes pour UTF-8.

En fait, c'est en partie devant les problèmes insolubles que j'ai eu à cause d'AJAX en ISO que j'ai fini par plier et que je suis passé à UTF-8.
Merci pour ton avis !
Je n’arrête pas de cogiter là dessus. J'ai le sentiment que je dois y aller, que plus j'attends, plus ca va être complexe et plus je vais me heurter à une succession de petites choses en me disant sans cesse "là en UTF8 y'aurait pas de pb" ...

As tu des conseils sur la méthode pour ne pas se planter (je parle principalement sur la question des fonctions agissant sur les chaines de caractère) ?
J'ai envisagé 2 solutions :
- un remplacement automatique de toutes les fonctions posant problème qui ont des équivalent mb_* et une reprise manuelle pour ce qui n'a pas d'équivalent.
- un remplacement automatique de toutes les fonctions sur les chaines de caractères avec une fonctions maison genre perso_str_replace(), ce qui aurait l'avantage par exemple de ne pas m'obliger à choisir tout de suite certains points et de pouvoir évoluer plus facilement (je pense par exemple aux fonctions grapheme_ )

La seconde option est plutôt chronophage et ne sert peut être pas à grand chose car on ne change pas si souvent Smiley cligne
Enfin derniers points si tu as une expérience là dessus, faut il s'attendre à de nombreux problème avec les preg_ ? J'ai bien compris qu'il fallait ajouter en fin de motif le u mais cela est il suffisant ?

Merci

B.
Modérateur
Bonjour,

Je conseille de passer en utf-8 pour l'encodage des pages pour commencer (l'encodage doit donc être utf-8 ET les fichiers HTML/php doivent être enregistré en utf-8).

Pour le reste (base de données, noms de fichier, scripts, ...) ça peut être fait au cas par cas. Souvent, il n'y a que quelques bricoles à rajouter pour que la sortie s'affiche correctement en utf-8 sans avoir besoin de toucher à ce reste. Mais évidemment, si on fait tout en utf-8, c'est mieux.

A noter que la plupart des fonctions de php de traitement de chaines de caractères ne sont pas en utf-8. Ça ne les empêche pas de fonctionner la plupart du temps (en gros, si le texte qu'on traite est en utf-8, mais ne contient que des caractères latins, ça marchera sans qu'on ait quoique ce soit à modifier).

Amicalement,
parsimonhi a écrit :
Bonjour,

Je conseille de passer en utf-8 pour l'encodage des pages pour commencer (l'encodage doit donc être utf-8 ET les fichiers HTML/php doivent être enregistré en utf-8).

Pour le reste (base de données, noms de fichier, scripts, ...) ça peut être fait au cas par cas.


Merci pour ton avis.
Je ne suis pas certain de comprendre la différence à faire entre "fichiers HTML/php doivent être enregistré en utf-8" et " le reste (base de données, noms de fichier, scripts, ...) ça peut être fait au cas par cas".

Si ton fichier php est enregistré utf-8 alors tu tombes direct dans le souci des fonctions de chaine de caractère, non ?
Et si on en est là, alors mieux vaut surement aussi avoir sa base en utf-8 sinon c'est le jonglage permanent entre les charsets non ?

B.
Modérateur
Bonjour,

Si par exemple ta base est en latin1 et que ta page est en utf-8 (ce qui veut dire que tu as un <meta charset="UTF-8"> dans la partie head de ta page, ou tout autre équivalent pour indiquer au navigateur qu'il reçoit du utf-8), tu peux très bien afficher un contenu extrait de ta base dans ta page sans avoir à changer l'encodage de ta base elle-même (par exemple en rajoutant des mb_convert_encoding() dans ton code php). C'est en ce sens que je dis que c'est du cas par cas : il peut être plus simple de rajouter quelques mb_convert_encoding() juste avant affichage dans la page plutôt que de changer l'encodage de la base (et peut-être aussi certaines requêtes SQL).

En ce qui concerne le traitement des chaines de caractères lui-même, si par exemple on considère la chaine "réussi" : encodée en latin1, strlen("réussi") renvoie 6, et encodée en utf-8, strlen("réussi") renvoie 7. Est-ce que ça va boguer ensuite ? Ca dépend de ce qu'on fait. Au pire, on peut toujours remplacer les strlen() par des mb_strlen() ici et là.

Concernant le jonglage permanent entre les charsets, même si ta base en utf-8, et même si tes scripts php sont encodés en utf-8, ce n'est pas ça qui fera que ta fonction php strlen() renverra le résultat que tu attends : elle renverra 7 pour la chaine "réussi" et non 6 si l'encodage de "réussi" est en utf-8. Il peut même être plus simple de garder ta base en latin1, de faire tes traitements en php (et à ce moment là, strlen("réussi") renverra 6), puis au dernier moment utiliser mb_convert_encoding() pour afficher le résultat de ton traitement en utf-8 dans ta page.

Amicalement,
Modifié par parsimonhi (20 Jul 2014 - 14:04)
Ok d'ac, c'est bien le traitement uniquement des données envoyées à l'affichage dont tu parlais.
J'ai pensé à ce cas là, mais cette solution là ouvre le pb de devoir spécifiquement traiter chaque insert dans la base de données, avec d'ailleurs un risque potentiel de perte suivant ce que va écrire l'utilisateur (utf-8->iso).
Ayant un site très hétérogène et un modèle de programmation très linéaire jusqu'à il y a peu, ce genre de solution est finalement tout aussi chronophage que celles que j'ai évoquées.

Je me demande si en fait cette évolution vers UTF-8 n'est pas d'abord à intégrer à une reprise générale de mon site, en particulier vers un modèle MVC et/ou basée sur un framework php.
Des mois de boulot ... et pendant qu'on est sur le moteur, on n'est pas sur le contenu ...

B.
Passer certaines choses en UTF-8 et en garder d'autres en ISO-8859-1, à mon avis, c'est le meilleur moyen de se planter. ON a trop vite fait de s'emmêler les pinceaux si on doit sans cesse se demander d'où vient telle string, où elle doit aller, et quels sont les encodages impliqués.

Je pense que c'est une transition binaire, 1 ou 0, à faire une fois pour toute complètement, ou pas du tout, mais pas à moitié ou arrêter en plein milieu. C'est des réflexes à prendre et une fois qu'on les a pris, ne pas regarder en arrière.

Oui c'est un travail conséquent, et effectivement ça se place probablement très bien dans le cadre d'une refonte plus générale.

a écrit :
As tu des conseils sur la méthode pour ne pas se planter (je parle principalement sur la question des fonctions agissant sur les chaines de caractère) ?
J'ai envisagé 2 solutions :
- un remplacement automatique de toutes les fonctions posant problème qui ont des équivalent mb_* et une reprise manuelle pour ce qui n'a pas d'équivalent.
- un remplacement automatique de toutes les fonctions sur les chaines de caractères avec une fonctions maison genre perso_str_replace(), ce qui aurait l'avantage par exemple de ne pas m'obliger à choisir tout de suite certains points et de pouvoir évoluer plus facilement (je pense par exemple aux fonctions grapheme_ )
La seconde option est plutôt chronophage et ne sert peut être pas à grand chose car on ne change pas si souvent


Je ne suis pas un expert, mais je ne crois pas que les blablas sur les graphèmes aient une importance capitale en pratique. Je n'ai jamais vu de "é" séparé en deux points de code, et je ne vois pas vraiment à quoi ça peut bien servir de les encoder sous cette forme par exemple.

Pour ta première proposition, il me semblais avoir vu en son temps (je ne sais pas si ça existe toujours) une option php pour remplacer automatiquement en interne les appels strXXX en mb_strXXX sans toucher au code.

a écrit :
Enfin derniers points si tu as une expérience là dessus, faut il s'attendre à de nombreux problème avec les preg_ ? J'ai bien compris qu'il fallait ajouter en fin de motif le u mais cela est il suffisant ?

Pas toujours. \b et \B par exemple sont plus subtils à gérer.
QuentinC a écrit :

Je ne suis pas un expert, mais je ne crois pas que les blablas sur les graphèmes aient une importance capitale en pratique. Je n'ai jamais vu de &quot;é&quot; séparé en deux points de code, et je ne vois pas vraiment à quoi ça peut bien servir de les encoder sous cette forme par exemple.


Je suis déjà tombé la dessus en extrayant des pdf par copier coller. Au début on comprend que dalle à ce qui se passe !

QuentinC a écrit :

Pour ta première proposition, il me semblais avoir vu en son temps (je ne sais pas si ça existe toujours) une option php pour remplacer automatiquement en interne les appels strXXX en mb_strXXX sans toucher au code.


C'est un paramètre de la config du module mb_string, mb_string_overload ou un truc du genre. J'ai souvent lu en remarque d'utilisateur qu'il ne fallait pas jouer avec !

a écrit :
Enfin derniers points si tu as une expérience là dessus, faut il s'attendre à de nombreux problème avec les preg_ ? J'ai bien compris qu'il fallait ajouter en fin de motif le u mais cela est il suffisant ?

Pas toujours. \b et \B par exemple sont plus subtils à gérer.

Ok merci, je retiens ça aussi !

Je vais laisser murir un peu. La décision sera pour la rentrée.
Merci pour votre aide à la réflexion !

B.
a écrit :
Je suis déjà tombé la dessus en extrayant des pdf par copier coller. Au début on comprend que dalle à ce qui se passe !

Oui, mais bon, c'est du PDF, on peut mettre à peu près n'importe quoi sans restriction dans un PDF; ça compte pas. Je n'en vois toujours pas l'intérêt.

a écrit :
C'est un paramètre de la config du module mb_string, mb_string_overload ou un truc du genre. J'ai souvent lu en remarque d'utilisateur qu'il ne fallait pas jouer avec !


C'est vrai que ça peut rapidement mettre le boxon plus qua'utre chose, surtout si c'est un remplacement global et inconditionnel. On va forcément tomber sur un cas où le remplacement n'est pas désiré, et, plus grave, où on ne pourra plus utiliser la fonction originale vu que c'est un remplacement systématique.

Au moins si tu fais un rechercher/remplacer sur l'ensemble de tes fichiers, tu pourras toujours enlever mb_ au cas par cas.
Sujet clos
Aller à