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.
4 réactions
1 De Seza - 12/03/2012, 23:52
À 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...
2 De haypo - 13/03/2012, 00:03
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.
3 De Da Scritch - 13/03/2012, 09:03
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.
4 De haypo - 13/03/2012, 23:45
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).