Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage PHP Discussion :

Internals : PHP6 et Unicode


Sujet :

Langage PHP

  1. #1
    Rédacteur

    Internals : PHP6 et Unicode
    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 ?
    Pas de questions techniques en MP please

    Mon site perso

    Mon profil Viadeo

  2. #2
    Membre confirmé
    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 ?
    Si vous avez un message d'erreur, n'oubliez pas de le lire, la réponse à votre problème est surement dedans !

  3. #3
    Membre chevronné
    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 ^^)

  4. #4
    Rédacteur

    Citation Envoyé par darkstar123456 Voir le message
    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 ?).

  5. #5
    Membre chevronné
    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.

  6. #6
    Membre régulier
    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 ?
    Pas de question techniques par MP

  7. #7
    Membre confirmé
    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...
    Si vous avez un message d'erreur, n'oubliez pas de le lire, la réponse à votre problème est surement dedans !

  8. #8
    Rédacteur

    @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 ?

  9. #9
    Membre confirmé
    En conclusion, je ferait bien de rajouter ce header sur mes pages Ajax :p
    Bon bha "Pour" :p
    Si vous avez un message d'erreur, n'oubliez pas de le lire, la réponse à votre problème est surement dedans !

  10. #10
    Rédacteur

    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.
    Blog - Mon espace developpez -
    Oracle Certified Professional, Java SE 6 Programmer
    eZ Publish Certified developer

  11. #11
    Membre régulier
    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.
    Pas de question techniques par MP

  12. #12
    Rédacteur

    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

  13. #13
    Membre averti
    Oui à l'unicode obligatoire ! Y'a pas photos !

  14. #14
    Membre régulier
    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 &#506;© et autres bizarreries, mais au moins qu'on fasse les premiers pas le plus rapidement possible. Voilà mon avis.

  15. #15
    Membre habitué
    Citation Envoyé par Folken Laëneck Voir le message
    ...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.
    Et un d'plus en moins !

  16. #16
    Membre chevronné
    +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...)
    .o0o__St@iLeR__oOo.

    Lead Developer

    ASP.NET MVC - MCP/MCSD ASP.NET
    PHP Zend Framework / PhalconPHP
    Cordova/Xamarin IOS/Android
    Kendo UI - ExtJS - JQwidgets
    SQL Server / MySQL

  17. #17
    Rédacteur

    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

  18. #18
    Membre actif
    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 ?

  19. #19
    Membre du Club
    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é.

  20. #20
    Membre habitué
    Citation Envoyé par eMeRiKa Voir le message
    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
    Et un d'plus en moins !

###raw>template_hook.ano_emploi###