18041 sujets
Questions générales et questions de débutants
Bonjour,
UTF-8 a bien des avantages et pour un nouveau projet, c'est chaudement recommandé.
Je n'interviens pas énormément sur les aspects dév front end mais à mon avis pour un site multilingue, pour le traitement des formulaires, pour AJAX et le transfert de données en JSON il faut probablement être très masochiste pour ne pas choisir UTF-8 dès le début.
Pour un site existant sans nouvelle fonctionnalité ni échange avec d'autres sites, à quoi bon passer du temps à essayer de tout convertir, réintroduire des bugs quelque part ?
UTF-8 a bien des avantages et pour un nouveau projet, c'est chaudement recommandé.
Je n'interviens pas énormément sur les aspects dév front end mais à mon avis pour un site multilingue, pour le traitement des formulaires, pour AJAX et le transfert de données en JSON il faut probablement être très masochiste pour ne pas choisir UTF-8 dès le début.
Pour un site existant sans nouvelle fonctionnalité ni échange avec d'autres sites, à quoi bon passer du temps à essayer de tout convertir, réintroduire des bugs quelque part ?
L'UTF-8 n'a pas que des avantages, notamment si on travaille sous windows, ou avec IE...
ET au niveau serveur, c'est pas si simple que ça à mettre en place.
Il n'y a pas si longtemps, j'étais encore profondément anti UTF-8. D'abord parce que sous windows, il y a ce satané BOM qui revient toujours; mais aussi parce que certaines fonctions telles qu'un bête strlen, ou les regex, ne fonctionne plus exactement comme prévu en php, sans oublier tout ce que ça implique en MySQL, et il faut faire très attention. Après être tombé 2 ou 3 fois dans les pièges courants, on commence à avoir l'habitude, mais au début on perd énormément de temps pour des bêtises. Donc non, côté serveur, c'est pas si simple, il y a quelques habitudes bien ancrées à changer.
J'ai changé d'avis seulement quand j'ai sérieusement envisagé une possible internationalisation d'un de mes sites, après être passé par tous ces pièges. IL n'en reste pas moins que, si on n'a pas encore l'habitude, si on ne comprend rien aux encodages, si on n'envisage pas de multilingue ni de grosses usines AJAX, je ne le recommanderais pas. Un petit site en ISO-8859-X, ça passe toujours très bien, et ça a le mérite d'être simple. La migration vers UTF-8 c'est très bien, mais il faut vraiment prendre le temps pour la faire correctement.
ET au niveau serveur, c'est pas si simple que ça à mettre en place.
Il n'y a pas si longtemps, j'étais encore profondément anti UTF-8. D'abord parce que sous windows, il y a ce satané BOM qui revient toujours; mais aussi parce que certaines fonctions telles qu'un bête strlen, ou les regex, ne fonctionne plus exactement comme prévu en php, sans oublier tout ce que ça implique en MySQL, et il faut faire très attention. Après être tombé 2 ou 3 fois dans les pièges courants, on commence à avoir l'habitude, mais au début on perd énormément de temps pour des bêtises. Donc non, côté serveur, c'est pas si simple, il y a quelques habitudes bien ancrées à changer.
J'ai changé d'avis seulement quand j'ai sérieusement envisagé une possible internationalisation d'un de mes sites, après être passé par tous ces pièges. IL n'en reste pas moins que, si on n'a pas encore l'habitude, si on ne comprend rien aux encodages, si on n'envisage pas de multilingue ni de grosses usines AJAX, je ne le recommanderais pas. Un petit site en ISO-8859-X, ça passe toujours très bien, et ça a le mérite d'être simple. La migration vers UTF-8 c'est très bien, mais il faut vraiment prendre le temps pour la faire correctement.
Le BOM n'a absolument aucun rapport avec Windows. C'est bien la première fois que j'entends une bêtise pareille.
En PHP les regex de type Perl fonctionne parfaitement avec des chaines encodées en UTF-8. Pour les fonctions du genre strlen() c'est normal puisqu'il faut utiliser leur équivalent mb (multi-byte) quand on utilise un encodage où les caractères peuvent être composés de plusieurs octets.
Pour MySQL je ne vois pas du tout ce que "tout ce que ça implique veut dire". Il suffit de bien configurer ses tables et déclarer le charset UTF-8 lors de la connexion à la base. C'est tout.
De plus 99% des frameworks et CMS en PHP sont configurés pour travailler en UTF-8 par défaut.
Je rajouterai que "si on ne comprend rien aux encodages" le mieux est encore de se former ! C'est pas la documentation sur le sujet qui manque et c'est un truc de base à connaitre et qui sert partout.
Modifié par jb_gfx (25 Dec 2013 - 08:03)
En PHP les regex de type Perl fonctionne parfaitement avec des chaines encodées en UTF-8. Pour les fonctions du genre strlen() c'est normal puisqu'il faut utiliser leur équivalent mb (multi-byte) quand on utilise un encodage où les caractères peuvent être composés de plusieurs octets.
Pour MySQL je ne vois pas du tout ce que "tout ce que ça implique veut dire". Il suffit de bien configurer ses tables et déclarer le charset UTF-8 lors de la connexion à la base. C'est tout.
De plus 99% des frameworks et CMS en PHP sont configurés pour travailler en UTF-8 par défaut.
Je rajouterai que "si on ne comprend rien aux encodages" le mieux est encore de se former ! C'est pas la documentation sur le sujet qui manque et c'est un truc de base à connaitre et qui sert partout.
Modifié par jb_gfx (25 Dec 2013 - 08:03)
a écrit :
Le BOM n'a absolument aucun rapport avec Windows. C'est bien la première fois que j'entends une bêtise pareille.
Non, c'est vrai, c'est en soi pas lié à windows. Mais mac et linux ont l'immense avantage d'être d'office en UTF-8, pas windows. D'où toute une série de problèmes potentiels qui apparaissent uniquement quand on travaille sous windows et qu'on met en prod sous linux.
a écrit :
En PHP les regex de type Perl fonctionne parfaitement avec des chaines encodées en UTF-8.
Tout à fait. Mais j'ai mis un bon moment avant de comprendre ce qui buggait et trouver qu'il fallait ajouter l'option U. Une fois qu'on le sait ça roule; mais il faut le trouver, c'est bien caché dans la doc.
a écrit :
Pour les fonctions du genre strlen() c'est normal puisqu'il faut utiliser leur équivalent mb (multi-byte) quand on utilise un encodage où les caractères peuvent être composés de plusieurs octets.
Exact. Mais là de nouveau, c'est pas forcément super clair quand on ne le sait pas.
a écrit :
Pour MySQL je ne vois pas du tout ce que "tout ce que ça implique veut dire". Il suffit de bien configurer ses tables et déclarer le charset UTF-8 lors de la connexion à la base. C'est tout.
Oui, c'est tout ! Mais là encore, j'ai dû chercher un bon moment avant de tomber sur le set names utf8 magique; et plein d'hébergeurs n'ont pas le charset UTF-8 par défaut.
a écrit :
Je rajouterai que "si on ne comprend rien aux encodages" le mieux est encore de se former ! C'est pas la documentation sur le sujet qui manque et c'est un truc de base à connaitre et qui sert partout.
Il faut quand même admettre que, bizarrement, c'est un sujet tout de même encore très méconnu... beaucoup de gens se cassent encore les dents quand ils tombent sur des é ou des forêts de ? ou de carrés.