Support natif d’Unicode

Tout ceux qui ont développé un minimum sous PHP <= 5 connaissent les problèmes d’encodage. Concrètement, vous retrouvez souvent vos caractères spéciaux (comprenez par là « caractères n’étant pas dans l’alphabet américain ») qui s’affichent bizarrement une fois application déployée. Et ce n’est que la partie apparente de l’iceberg. A vrais dire, la multiplicité des encodages pose de véritables problèmes dès que l’on doit effectuer un traitement quelconque sur une chaîne de caractères. Sachant qu’en général, plus de la moitié des traitements en PHP concerne les chaînes de caractères, il fallait agir.

Le staff décisionnaire de PHP s’est rendu compte que la multiplicité des charset n’était, au final, qu’un croche patte pour la plupart des développeurs. Voilà pourquoi il a été décidé d’implémenter Unicode en natif dans PHP6. Il serait très fastidieux d’expliquer ce qu’est Unicode ici, pour cela, vous pouvez vous référer à Wikipédia. Mais, dans les grandes lignes, sachez qu’Unicode représente une gestion uniformisée de tout les alphabets mondiaux sur n’importe quelle plateforme et de façon propre. On pourra ainsi traiter un alphabet européen, cyrillique ou chinois sans trop se soucier de l’encodage.

Même si le PHP Group a décidé d’implémenter ICU (solution existante qui a largement fait ses preuves et qui est libre), le passage a Unicode a nécessité la réécriture de beaucoup de code à tout les niveaux du noyau PHP et des librairies. Oui mais voilà, le résultat est là ! Sans parler des problèmes d’affichage de caractères, faisons quelques travaux sur des chaînes de caractères …

Prenons un exemple simple, imaginons que nous cherchions à connaître la longueur de chaînes de caractères (ce qui est fréquent en PHP). Voyons ce que cela donne avec PHP5 et avec le support d’unicode de PHP6:

Sous PHP5:

 strlen("php");		// Retourne 3
 strlen("être");		// Retourne 5
 strlen("µ£~");		// Retourne 5

Sous PHP6:

 strlen("php");		// Retourne 3
 strlen("être");		// Retourne 4
 strlen("µ£~");		// Retourne 3

Alors pourquoi une telle différence entre les deux versions ? Tout d’abord il faut préciser que le fichier qui a servi à faire ces tests était codé en UTF-8, ce que PHP5 ne gère pas de façon native. Pour PHP5, un caractère, c’est tout simplement un octet. Seulement, si on prend le cas du « ê » de « être », il est codé sur plus d’un octet en UTF-8. C’est aussi ce qui explique le décalage dans « µ£~ ». PHP6, quant à lui, ne réfléchi plus en terme d’octet mais en terme de caractère véritable. On se retrouve ainsi avec les bons résultats.

Après, on pourrait se demander pourquoi avoir encodé ce fichier de test en UTF-8. Tout d’abord parce que c’est un standard (dès qu’on parle d’internationalisation, il faut penser à ça !). De même, il n’est pas forcement utile d’amener le raisonnement aussi loin. Prenez simplement l’exemple d’Ajax ! En Ajax, les données envoyées au serveur sont obligatoirement en UTF-8. Certes il existe des solutions pour palier à ces problèmes sous PHP5, mais c’est plutôt hasardeux et peu pratique.

Pour finir, le support natif de l’Unicode ne s’arrête pas seulement aux chaînes de caractères. Ainsi, les noms de fonctions et de variables pourront être écrit avec des caractères internationaux (une fonction avec des idéogrammes chinois par exemple). On emmétra cependant une réserve vis-à-vis de cette possibilité. Ce n’est pas l’idéal pour travailler à plusieurs sur un code. Imaginez que vous travailliez sur ces scripts écrits par un développeur chinois …