Version imprimable
Desole si t'y a vu de l'agressivite, car il en etait rien. Nous sommes la pour partager comme tu l'as si bien dit, et a ce titre, Je voulais juste pointer le fait que dans ce genre de discution a portee globale, limitee son raisonnement a la seule faisabilite en france empeche de voir le fond du probleme comme je l'ai exposer par la suite.
Je n'arrive pas a voir l'interet d'avoir de l'Unicode dans le code PHP. Je vois tres bien l'interet pour les données (base de données ou chaine de caracteres) mais pas pour le code lui meme.
Partager ses sources va devenir problematique si le code PHP differe en fonction du langage de chaque pays.
Oui a l'Unicode mais je vois d'un mauvaise oeil du code avec des caracteres accentués...
Je suis plutot pour renforcer le support I18n natif.
Il faut bien voir que tes scripts ont déjà un encodage, que tu en sois conscient ou non. Vois avec ton éditeur favori quel encodage il utilise par défaut.
L'intérêt d'Unicode est justement d'uniformiser les jeux de caractères dans les scripts, principalement pour les chaînes de caractères (messages d'erreurs en clair, etc.). Sans Unicode, chaque jeu de caractères a son propre encodage (ou même plusieurs encodages possibles), ce qui complique justement le partage de source. Avec Unicode, tu sais au moins que tous les scripts PHP6 sont avec un jeu de caractères Unicode, il y a donc un moins grand potentiel d'erreurs ;)
C'est principalement pour une question d'harmonisation des scritps et des traitements.
Je comprends tres bien que mon editeur a un encodage par defaut mais comme tous ce qui concerne I18n se trouve a l'exterieur de mon code, je n'ai pas vraiment de soucis. Je passe sans probleme du Notepad a Eclipse...mes données sont en base encodées en UTF8.
Maintenant comment éviter que les codes des uns et des autres soient écrits dans leur langue d'origine ?
Je suis loin du débat et d'avoir le recul propice à y mettre mon grain de sel, mais si par miracle je me debarrasse enfin de ses problèmes d'accents, je suis pour.
J'ai beau avoir lu plusieurs tutos, et demander 250 fois de l'aide j'arrive jamais a ce que le truc soit parfait (j'en revient même à coller des é).
Donc oui pour l'idée en gardant l'ancien système pour ceux qui comprennent le pourquoi du comment (moi un jour p-e).
De mon experience personnel, pour faire de l'utf8 correctement, il faut a tout prix avoir la chaine de process complète en utf 8.
De la base de donnée au navigateur de l'utilisateur. Les fonctions de conversion charset en utf8 ne marche que pour les caracteres d'un jeux standart (ou alors j'ai jamais rien compris ^^)
A partir du moment ou j'ai commencé à faire ça, ça tournait tout seul avec absolument aucune difference par rapport à un environnement ISO.
En faite, c'est vraiment pas sorcier ;) Y'a rien a changer à part 2 ou 3 habitudes (penser à fixer les entetes des fichiers html et les headers, passer la database en utf8 et c'est a peu pret tout ^^)
En effet, si on connait bien le process, il n'y a pas plus de soucis qu'avec l'ISO et même surtout beaucoup moins.
Le problème est le peu de connaissances des développeurs en général, d'ou une impréhension que cela conmplique.
Quand on explique à un non initié le principe et qu'il le met proporement en place, il découvre le monde merveilleux de l'encodage :mrgreen:
Maintenant je fais tout en UTF-8 perso. Donc je serai plutot pour l'Unicode obligatoire en PHP
+1 il suffit de lire les messages des forums, AJAX par exemple, où seul l'UTF-8 est reconnu. Cela cause conflit sur conflit...
La période d'adaptation sera peut-être un peu longue pour toute la chaine concernée (base de données, ...) mais au final je pense qu'on sera gagnant.
Mais par contre, qu'on ne nous refasse pas le coup fdans 2 ans de nous dire que l'utf-16 est mieux... Si c'est le cas autant y passer de suite !
ERE
Et ça ?Citation:
Envoyé par batataw
:aie:Code:echo 'Héhéhé !';
Pour reprendre le fil, je ne sais pas à quel point on va avoir besoin d'UTF-16 et à quel terme, mais comme le dit Emmanuel il serait peut-être bon qu'ils y pensent rapidement.
Pour ma part je suis bien d'accord pour passer PHP en UTF-8 par défaut. La restriction à ce seul jeu de caractères pose, malheureusement, un problème évident de compatibilité avec le passé et, effectivement, tant qu'on n'impose rien on devra composer avec certains scripts dinosaures pour encore longtemps...
*à tendance radicale pour l'UTF-8* :mouarf:
Ton exemple ne change pas ce que je pense:Citation:
Envoyé par Oscar Hiboux
Je vois tres bien l'interet pour les données (base de données ou chaine de caracteres) mais pas pour le code lui meme
Nous avons besoin de l'UTF8 ou UTF16 en standard mais je ne suis pas convaincu qu'il fallait aller jusqu'a autoriser le tout UTF dans le code. J'aurais préféré un model avec par exemple des fichiers ayant une extension .utf8 ou .utf16 ou les données y seraient stockées. Le risque est se retrouvrer avec des noms de fonctions, de variables et des commentaires indéchiffrables.
आज मेरी किस्मत अच्छी है
Seras-tu deviner que fait cette méthode?
Le PHP ne comprend pas l'hindou :mouarf:
OK... je sors :arrow:
Ok ...Citation:
Envoyé par batataw
Mais là tu sous entends qu'il faudrait restreindre un type d'encodage pour un langage de programmation (ou autre logiciel) pour éviter d'avoir ce genre de cas de figure.
Crois tu que c'est à l'encodage de régler ce problème ?
Ce serait plutôt au langage lui même (ou autre logiciel) d'y mettre cette restriction, non ?
Pour ma part c'est un faut problème, et c'est tant mieux si le utf-8, utf-16, etc ... se généralise, ça ne peut qu'améliorer la portabilité, et la facilité pour générer des site, doc, etc ... multi-langues, et de leur accessibilité.
Faut pas perdre de vu aussi qu'un fichier contenant du code contient aussi des commentaires, ceci dans le but de générer une documentation.
Comment faire dans ce cas là si le code contient des commentaires dans plusieurs langues ?
Ceci sera possible sans se poser la question de l'encodage de telle ou telle langue.
Un seul encodage, et tout reste cohérent.
Citation:
Envoyé par david drapeau
C'est délirant, mais ça marche.Code:
2
3
4
5
Php comprend l'Français en tout cas :mouarf:
Non tu m'as mal compris, je sous-entendais surtout que l'interet du tout UTF n'est pas la meilleur réponse. Objectivement quand et ou as-tu besoin de l'UTF8. Pour ma part c'est essentiellement pour les données a afficher ou a traiter. Je comprends tres bien que l'on apporte un grand soin a cette partie.Citation:
Envoyé par RunCodePhp
J'attendais surtout une grande simplification dans l'utilisation de données UTF8. L'encodage actuel (latin) ne me génait pas dans la mesure ou mes données UTF8 sont dans ma BD.
C'est justement ce que je dis l'UTF8 va etre généraliser donc les variables, les methodes, les classes pourront avoir l'encodage qu'elles souhaitent. Il n'y a pas de restriction de prévu donc attends toi a des surprises. Et puis on ne peut pas d'un coté demander le tout UTF8 et de l'autre dire oui mais je veux certaines restrictions pour éviter les erreurs.Citation:
Envoyé par RunCodePhp
Qui se plaindrait d'avoir un site gérant nativement le multi-langues ou d'avoir une grande portabilité?Citation:
Envoyé par RunCodePhp
Mais la encore une fois tu parles de l'explotation des données pas du code PHP en lui meme.
Et voila ce que je craignais, l'encodage UTF8 va finir par etre utiliser pour avoir des commentaires dans toutes les langues. Bonne chance pour le travail collaboratif.Citation:
Envoyé par RunCodePhp
Je l'ai fais exprès ... :mouarf:Citation:
Et voila ce que je craignais, l'encodage UTF8 va finir par etre utiliser pour avoir des commentaires dans toutes les langues. Bonne chance pour le travail collaboratif.
Mais il ne faut pas prendre les choses au "pieds de la lettre".
Cet exemple démontre tout l'avantage d'avoir 1 seul et unique encodage.
Ceci est exactement le même problème que tous les langages de programmations, tous sans exception : On ne pourra pas interdire à un codeur de mal coder, même avec le meilleur langage du monde ... ce n'est pas possible.
Php en est l'exemple type, car on peu tout faire, et surtout du n'importe quoi, quasi tout est permis.
Faut il pour autant utiliser tout ce qui est permis ?
La réponse est non, c'est au codeur de coder correctement, d'éviter les absurdités, tout langages confondus.
Bref ... comme tout langage, il y a la bonne pratique et la mauvaise.
(heeeuuu, pour ma part, la bonne pratique c'est pas pour demain, soit dit en passant. :aie: :mrgreen:)
Puis dans toutes solutions il y a des avantages et des inconvénient, sans exception.
Faut juste mettre tout ça dans une balance, et voir ou elle penche.
Pour ma part il n'y a pas photo, l'utf-* apportent tellement d'avantages qu'il est normal que Php prenne cette voix là.
S'il y a quelques fous furieux pour créer du code dans leur propre langue, et bien tant pis. On s'en passera.
Et puis, qui sait, un codeur pourrait le traduire en bon Anglais, comme c'est le cas pour les docs. Où est le problème ?
Puis s'il y a un autre inconvénient, et bien on fera avec, ou sans.
Mais les avantages sont là, biens présents.
Faut il pour autant abandonner cette solution ?
Crois tu qu'ils seront aussi nombreux ces fous furieux ?
Ne peux tu pas créer ton code en UTF-8 ou 16 ... et respecter la langue du langage où elle a été écrite ?
Franchement ... c'est loin d'être un inconvénient ...
Ca fait à peine fléchir la balance à coté des nombreux avantages.
Faudrait créer un club pour lutter contre : function php_ça_décoiffe() {} :france: :salo:
Tu fais fausse route, les développeurs quelque soit le langage font ce qu'ils veulent. Mon idée ce n'est certainement pas de conserver le Latin pour les surveiller et les empecher de faire des bétises. Seulement les avantages que tu avances je les ai déja entendu et je ne trouve pas ca transcendant.Citation:
Envoyé par RunCodePhp
Encore une fois la question n'est pas: s'il faut ou pas de l'UTF8 dans PHP, c'est une évidence. Bien sur que UTF8 a besoin d'etre repensé. Cependant a-t-on besoin que tout le code PHP soit en UTF8. Si tu as des exemples ou c'est indispensable je suis preneur.Citation:
Envoyé par RunCodePhp
C'est pas le probleme de savoir si c'est un inconvénient, l'idée c'est de trouver la bonne métrique. Franchement le seul grand avantage que je vois au tout UTF8 concerne plutot les EDI pas les developpeurs ou les sites Web. De toute facon a bien y réfléchir y'a pas trop de soucis a faire aujourd'hui un site multilingue.Citation:
Envoyé par RunCodePhp
Pour ma part, la solution a été donné dès le début, sous forme de question certes, mais elle me suffit :
Un seul encodage comprenant toutes les langues, cela améliorera la portabilité.Citation:
Envoyé par Yogui
Il faut cependant que tous les langages se mettent au diapasons, au minimum ceux qui gravitent autour de Php dans notre cas, comme les IDE par exemples, et les codeurs évidemment.
Par la suite, ce n'est que la transition (genre ISO vers UTF) qui risque d'être un peu pénible, mais ce n'est que provisoire. Enfin, j'ai idée qu'il y aura toujours des résistants.
Je suis passé de l'iso à l'utf-8, ca été un peu douloureux, mais je trouve qu'au bout ça été bénéfique.
Reste une bibliothèque qui fait de la résistance : FPDF, qui elle n'accepte pas l'UTF-8, obligé de décoder.
Et puis chacun à le droit d'avoir son avis, c'est l'objet du topic.
Tu n'est pas pour le passage en tout UTF-8, et bien soit. ;)
Et bien si, car s'il n'y a pas d'inconvénient, c'est donc un avantage.Citation:
C'est pas le probleme de savoir si c'est un inconvénient
C'est 0 ou 1 :mouarf:
Et bien si, justement, et l'UTF-* ne fera qu'améliorer les choses.Code:De toute facon a bien y réfléchir y'a pas trop de soucis a faire aujourd'hui un site multilingue
Imagine donc un site multilangue dont les traducteurs te fournirais tantôt un fichier au format ISO, un autre en Cyrillique, allez hop ... etc etc ...
Si tu devais faire une moulinette en Php, tu fais comment aujourd'hui sans le UTF-8 ?
Pas le choix d'utiliser des fonctions spécifiques pour chaque encodage pour les déposer dans la BDD.
Grâce à l'utf-*, même plus besoin de moulinette, on récupère les données, on les dépose tel quel dans la Bdd. Si tous les traducteurs utilisent le même encodage : UTF-8, évidemment.
Bah... c'est simple, rien que pour l'interopérabilité et le tavail d'équipe il faut trouver une norme. "Qui peut le plus peut le moins", choisissons l'UTF-8 et hop.
Si certains ont des problèmes ou simplement des frissons à voir apparaître du chinois dans les commentaires de code ils n'ont qu'à pas travailler en chinois. Sérieusement... fermez les fenêtres il pleut des caractères chinois ! :aie:
Tiens, tant que je passe par là : ce matin je suis tombé sur le code d'un développeur qui, n'ayant visiblement pas l'esprit très ouvert à ces préoccupations, avait écrit cette expression régulière : [’\[\]\#\&;:\?\-*~`´\)\(\=%\!\”\"\']{1} mais dans un endodage différent de ce qui était préconisé... drôle.
Bonjour,
un des fous-furieux qui codaient en français (style function çadécoiffe)
car mon cerveau travaille en français et en aucun cas en UTF-8 (ce que je déplore :calim2:) Gnarf gnarf !!!
Si j'ai abandonné cette manie, c'est face à des contextes/languages écrits majoritairement en anglais, certains programmes ne passaient pas du tout,
mais je resiste quand même en écrivant des fonctions qui sont lisibles ... par un français ... function DecoderVariation().
Et ce n'est qu'un début; ce genre de problème me fait dire qu'il faut vraiment une transition en douceur. Je ne me vois pas réécrire des librairies car mon site à migré en tout UTF8.Citation:
Envoyé par RunCodePhp
Encore une fois je ne dis pas non, ça serait absurde de refuser l'UTF8, je dis juste pas le tout UTF8.Citation:
Envoyé par RunCodePhp
Faut pas exagérer des sites multilingues y en a à la pelle cependant oui dans le cas que tu exposes ça pose problème et encore comment comptes-tu empêcher un traducteur de te filer un format autre que UTF8. Il fera la traduction avec l'éditeur en sa possession. Va lui dire j'exige de l'UTF8 quand il te filera un fichier Excel avec toutes les traductions. Les sites sur lequelles je travailles, pour des raisons pratiques les traductions sont faites en BDD. Ca permet d'avoir un back office facile à mettre en oeuvre. Oui un site sans BDD ça pose problème.Citation:
Envoyé par RunCodePhp
Oui ca va régler certaines problèmes, oui un standard c'est toujours mieux que la pseudo-anarchie actuelle cependant il faut faire les choses en douceur.Citation:
Envoyé par Oscar Hiboux
Certes, en douceur. Ça fait combien d'années maintenant qu'on traîne ces problèmes ?.. :mrgreen:
Je suis bien d'accord, j'exagère un peu.
Bonjour,
je suis en train de passer tout un site en utf-8 et je me heurte à un problème de taille.
Faut-il remplacer toutes les fonctions de traitement de caractères (strlen, strpos, substr, ...) par leur équivalent mb_* ?
Ou il y a moyen de régler ça direct dans le php.ini ou une autre solution ?
Je crois également que même certaines fonctions de la famille array sont impacté par l'utf-8 :aie:
oui ca peu se régler dans le php.ini avecCitation:
Envoyé par FrontLine
mbstring.func_overload
http://www.php.net/manual/fr/mbstring.overload.php
pour les array faudrait, voir du coté de intl avec Collator
http://fr2.php.net/manual/fr/class.collator.php
;)
mais bon, j'ai jamais vraiment eu de soucis de se genre, ta un exemple d'utilisation qui ne marcherait pas ?
Merci pour ta réponse !
J'ai testé l'overload de mbstring mais apparemment il n'est pas stable (lu dans la doc). Par exemple j'ai planté l'accueil d'un Mediawiki installé en local. Après avoir modifié un peu les réglages de mbstring c'est rentré dans l'ordre (j'ai mis à 4 l'overload et modifié 2 ou 3 autres valeurs).
En tout cas c'est déjà une solution que je vais utiliser.
Pour les array je n'ai pas testé, j'ai simplement lu dans la doc. Je regarderais en profondeur pour voir si il y a une réel impact.
Sinon pour str_* echo strlen('éà') = 4 caractères au lieu de 2.
Collator je ne connaissais pas, je regarde de plus près :)
ma question était plus dans l'intérêt de faire quelque chose du genre, dans quel but t'as besoin de faire un strlen('éà')Citation:
Envoyé par FrontLine
Vérifier les données d'un formulaire par exemple
oui, ca me herisse le poil.
on entend partout 'logiciel libre", etc..
et la, quoi.?? on veut nous imposer un type d'encodage.???
deja, rien que ca, parceque au final, c'est ca, ca me herisse le poil.
alors, sous couvert de soit disant compatibilité, etc, des arguments falacieux, on obligerait les gens à passer sous un encodage qui ne leur convient pas forcement, voir meme pourrait completement les desservir..
alors, non, imposer un type d'encodage, c'est de la mega connerie.
c'est une politique de faineants sans imagination.
si c'est ca la philosophie de la team aux commandes aujourdhui, ca fait peur pour la suite de php.
parallele simple. c'est comme si aujourdhhui, toutes les emissions de radio et televisions etaient faites en anglais uniquement pour faciliter la circulation de l'information..
c'est pas de l'imperialisme ca.??:furieux:
oui à l'intelligence, à la possibilité d'apprendre, non à l'imposition d'une uniformisation sterile.
Ca sent pas un peu le troll ?
L'encodage ne force pas la langue de diffusion de ton contenu... ou alors j'ai loupé un épisode :aie:
La comparaison avec la radio...rien à voir :(
une belle reponse de queqlu'un qui n'a pas lu ni compris le message.
ce n'et pas l'utf8 ou autre que je critique, mais le fait qu'on veuille nous imposer tel ou tel encodage.
s'ils continuent dans cette voie, on verrra forcement fleurir des moyens de detourner ce choix fait par une minorité, et imposé aux autres, et un ou plusieurs fork de php pourraient bien voir le jour.
bravo ensuite pour l'interoperabilité..
maintenant si on nous balance que les developpeurs n'arrivent pas à comprendre le principe d'encodage, au secours, c'est pas des developpeurs, c'est des nazes.
la vie ne se satisfait pas de l'uniformité.. elle aime la diversite.
l'informatique, ca fait partie de la vie, et ca respecte les memes principes.
Si on part là dessus disons que tu n'as pas lu mon message également, je parlais de ta comparaison qui n'avais pas trop de rapport.
Après tout l'informatique c'est construit sur des normes, divers standards...
Je ne vois pas en quoi imposer un encodage à PHP est un problème de liberté.
Les gens resteront libre de forké au besoin.
Je trouvais juste que tu partais un peu loin dans ton message sur "l'imposition".
Juste un avis :)
Franchement, foutaise, mais vraiment. :aie:Citation:
c'est comme si aujourdhhui, toutes les emissions de radio et televisions etaient faites en anglais uniquement pour faciliter la circulation de l'information..
la vie ne se satisfait pas de l'uniformité.. elle aime la diversite.
L'informatique, comme n'importe quel secteur, entre autre l'industrie, les normes, les conventions, ou autres soit disant standard qui laisserait croire que c'est pour offrir plus de choix aux utilisateurs, c'est du vent.
Chaque éditeur de logiciels tenterait plutôt d'imposer leur standard qui serait soit disant mieux que les autres, et si un y parvient, c'est le Jackpot, le roi du pétrole.
Bref, le but, c'est avant tout une histoire de gros sous, rien de plus.
Puis que la nature soit diversifiée oui. Du moins, elle l'était. :aie:
Mais l'Homme (avec un grand H parait il) fait justement tout pour qu'il n'y ait plus cette diversité.
Il n'y a qu'à voir les dégâts qu'on fait.
Par nature, l'Homme n'aime pas l'imprévisible, alors il crée des normes pour ça, de la standardisation.
L'informatique n'y échappe pas.
Donc crier scandale que Php tenterait d'imposer un encodage. Peut être, voir surement.
Cependant, on va pas me faire croire que c'est mieux chez les autres.
Du vent ...
Et pour la comparaison avec la télé ou radio, il fallait trouver mieux, car là, c'est tout l'inverse.
En France, et aussi dans les DOM, c'est la TNT ... et rien d'autre dans quelques mois ... plus l'ombre d'un signal analogique dans peu de temps.
Vive la diversité. :P
Mais encore mieux.
Si tu as la bonne idée de venir à la Réunion avec ta super Télé dernier crie et son décodeur/adaptateur TNT intégré ... pas d'bol ... en France le standard c'est du MPEG2 et à la Réunion du MPEG4.
T'est bon pour aller courir acheter un autre décodeur.
Vive la diversité. :aie:
Plus sérieusement, et quand bien même que je ne suis pas un codeur professionnel, ça fait quelques années maintenant que je fais du Php, et à mon sens, avoir un vrai standard universel serait justement une aubaine.
On code avec un seul encodage, on partage ce code au travers la planète tout entière, et on a plus à se poser la question si celui qui le reçois va pouvoir l'exploiter.
L'utf8 devait apporter ça si j'ai bien compris, et c'est justement ça l'interopérabilité, non ?
A l'inverse, si je code en utf-8, et qu'un autre me donne un code en ISO, puis un autre en ANSI, et encore un autre un Windows 1200 je ne sais quoi, et bien c'est justement tout sauf de l'interopérabilité.
Je dirais plutôt un vrai cauchemar.
J'suis plutôt d'accord. ;)Citation:
Envoyé par yannux
Ca cri au scandale, mais dans le fond, on ne sait pas vraiment pourquoi. :?
Ceci dit, si la politique de Php ne correspond pas à sa philosophie, et bien il suffit d'utiliser un autre langage, non ?
Que je sache, Php n'est pas le seul langage pour faire un site Web, non ?
Finalement, de la diversité, il y en a. :D
Puis vu que c'est l'open Source qui a l'air visé, il y a une petite blague qui comparait ces 2 mondes (libre/payant) que j'aime bien.
Je cite (en gros) : "Il y a moins bien, mais c'est plus cher". :mouarf:
Une vrai question d'ailleurs par rapport à ce utf-8.
Quand est il des autres langages d'ailleurs, comme ASP, JSP, Python, Perl, etc ... par rapport à Php.
En faite, la question sous entendue que je me pose, c'est :
Est ce que la communauté Php tenterait d'innover en proposant nativement de l'UTF-8 ?
Où bien est ce plutôt pour tenter de rattraper un retard, car les autres langages eux le sont déjà ?