Ou pourquoi pas dans une langue construite, indépendante d'une nation…
Sinon, +1 pour l'Unicode dans PHP6. Mais pourquoi seulement maintenant ?![]()
+1 pour l'unicode dans php6, comme ça plus de questions à se poser à l'avenir.
Veillez à bien faire les changements coté apache, db et (x)html
Petit lien d'aide pour le cas XAMP
http://electron-libre.fassnet.net/utf8.php
C'est malheureux mais je pense qu'il faut rendre obligatoire l'UNICODE.
Beaucoup trop de développeurs ne connaissent pas l'UNICODE ou l'UTF8 et vous code des appplis non adaptable en i18n.
Un véritable désastre. Pour que la société avance, il faut parfois forcer le changement.
L'anarchie à des limites ^^.
Non, plus sérieusement, cela sera un atout fabuleux pour PHP. Je pense que dans la politique de développement de ce langage, ce serait une bonne chose. Au bout de quelques mois, on verrait déjà la différence et les gains de temps seront nombreux, une fois que tous les développeurs auront compris l'intérêt de l'UNICODE.![]()
Pour info, Scott MacVicar souhaite retirer le switch unicode_semantics dès que possible du php.ini : http://marc.info/?l=php-internals&m=120991762731600&w=2
Après application de son patch, PHP 6 pourra encore gérer Unicode mais la configuration php.ini ne décidera plus si l'encodage par défaut est ANSI ou Unicode, ce sera obligatoirement l'un des deux (je ne sais malheureusement plus lequel).
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
entièrement d'accord, mais bon, les jeux de caractères est un domaine tout de même sacrèment obscure lorsqu'on y est pas sensibilisé et j'ai personnellement toujours penser que c'était vraiment un truc monté à coup de correctif et paliatif de couche et de surcouche.... bref un sujet pas forcément facile à prendre en main pour le quidam.
Je suis tout à fait d'accord, les jeux de caractères ont toujours été problématiques. Toutes les extensions PHP permettant d'accomoder différents jeux ne semblent d'ailleurs pas complètes (iconv et mbstring), et Unicode lui-même n'est pas 100% stable : http://feeds.feedburner.com/~r/blogspot/MKuf/~3/284051378/moving-to-unicode-51.html
Au passage, Google vient de diffuser un graphique intéressant :
![]()
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
Je pense que php a tout interet a un support a 100% de l'unicode (utf-8 ou 16). - D'un point de vue marketing pour seduire les pays emergeant dans l'industrie du net (inde, chine) qui ont des langues a script complex.
- D'un point de vue technique, c'est un pas de plus vers la standartisation du web.
- Pour nous dev, s'assurer de la lisibilite de nos site, car je prendraiss l'exemple du japonais pour lequel on est oblige de jongler entre 3 encodages. Autant la conversion unicode vers encodage exotique pose peu de souci que la conversion d'encodage exotique vers un autre encodage exotique c'est la loterie.
Graphique interessant, sa aurait était encore plus interessant d'avoir un découpage par technos, langues, extensions nom des domaines, brefs des informations pour comprendre un peu dans quelle contexte ce mouvement s'opère.
La team PHP à t'elle décidé d'une date de délibération au fait ?
Sinon par curiosité, en .net / java, ils sont déjà full unicode ?
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
Hum autant c'est une bonne chose que php puisse supporter un jeu de caractères supplémentaire, autant je vois mal comment la perte du support des jeux de caractères existants pourrait être un plus.
Pour mon cas personnel c'est bien simple: si php6 me permet de continuer à travailler en iso, j'upgrade mon installation le plus tôt possible dès sa sortie, et ensuite je commence à réfléchir à switcher de iso vers unicode. C'est un choix qui n'implique pas que les scripts mais également la base de données.
Si je ne peux que travailler en unicode avec php6, je serais obligé de tout faire en même temps, à supposer que je veuille le faire. C'est beaucoup plus compliqué, c'est risqué, en plus quand les gens s'amusent à me compliquer la vie ça ne me donne pas tellement envie de rouler avec eux. Pourquoi me forcer à implémenter deux changements de grande envergure simultanément? Est-ce que c'est çela qui est censé m'inciter?
D'autant plus que visiblement on cherche à me forcer la main; on me dit qu'Unicode est vachement mieux qu'iso... fort bien, dans ce cas il ne devrait pas y avoir de problèmes à me laisser le choix, non? Désolé, il y a vraiment quelque chose de suspect là-dessous. Plutôt que de m'inciter à passer à l'Unicode, cela ne fait que m'encourager à rester sur php5.
Ben tu resteras sur php5.
Ce n'est pas grave, il sera maintenu pendant encore longtemps.
Et encore heureux car moi je ne vais pas faire l'upgrade de mes sites juste pour le plaisir de passer a php6 et avoir de l'unicode ou les espaces de noms.....
Comme php4, on utilisera des handlers de apache et on continuera avec plusieurs versions de php sur un même serveur.
Ben si t'avais un boulet accroché au pied, Tu penses que tu irais mieux avec ou sans ? C'est toi qui voit.Hum autant c'est une bonne chose que php puisse supporter un jeu de caractères supplémentaire, autant je vois mal comment la perte du support des jeux de caractères existants pourrait être un plus.
L'argument majeur est que si le choix est laissé (c'est-à-dire si la directive unicode_semantics est conservée), de nombreux hébergeurs feront comme ils ont fait avec les autres directives problématiques : ils laisseront la configuration telle qu'elle est actuellement, mais avec une nouvelle version de PHP.
Résultat, nous avons encore des installations de PHP5 avec magic_quotes et/ou avec register_globals
Si les hébergeurs avaient tous pris un chemin raisonnable, ces directives auraient disparu depuis longtemps et il y aurait eu moins de problèmes de sécurité dans les sites Web, mais en contrepartie l'adoption de PHP5 aurait été plus difficile pour les utilisateurs.
Si ces directives disparaissent de PHP6, c'est uniquement pour obliger les utilisateurs à ne plus les utiliser. Il en va de même pour les autres directives jugées problématiques sur le long terme, et le PHP Group ne souhaite plus offrir de directive tellement problématique.
http://marc.info/?l=php-internals&m=120991997102886&w=2
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
Un boulet? Disons plutôt que c'est toi qui vois un boulet accroché à mon pied. Ca rend la situation entièrement différente.Ben si t'avais un boulet accroché au pied, Tu penses que tu irais mieux avec ou sans ? C'est toi qui voit.
Je comprends très bien que des gens puissent souhaiter la possibilité d'utiliser UNICODE pour eux-même. De là à vouloir empêcher les autres d'utiliser autre chose...
Au sujet de register_globals et des magic quotes: rien ne n'empêche qui que ce soit de choisir un hébergeur qui n'applique pas ces directives. Mince, on doit même pouvoir les désactiver localement au niveau des scripts (à vérifier, je ne fais jamais ce genre de choses car je suis mon propre hébergeur; d'ailleurs chez moi je n'ai ni les magic quotes ni register_globals, mais les autres peuvent bien faire ce qu'ils veulent). Tant qu'il se trouve du monde pour vouloir les utiliser, le support de ces directives est utile.
Alors ça c'est le plus drôle. Eh oui, ben je resterai sur php5... sauf qu'à la base, ils ont voulu booster la diffusion de l'UNICODE, c'est pour ça que son support risque fort d'être exclusif dans php6. Résultat: on nuit à la diffusion de php6... et donc à celle de l'UNICODE.Ben tu resteras sur php5.
J'ai bien peur de ne pas comprendre les enjeux et avantages de PHP6 Unicode.
Ok pour l'UTF-8 j'ai commencé à fonctionner comme ça depuis cette année (mise à jours des logiciels oblige et confort aussi ;-))
Mais quel est l'intérêt d'avoir un code PHP6 Unicode???
Cela permet notamment d'éviter les problèmes d'encodage lorsque tu donnes ton script à un autre développeur (ce qui est une pratique relativement fréquente dans le monde Open Source).
Mes articles - Zend Certified Engineer (PHP + Zend Framework)
Ressources PHP - Ressources Zend Framework - Cours et tutoriels pour apprendre PHP - Forum PHP
L'Unicode dans les scripts PHP est un inconvénient lorsqu'on utilise OpenLaszlo qui ne peut interagir avec les scripts PHP.
Dans le meme genre de remarques, on peut dire , que unicode est un inconveniant pour les langues ASCII-based en general. Arretons l'egocentrisme, avez-vous penser aux langues a script complex comme le chinois ou l'indi ? Je prend pas ces deux langues par hazardet ne vais pas m'etendre sur le sujet.
N'oublions pas que ZEND est a la base israelienne (langue = hebreu) c'est qui donne des elements de comprehension sur le choix de l'unicode.
Dernière modification par mon_nom_est_personne ; 21/05/2008 à 10h35.
Partager