Discussion :

[RideKick]

Bonjour,

Comme vous le savez ans doute, PHP6 est encore en phase de développement. Ce n'est pas encore une beta (loin s'en faut) et certaines questions fondamentales restent en suspens.

Récemment, une ancienne question a refait surface sur la liste internals@ : PHP6 doit-il être uniquement Unicode, simplement supporter Unicode ou... ?

Le débat tourne principalement autour des chaînes à l'intérieur des scripts. Il ne fait pas de doute que PHP6 intègrera la bibliothèque ICU et proposera toute une panoplie de fonctionnalités i18n ; la question aujourd'hui est de savoir si les scripts PHP6 devront être encodés en Unicode ou si PHP6 encodera les chaînes en binaire (ce que PHP a fait jusqu'à présent).

Concrètement, la question est de savoir si PHP6 proposera Unicode comme une option ou bien si ce sera obligatoire.

Voici une discussion des archives à ce sujet : why we must get rid of unicode.semantics switch ASAP
Plus récemment : What is the current state of PHP6?


Qu'en pensez-vous ? Doit-on aller de l'avant sans conserver la compatibilité avec les anciens scripts, ou bien suivre le mouvement général et attendre PHP7 pour obliger l'utilisation systématique d'Unicode ?

[gloubi]

J'avous que je ne sais pas ce que cela implique... Tu peux nous faire un petit topo sur ce que ça sognifierai de n'avoir que l'unicode ?

[darkstar123456]

Hmmm je ne suis pas hyper au courant de l'Unicode non plus. Je suis donc allez voir sur Wikipedia.

D'après ce que j'y ai lu, je trouve que l'Unicode pourrait être pas mal. Je pense qu'il pourrait palier à certains problèmes d'encodage et de transfert de BDD (qui n'a jamais eu de problème entre UTF8 & ISO ? )
Du moins, si j'ai bien compris

Pour ce qui est de savoir si on doit attendre le 7 ou le mettre directement dans le 6, je dirais que quoi qu'il arrive, un bon hébergeur permet à son client de choisir sa version PHP, le problème n'en est pas vraiment un.
Pour le reste, on est habitué maintenant... par exemple, au passage à PHP5, pratiquement tous les scripts ont du être modifiés à cause du register_globals Off (et c'était pas du luxe ^^)

[Yogui]

qui n'a jamais eu de problème entre UTF8 & ISO ?

C'est exactement de cela qu'il s'agit, en effet.

Tout avoir en Unicode obligerait tout le monde à utiliser UTF-8 pour l'encodagedes scripts, mais aurait l'avantage de ne plus devoir se poser la question de l'encodage (comment est encodée ma chaîne ? dans quel encodage dois-je l'afficher ? comment puis-je la convertir ?).

[darkstar123456]

Ca simplifierait également les bases de données. Car si les chaines sont en UTF8, les bases de données le seraient aussi... donc moins de problème avec les caractères accentués (notamment lors d'une recherche) qu'avec le latin1_swedish_ci.

Peut-être moins de questions à se poser aussi par rapport aux ORDER BY.

[B.Moncef]

A mon avis, il serait préférable qu'Unicode soit obligatoire, et non une option de php6.
L'avantage est vraiment énorme, sur les forums de support en PHP, il y a beaucoup de gens qui ont des problèmes avec l'encodage, choisir ISO ou UTF-8 ? Pourquoi y'a t-il des caractères bizarres qui s'affiche sur ma page ? ou dans ma base de données ? etc.
L'inconvénient qu'est la perte de la rétro-compatibilité n'en est pas un je pense, étant donné qu'à à un moment ou un autre (PHP6 ou PHP7), il faudra aller de l'avant au détriment de cette compatibilité. Pourquoi attendre PHP7 alors ?

[gloubi]

Ah, c'est juste ça :p
Bha je suis clairement en faveur de l'évolution du langage, même si ça doit couter la rétrocompatibilité... Mais pour le coup, je ne vois pas bien pourquoi on perdrait la compatibilité des scripts PHP5...

[Yogui]

@gloubi, fais un test simple. Enregistre le document suivant sur ton serveur en encodage ANSI, puis affiche-le avec le navigateur. Enregistre-le ensuite en UTF-8 et affiche-le de nouveau. Refais enfin ces deux opérations en changeant le header() à UTF-8 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
<?php
header('Content-Type: text/html; charset=ISO-8859-1');
?>
Développez

Pense maintenant que ce header n'est pas systématiquement envoyé par ton script, tu te reposes alors sur l'encodage par défaut du serveur Web. Comment sais-tu que l'encodage par défaut du serveur Web correspond à l'encodage des scripts (par exemple si tu utilises des biblios toutes faites) ou, pire, à l'encodage du navigateur de chacun de tes internautes ?

[gloubi]

En conclusion, je ferait bien de rajouter ce header sur mes pages Ajax :p
Bon bha "Pour" :p

[Yoteco]

Bonjour,

Moi je pense que sa serait en effet bien que PHP6 supporte l'unicode pour régler une fois pour toute ces soucis de header mais par contre je n'ose pas imaginer le bordel si PHP6 est unicode ! Imaginez des bouts de code avec des variables en arabe ou en chinois...

Donc oui pour le support mais contre PHP6 unicode.

[B.Moncef]

Il peut y avoir des variables écrites en français dans du code non ? certes les caractères propres à la langue française ne sont pas autorisés pour les noms de variables, mais il y a beaucoup de codes où on ne peut comprendre le nom d'une variable qu'en parlant français.

Je ne vois pas pourquoi ça dérangerais si le nom d'une variable est écrit en langue arabe ou chinoise, au lieu du français.

[Yogui]

Il est déjà possible d'écrire un nom de classe en français ou même en japonais si tu veux, du moment que ton script est encodé correctement (UTF-8 par exemple).

Par contre ce n'est pas du tout une bonne pratique : que se passe-t-il le jour où tu veux exporter ton projet ? Il est largement préférable de coder dans une langue internationale, ie. en anglais

[yannux]

Oui à l'unicode obligatoire ! Y'a pas photos !

[Folken Laëneck]

Pour ma part, je pense que faire passer PHP6 intégralement en unicode serait une excellente chose.

Je ne vais pas reprendre tout ce qui a été dit, mais forcer l'utilisation d'unicode résoudrait énormément de problème dans bien des situations. Quand l'application est dans une seule langue, ce ne serait déjà pas du luxe la plupart du temps, mais ca devient absolument incontournable quand elle vire au multilingue, en allant parfois jusqu'à des langues aux jeux de caractères étranges et complexes - qui a dit turque ? -

Il y a plusieurs mois maintenant que je suis personellement passé définitivement au tout unicode - via l'utilisation de l'UTF-8 à tous les niveaux - et pour rien au monde je ne ferrais machine arrière.
Le dernier exemple en date ? Je dois refaire actuellement un site web entier en 7 langues pour la simple et bonne raison que le développeur qui est passé avant n'a a aucun moment véritablement porté attention à ce qu'il manipulait et que application comme base de données forment actuellement un tel plat de nouilles que c'en est inextricable. Et bien sur, ça bug :/


En revanche, il faudra certainement que les SBDB suivent le même chemin. De mémoire, il en est quelques-uns des plus courant qui gêrent parfois de manière étrange les jeux de caractères multi-octet, principalement au niveau de la recherche plein texte.


Pour ce qui est de la rétro-compatibilité, pourquoi crier tout de suite au loup ? Actuellement, on peut déjà préciser le jeu de caractère utiliser en interne par les fonctions des modules iconv et mb_string, qu'est-ce qui empêcherait un PHP6 full unicode de venir au monde avec dans son panier une fonction simple ou une directive de configuration pour définir l'encodage interne sur le bon vieux ISO-8859-1 par exemple ?
Mais par pitié, que l'UTF-8 soit l'option par défaut. Je vois déjà d'assez loin venir si cela se fait les hébergeurs qui s'empresseront de remettre l'ancien mode de fonctionnement sous couvert de retro-compatibilité, comme ça a été fait pour le register_global. Résultat ? on traine encore aujourd'hui des scripts passoires avec des failles de sécurité grande comme le Grand Canyon...


Bref, on est surement pas près de voir disparaitre les Ǻ© et autres bizarreries, mais au moins qu'on fasse les premiers pas le plus rapidement possible. Voilà mon avis.

[ludosoft]

...Il y a plusieurs mois maintenant que je suis personellement passé définitivement au tout unicode - via l'utilisation de l'UTF-8 à tous les niveaux - et pour rien au monde je ne ferrais machine arrière...

Pareil. Voilà 3 ans que j'ai imposé ça au bureau. Ca a commencé le jour où on a dû livrer un site traduit en chinois... Depuis toute la chaine travail en UTF8 comme ça c'est clair.

Le seul problème rencontré concerne le tri en base de données. En effet, dans le cas de PostgreSQL 8.2 (je n'ai pas fait de test avec la 8.3), la présence de "é" et autres "à" perturbent le ORDER BY. Rien de grave car on peut contourner ça avec une petite procédure stockée qui supprime les accents.

Donc à mon avis la réponse est : "yes, unicode now" !

En espérant juste que cela ne va pas ralentir l'adoption de PHP6.

[stailer]

+1, j'ai eu pas mal de souci entre certains de mes modules ou pages en ISO , et finalement la récup de données sur d'autres pages en UTF... Bref maintenant je fais tout en unicode et ça va beaucoup mieux

Donc yes, pour moi aussi, ce serait bien que ce soit implémenté dans Php6.


EDIT : ou 5.3 , puis qu'apparemment aux dernières infos 90% des "trucs" de la 6 vont se retrouver dedans (packages, APC...)

[Yogui]

Pour info, implémenter Unicode dans PHP demande une réécriture totale du Zend Engine, c'est pour cela qu'il passera en version 3 pour PHP 6. C'est aussi pour cela qu'Unicode ne sera pas dans PHP 5.3

Conserver un switch pour désactiver Unicode dans php.ini a déjà été discuté dans internals@ mais la proposition a été rejetée, cf. le lien posté dans le premier message de cette discussion : why we must get rid of unicode.semantics switch ASAP

[Le Roux B.]

Unicode en PHP aurait dû être implémenté depuis longtemps.
J'ai lu un forum que par contre il y aura une baisse significative des performances (temps de réponses) ce qui explique pourquoi il y aura implémentation de la gestion de cache. Est ce exact ?

[eMeRiKa]

Je serai également pour obliger l'unicode.

Par contre, l'UTF-8 et le BOM me pause de sérieux problème, j'ai beau avoir défini dans mon éditeur encodage en UTF-8 sans BOM, il refait toujours surface et pause problème.

Je ne connais pas son utilité, mais si PHP6 oblige l'unicode il faudrait que le problème du BOM soit réglé.

[ludosoft]

Je serai également pour obliger l'unicode.

Par contre, l'UTF-8 et le BOM me pause de sérieux problème, j'ai beau avoir défini dans mon éditeur encodage en UTF-8 sans BOM, il refait toujours surface et pause problème.

Je ne connais pas son utilité, mais si PHP6 oblige l'unicode il faudrait que le problème du BOM soit réglé.

Ouais, ça me rappelle quelques heures passées à chercher d'où venaient ces quelques fichus caractères qui hantaient une page... Attention à bien configurer son éditeur favori