Tout en utf-8
Par Laurentj le lundi, mars 19 2007, 14:00 - Geek-log - Lien permanent
Je commence à en avoir vraiment marre de manipuler mon éditeur pour passer de utf-8 à latin1 ou latin1 à utf-8 quand je passe d'un projet à un autre, d'un fichier à un autre. Dorénavant, je ferais tout en utf-8. J'ai d'ailleurs commencé :
- passage des sources de Jelix en utf-8, et l'encodage par défaut est maintenant utf-8.
- mise à jour de mon installation dotclear vers la version 1.2.5, avec au passage migration de mes données mais pas seulement : connexion à la base de donnée (ce qui a nécessité un petit hack dans dotclear), schéma des tables de données, templates. Tout en utf-8 de bout en bout.
Le reste de mon site perso, mes autres projets et autres sites subiront le même sort petit à petit, à l'occasion d'évolutions.
Chez moi, latin1 (iso-8859-1) fait parti désormais du passé.
Commentaires
C'est bizarre que des gens pensent la même chose presque au même moment. Je viens de faire un billet sur le passage d'un site en UTF-8 justement.
Bon courage en tout cas, c'est pas de tout repos...
Avant j'utilisais HTML Kit pour ses capacités a éditer un site directement via FTP, mais c'était une énorme galère pour saisir du texte en UTF-8.
Par la suite j'ai découvert pspad et depuis, mon bonheur est total...
J'ai fait la même démarche il y a un an et depuis c'est du bonheur. :)
Faut passer directement en utf-16 ;)
Question: comment fais-tu pour passer toutes tes sources en utf-8 ? avec iconv ?
Oui je pense qu'il n'y a qu'iconv... Mais si quelqu'un a une autre solution ;)
Par contre il faut connaitre l'encodage de base...
Il y a l'outil recode aussi Par contre quel hack est nécéssaire dans dotclear2 pour la connexion en UTF8 ? ne prend t-il pas l'encodage de connexion par défaut de la base ?
@neonov >Bon courage en tout cas, c'est pas de tout repos..
Merci. le souci principal, c'est la prise en charge correct d'utf-8/16 par php. Il faut faire attention aux fonctions qu'on utilise. Vivement php6.
@YvesTan : oui, j'ai utilisé iconv + un petit script pour parcourir tous les fichiers/répertoires automatiquement
@dam : Par contre quel hack est nécessaire dans dotclear2 pour la connexion en UTF8 ? ne prend t-il pas l'encodage de connexion par défaut de la base ?
J'ai pas DC2, mais DC 1.2.5. Souvent chez les hébergeurs, l'encodage par défaut des connections est latin1. J'ai donc dans DC 1.2.5 rajouté après la connexion :
if(defined('DB_CHARSET') && DB_CHARSET != ''){ mysql_query("SET CHARACTER SET '".DB_CHARSET."'", $this->con_id); }où DB_CHARSET est une constante que j'ai rajouté dans le config.php :
define('DB_CHARSET','utf8');@laurentj : Pour ne pas s'emm**der avec les fonctions il y a toujours mbstring qui peut 'overrider' les fonctions habituelles (change les strlen par les mb_strlen à la volée). Mais après niveau perf ou compatibilité je n'ai pas testé...
> Vivement PHP6 : ooouuiii !!!
Et au passage, c'est neoVov, pas neoNov :p (j'ai l'habitude...)
L'Unicode est quelque chose de bien plus compliqué qu'on ne le croit. Gérer les encodages, c'est trivial. (enfin sur le web les gens sont moins bons, alors ils ont besoin d'une bibliothèque pré-écrite). Il faut faire attention pour faire ça de manière performante, mais c'est facile. Les grapheme clusters et les normalisations, ça devient plus compliqué. On remarque d'ailleurs que la plupart des bibliothèques/langages se prétendant 'Unicode-aware' ne les gèrent pas vraiment. Les tailored grapheme clusters, les collations etc., ça devient très complexe.
Que ce soit avec les fonctions actuelles ou avec PHP6, le support d'Unicode est limité. (enfin c'est quand même mieux avec PHP6)
@neovov: mbstring n'est pas activé par défaut et donc pas toujours activé chez les hébergeurs. Je ne l'utilise donc pas dans jelix.
@loufoque : dans php6, toutes les fonctions seront full compatible avec utf-8/16. D'ailleurs, en interne, tout sera traité en utf-16. La lib ICU sera utilisée. Tu peux surveiller l'avancement des travaux ici, et il y a aussi un pdf qui résume très bien ce que sera PHP6 avec unicode. Bref, je doute franchement que le support d'unicode dans php6 sera "limité" ;-)
C'est une bonne initiative de tout passer en utf-8. C'est vrai que c'est le bordel !
C'est le bordel parce qu'au premier abord ça parait compliqué, mais en fait il suffit de faire attention, et avec un peu d'organisation c'est simple.
A partir du moment ou on choisi de TOUT mettre en UTF-8 on a largement moins de problèmes par la suite.
Fun, j'allais publier un billet sur le sujet :-)
En effet, depuis que je suis passé sous PDT je convertis l'ensemble de mes fichiers en UTF8 pour éviter les problèmes.
Ha ba ouais je viens d'en parler sur le forum de copix et j'ai même créer un plugin pour ça... et je ne veux plus que du UTF-8...
Par contre ça fout le souk avec Oracle
Bravo pour cette décision. Sinon, personnellement, jutilise plutôt: SET NAMES utf8; Jai regardé dans la doc mais je ne parviens pas à bien comprendre la différence avec SET CHARACTER SET 'utf8';
http://dev.mysql.com/doc/refman/4.1/en/charset-connection.html
Tient c'est marrant je suis justement en train de me battre a ma boite pour qu'ils arretent d'utiliser des encodages farfelus (on gere des caracteres asiatiques entre autres)...
Migrer toutes ses infos en UTF-8 n'est pas de tout repos (surtout pour les bases de donnees) mais c'est assurement un tres bon choix sur le long terme!
J'en profite pour faire un peu de pub pour Firebird qui, dans sa recente version 2.0, est devenu entirement compatible UTF-8:que du bonheur ;) !
laurentj, je parle en connaissance de cause. Contrairement à toi, je sais ce qu'est Unicode. Je te conseille de te renseigner sérieusement sur le sujet si tu veux discuter là-dessus. Par exemple, tu aurais pu commencer par savoir ce que sont les grapheme clusters, et autres éléments de base de la compréhension d'Unicode, avant de prétendre des choses dont tu ne peux juger de la véracité.
Par exemple, le choix a été fait dans PHP6 que les chaînes soient des séquences de code points et non de grapheme clusters. Java a fait un choix similaire. Bref, ça ne gère que l'encodage d'Unicode. Mais Unicode, c'est bien plus que l'UTF-8, 16 ou 32.
Du coup, on peut aisément rendre invalide une chaîne. Des efforts ont été fait néanmoins pour certaines des fonctions de la bibliothèque standard fasse attention aux grapheme clusters. (strrev en particulier, histoire de ne pas générer une chaîne invalide à partir d'une qui l'est)
L'opérateur d'égalité fait quant à lui une comparaison correcte en mettant les chaînes sous forme canonique. Pour ce qui est des comparaisons approximatives et ordonnées il devrait y avoir de nouvelles fonctions. Je ne sais pas par contre ce qu'ils ont prévu de faire pour les vieilles fonctions qui supportaient ces fonctionnalités. Enfin, il est prévu dans le futur d'exposer des parties de l'API d'ICU pour des fonctionnalités avancées.
Le lien que tu as fourni sur l'évolution de la migration qui est effectuée dans PHP ne correspond qu'à l'utilisation de nouvelles primitives du Zend Engine pour l'utilisation des nouveaux types.
Même si je le ton est aux piques d'un coté comme de l'autre, j'apprécie grandement le contenu technique qui se trouve dans la contre argumentation des messages de loufoque (la dernière fois c'était avec les méthodes modernes de développement C++ je crois)
Commentaire qui ne sert à rien, je l'admet volontiers, mais s'il fallait se taire même lorsque l'on a rien à dire.....