PHP 5.4 et l'encodage de caractères
PHP 5.4 vient d'être rendu disponible et sa conception, qui a commencé dans la foulée de l'abandon du développement de PHP 6, aura duré à première vue pratiquement deux ans jour pour jour.
Cependant, à y regarder d'un peu plus près, le développement de PHP 5.4 a duré bien plus longtemps que cela, puisque certaine partie de son code ont été écrites durant la période de gestation de PHP 6.
La version 5.4 du langage, malgré sa numérotation la définissant comme une version mineure, est donc le fruit d'un gros travail effectué par les développeurs du langage.
Il est donc légitime de se demander s'il est pertinent de la mettre en œuvre dès aujourd'hui et de s'interroger sur ce qu'elle apporte au développeur.
Je tente déjà d'apporter des éléments de réponse à la première interrogation dans la série de billets correspondante.
Je vais donc tenter dans la série inaugurée par ce billet de répondre à la seconde, car il est très difficile de lister et surtout d'expliquer l'intérêt des apports de PHP 5.4 dans un unique article.
Les nouveautés de PHP 5.4 sont en effet à la mesure du travail fourni par ses concepteurs et sont donc très nombreuses.
De plus, certaines sont très riches et puissantes et il est donc difficile d'en démontrer l'intérêt en quelques mots.
Je vais donc tenter au cours des semaines qui viennent de publier régulièrement un billet décrivant l'un des nombreux apports de PHP 5.4, qu'ils s'agissent d'une suppression ou d'un ajout de fonctionnalité.
Et pour commencer, je vais vous parler des changements intervenus au niveau des directives de configuration du langage et plus particulièrement de celles relatives à la gestion de l'encodage de caractères.
Tout d'abord, PHP considère dorénavant par défaut que les données envoyées à un navigateur web sont encodées en UTF-8.
La valeur par défaut de la directive default_charset est en effet passée de iso-8859-1 à UTF-8.
Attention cependant, cela ne veut pour autant pas dire que PHP encode automatiquement et de manière transparente les données envoyées à un client HTTP en UTF-8.
La responsabilité de cet encodage reste entièrement à la charge du développeur, aussi bien au niveau de son code source qu'au niveau de ses fichiers de ressources ou de sa base de données.
D'ailleurs, pour ceux qui se poserait la question, le support de l'Unicode n'a pas été amélioré par PHP 5.4 et il faut donc toujours recourir aux outils traditionnels du langage pour travailler dans un encodage de caractères autre que l'iso-8859-1, comme mbstring ou intl.
Une directive de configuration nommée zend.multibyte a bien fait son apparition avec PHP 5.4, mais elle ne fait que remplacer la directive de compilation --enable-zend-multibyte et ne permet que d'activer la détection de l'encodage des fichiers analysés par le Zend Engine via leur BOM, et de plus uniquement si l'extension mbstring est disponible.
Il en va de même pour la nouvelle directive zend.script_encoding, qui permet de définir l'encodage d'un script PHP, en complément de la possibilité apparue avec PHP 5.3 de le définir via la directive declare().
En conclusion, si PHP 5.4 a été développé suite à l'abandon du développement de PHP 6, dont le principal apport devait être le support natif d'Unicode, il ne fait pas fonctionnellement mieux que PHP 5.3 sur ce point, même si quelques directives permettent de l'intégrer un peu plus fortement.
Commentaires
À ce sujet M. Ramsus a fait un commentaire sur @internals.
Si tu n'était pas encore au courant : http://news.php.net/php.internals/5...
Je pense que PHP6 était un échec car passer directement à Unicode par défaut est un bond en avant trop important. Il faut patcher l'ensemble des fonctions et des modules, ce qui est un travail titanesque. Neuf années ont par exemple été nécessaire à Python pour passer à Unicode par défaut pour les chaînes de caractères. Je pense que PHP devrait suivre la même voie que Python en commençant par ajouter un type unicode, puis supporter doucement ce nouveau type un peu partout.
Quand ce ne sont pas les langages natifs en Unicode, comme Javascript (ECMA recommande d'utiliser en interne UCS-2) qui posent problème, tout simplement parce qu'on a très vite dépassé les 65000 caractères adressables, qu'on a aussi dépassé les 100000. Reste donc à passer nativement à UCS-4, voire aux UTF, mais dans ce dernier cas, les calculs de longueur de chaînes, les possibles incohérences deviennent très rapidement des plaies.
Java, la bibliothèque Qt et Windows 2000 utilisent UTF-16. Le C et Python utilisent UTF-16 ou UCS-4 selon: la taille du type wchar_t (16 or 32 bits) pour le C, et un mode compilation (narrow or wide) pour Python. Windows 95 utilise UCS-2. Python 3.3 (en cours de développement, 3.3 alpha 1 est dispo) offre un accès en O(1) au n-ième caractère tout en utilisant le format le plus compact pour le texte : 1, 2 our 4 octets par caractère selon le code du caractère maximum (ex: 1 octet par caractère pour du texte ASCII ou Latin1).