Discussion :

[mon_nom_est_personne]

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.

[batataw]

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.

[Yogui]

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.

[batataw]

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 ?

[SirDarken]

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 &eacute.
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).

[Phelim]

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 ^^)

[Tchinkatchuk]

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

[Spir]

Maintenant je fais tout en UTF-8 perso. Donc je serai plutot pour l'Unicode obligatoire en PHP

[emmanuel.remy]

+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

[Oscar Hiboux]

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.

Et ça ?

Code :

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

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*

[batataw]

Et ça ?

Code :

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

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*

Ton exemple ne change pas ce que je pense:
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?

[zyongh]

Le PHP ne comprend pas l'hindou

OK... je sors

[RunCodePhp]

Ton exemple ne change pas ce que je pense:.

आज मेरी किस्मत अच्छी है

Seras-tu deviner que fait cette méthode?

Ok ...
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.

Le PHP ne comprend pas l'hindou

Code :

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

1
2
3
4
5
function php_ça_décoiffe() {
	echo 'Ok ...<br />';
}
 
php_ça_décoiffe();

C'est délirant, mais ça marche.
Php comprend l'Français en tout cas

[batataw]

Ok ...
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.

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.
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.

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 ?

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.

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é.

Qui se plaindrait d'avoir un site gérant nativement le multi-langues ou d'avoir une grande portabilité?
Mais la encore une fois tu parles de l'explotation des données pas du code PHP en lui meme.

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.

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.

[RunCodePhp]

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.

Je l'ai fais exprès ...
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. )


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() {}

[batataw]

Je l'ai fais exprès ...
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. )

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.

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 ?

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.

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() {}

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.

[RunCodePhp]

Pour ma part, la solution a été donné dès le début, sous forme de question certes, mais elle me suffit :

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

Tout avoir en Unicode obligerait tout le monde à utiliser UTF-8 pour l'encodage des 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 ?).

Un seul encodage comprenant toutes les langues, cela améliorera la portabilité.
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.

C'est pas le probleme de savoir si c'est un inconvénient

Et bien si, car s'il n'y a pas d'inconvénient, c'est donc un avantage.
C'est 0 ou 1

Code :

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

De toute facon a bien y réfléchir y'a pas trop de soucis a faire aujourd'hui un site multilingue

Et bien si, justement, et l'UTF-* ne fera qu'améliorer les choses.

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.

[Oscar Hiboux]

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 !

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.

[a028762]

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 ) 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().

[batataw]

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 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.

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.

Encore une fois je ne dis pas non, ça serait absurde de refuser l'UTF8, je dis juste pas le tout UTF8.

Code :

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

De toute facon a bien y réfléchir y'a pas trop de soucis a faire aujourd'hui un site multilingue

Et bien si, justement, et l'UTF-* ne fera qu'améliorer les choses.

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

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.

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 !

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.

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.