Tout le monde sait que PHP a des problèmes avec Unicode. La version 6 est effectivement abandonnée, en raison de difficultés de mise en œuvre d'Unicode. Mais je me demande si quelqu'un sait quelles sont les raisons exactes ? Problèmes d'architecture / conception, problèmes de performances, problèmes de communauté (je parie que non), autre chose?
Réponses:
PHP en tant que langage peut certainement l'avoir, mais je pense que le problème est avec la compatibilité avec les programmes existants. La prise en charge Unicode peut les briser de manière subtile, ce qui est le type de bogue le plus ennuyeux à avoir.
Actuellement, la plupart des fonctions de traitement de chaînes en PHP sont "binaires", ce qui signifie que vous pouvez les utiliser pour traiter n'importe quel fichier dans n'importe quel encodage ainsi que des formats binaires comme les données d'image, etc.
Avec l'ajout de chaînes Unicode, vous devez faire très attention à ne pas mélanger les chaînes Unicode avec des chaînes binaires (assez difficile lorsque vos chaînes proviennent de différentes sources et que vous n'avez jamais eu à vous en soucier auparavant). Et vous ne pouvez plus ignorer les encodages (et beaucoup de scripts l'ignorent!)
Un autre problème difficile, mais résoluble est l'accès aléatoire dans les chaînes Unicode. Implémentation de $string[$offset]changements de triviaux à très lents ou peu lents et très complexes.
Je pense aussi que c'était une erreur de choisir UTF-16 comme encodage interne pour PHP. Il a les mêmes problèmes que l'UTF-8 (largeur variable en raison des paires de substitution) et l'inefficacité de l'UCS-2. Peut-être devraient-ils abandonner cela et recommencer avec UTF-8?
</speculation>
TLDR: de nombreuses bibliothèques PHP ne sont qu'une couche mince sur les bibliothèques C natives qui ne prennent pas en charge Unicode, ou le prennent en charge de manière incompatible les unes avec les autres. La rectification de cette situation est susceptible d'introduire des changements incompatibles en amont.
AVERTISSEMENT: comme je suis passé de PHP à Python (pour ne jamais regarder en arrière) il y a quelques années, mon opinion est clairement biaisée.
Je pense que PHP est un hack sympa et intelligent. En tant que hack, il a commencé sans prétention et s'est développé de manière quelque peu chaotique à partir d'un tas de bibliothèques clairsemées - manquant d'une conception bien pensée et unifiée (du point de vue de la théorie du langage informatique).
Comme l'a dit Machiavel, "celui qui n'a pas posé ses fondations en premier peut être capable de les poser par la suite, mais celles-ci seront posées avec des problèmes à l'architecte et un danger pour le bâtiment".
Pour un langage de programmation, le plus populaire, le plus difficile à changer. C'est pourquoi des langages comme C changent tous les 10 ans. Par exemple, Python 3 a apporté de nombreux changements incompatibles en arrière, et ce n'était pas joli. La prise en charge unicode dans les incarnations Python précédentes était déjà considérée comme supérieure à l'état actuel des choses en PHP, mais devinez quoi: les changements les plus polémiques dans Python 3 sont liés à la gestion unicode. Cette diatribe d' Armin Ronacher résume la frustration d'une grande partie de la communauté Python.
PHP étant "la" plateforme web omniprésente le rend victime de son propre succès. Apporter un support unifié pour unicode en PHP est inévitable, mais nécessitera beaucoup de sang, de sueur et de larmes.
L'une des principales raisons pour lesquelles l'ancien travail PHP 6 a été arrêté était en raison de la complexité interne qu'il apportait et de la quantité de travail à faire, ce que presque personne ne comprenait à peine.
Un peu d'histoire: l'implémentation Unicode de PHP 6 a été conçue par le besoin d'un plus grand utilisateur PHP et a essayé de faire Unicode "correctement". Après une certaine évaluation, le concepteur principal de la prise en charge de PHP-to-Unicode a choisi d'ajouter un nouveau type de chaîne qui est en interne Utf-16 et d'autoriser différents codages à utiliser à différents endroits. Ainsi, le code peut être écrit dans un codage, la sortie peut utiliser un codage différent et des "opérations runtme" un autre codage. La raison du choix de l'UTF-16 était que le travail devrait être basé sur l'ICU livrary qui utilise UTF-16 et il a été constaté que cet encodage permet des opérations de chaîne courantes d'une manière rapide tandis que la conversion entre utf- et utf-16 est relativement bon marché. . Jusqu'ici tout va bien.
Maintenant, la conséquence de cela est avant tout l'introduction d'un nouveau type de chaîne. Le système de type interne de PHP avait jusque-là quelques types (NULL, bool, int / long, float / double, chaîne, tableau, ressource, objet) et beaucoup de code avait certaines hypothèses à ce sujet. Outre ces hypothèses, toutes les fonctions fonctionnant sur des chaînes, et il y en a beaucoup, doivent être évaluées individuellement et il faut décider comment gérer les encodages. Doivent-ils fonctionner sur des chaînes binaires ou des chaînes unicode? Si une conversion est requise, quel codage doit être utilisé, etc., et cela demande beaucoup de travail et, dans certains cas, est assez compliqué à faire correctement. De plus, les API internes sont devenues assez compliquées, car la plupart des API clés de PHP ont des versions pour les chaînes binaires (l'ancienne), puis souvent une version pour les chaînes "encodées à l'exécution",
Au cours du processus, de nombreux développeurs sont tombés sur la coplexité, sont devenus agacés par utf-16 et n'aimaient pas le fait que cela doublerait l'utilisation de la mémoire et passerait beaucoup de temps à convertir des chaînes tout en cassant la plupart des applications existantes. Ainsi, PHP étant piloté par des bénévoles, de moins en moins de développeurs y travaillaient et d'autres choses s'accumulaient et les contributeurs étaient mécontents et à la fin il a dû être abandonné.
Maintenant, que pourrait apporter l'avenir? - Il y a une évolution lente qui se produit et de plus en plus de choses en PHP sont construites autour de utf-8. Pas de manière forte avec un type personnalisé et forçant tout et actuellement les développeurs ne sont pas motivés pour toucher ce fer à repasser. On peut espérer que quelqu'un a une bonne proposition pour le faire fonctionner correctement, mais actuellement "tout le monde" s'enfuira s'il n'entend que le mot. :)
Je suppose que la raison réelle est que l'équipe de développement PHP n'a pas de feuille de route claire pour le développement PHP (mentionnons simplement une discussion assez animée lorsque quelqu'un sur php-internals a décidé de démarrer la branche PHP 5.4 sans s'être préalablement mis d'accord sur les fonctionnalités que 5.4 devrait contenir). J'aime beaucoup ce langage, mais la façon dont il est développé me rend un peu inquiet.