Le bug dont je parle est toujours la au moment ou je vous parle
la communauté d'entraide francophone dédiée au PHP
coloration syntaxique pour php
scite définit l'encodage utf-8 en rajoutant un caractère utf-8 au tout début du fichier afin de le forcer ce qui buggue quand le fichier php est utilisé par apache. la bonne configuration est en fait utf8-cookie comme dit précédemment mais le fichier se réouvrira systèmatiquement en ascii. L'ascii (valeur par défaut de l'encoding qui est sujette à un bug et donc inreconfigurable) est une valeur strictement égale à l'utf8 tant que le fichier ne présente aucun caractère "spécial" tel que les accents les cédilles etc.
Le bug dont je parle est toujours la au moment ou je vous parle
Le bug dont je parle est toujours la au moment ou je vous parle
Fait du php depuis que ca existe ou presque
Ce bug apparaissait déjà à l'époque (il y a 2 ans à peu prêt) où je l'utilisais. La solution était : avant d'écrire quoi que ce soit dans le fichier, il fallait déjà spécifier un encodage utf-8, écrire un caractère non accentué (genre a), l'effacer, et enregistrer le fichier. Après, à chaque ouverture, il s'ouvrait en utf-8. Mais bon, pas simple hein 
.
.« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
Ça résume bien les informations que j'ai pu trouver sur l'Internet.scite définit l'encodage utf-8 en rajoutant un caractère utf-8 au tout début du fichier afin de le forcer ce qui buggue quand le fichier php est utilisé par apache. la bonne configuration est en fait utf8-cookie comme dit précédemment mais le fichier se réouvrira systèmatiquement en ascii. L'ascii (valeur par défaut de l'encoding qui est sujette à un bug et donc inreconfigurable) est une valeur strictement égale à l'utf8 tant que le fichier ne présente aucun caractère "spécial" tel que les accents les cédilles etc.
Le bug dont je parle est toujours la au moment ou je vous parle
En gros, s'il n'y a pas de caractère UTF-8 dans le fichier, l'éditeur ouvrira le fichier en ascii par défaut à moins d'utiliser des commentaires qui indiquera à l'éditeur que le fichier doit être ouvert en UTF-8 et/ou inclure quelques caractères UTF-8.
Cependant j'ai une question:
Pourquoi désirez-vous absoluement que le fichier soit ouvert en UTF-8? Il n'y a aucune différence entre un fichier encodé en UTF-8 et un fichier encodé en ANSI.
2 fichiers différents ayant tous les 2 le même contenu: "Contenu".
L'un est encodé en UTF-8 et l'autre ANSI:
# md5sum ascsii.txt utf8.txt
af847154bed567994563d7d91870c0c2 ascsii.txt
af847154bed567994563d7d91870c0c2 utf8.txt
Le même test mais avec le contenu suivant: "Accentué".
Encore une fois, l'un est encodé en UTF-8 et l'autre en ANSI:
# md5sum ascsii.txt utf8.txt
e280c13f86d2a8d68222f5ebdf651e46 ascsii.txt
cc19e564fa813b2921cfb1b991bf40c9 utf8.txt
Donc tant qu'il n'y a pas de caractère accentué, il n'y a AUCUNE différence entre un fichier UTF8 et un fichier ASCII. Ils sont identiques!
Comment l'éditeur fait pour différencier l'encodage s'il n'y a pas de caractère UTF-8? Il ne peut tout simplement pas. Enregistrer un fichier qui ne contient que des caractères ASCII avec un encodage UTF-8 est inutile.
La programmation est l'expression de la poésie d'un programmeur
Génération PHP
Génération PHP
En effet aucun éditeur ne sait ouvrir un fichier en UTF-8 s'il n'y a ni BOM (les fameux 4 octets en début de fichiers qui foutent le bordel dans les headers et les includes) ni caractères accentués typiques.
Personnellement j'attends tout de même que mes fichiers soient toujours ouverts/enregistrés en UTF-8 sans que je n'ai à y penser, tout simplement parce que dans les commentaires, ou dans les fichiers de vue, ou je ne sais quoi encore, je peux mettre des accents et je n'ai pas envie d'avoir à chaque fois me poser la question.
Les trois solutions que je préconise :
Personnellement j'attends tout de même que mes fichiers soient toujours ouverts/enregistrés en UTF-8 sans que je n'ai à y penser, tout simplement parce que dans les commentaires, ou dans les fichiers de vue, ou je ne sais quoi encore, je peux mettre des accents et je n'ai pas envie d'avoir à chaque fois me poser la question.
Les trois solutions que je préconise :
- Utiliser un vrai éditeur qui gère l'encodage au niveau du projet (on lui dit quel est l'encodage du projet, puis les exceptions par fichier), genre... eclipse
- Utiliser un vrai OS qui travaille directement en UTF-8 partout, ce qui simplifie tout le travail puisque du coup tous les éditeurs encodent les fichiers en UTF-8 sans avoir à se poser la question (on retombe sur le même pb quand on veut faire du latin-1), genre... Linux, toutes distros confondues
- Toujours spécifier l'encodage en commentaire au début du fichier :
"// coding: UTF-8" à la première ligne du script
"<!-- coding: UTF-8 -->" juste en dessous du doctype
Ça ne peut de toute façon pas faire de mal, et si on bosse sous windows avec des éditeurs "light" on ne peut de toute façon pas y couper, et ça marche au moins parfaitement sous SciTE.
Parce que c'est dans les specs !Pourquoi désirez-vous absoluement que le fichier soit ouvert en UTF-8?
En fait, surtout parce que ce sont essentiellement des XML qui transitent d'une plateforme à une autre
et que les pétouilles d'affichage de caractères spéciaux sont assez peu prisées.
Comme l'a démontré le test de Xenon_54, il n'y aucune différence entre l'uft-8 et l'iso-8859-1(5) lorsque nous n'avons pas de caractères accentués. Mais là où ça devient intéressant, c'est quand on travaille entre divers applications dans divers langues avec divers formats de fichiers. Dans ce cas, si tout le monde est en utf-8, ça simplifie énormément la vie !
Conclusion, il faut développer un projet de A à Z en UTF-8.
Conclusion, il faut développer un projet de A à Z en UTF-8
.« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
Code : Tout sélectionner
/**
* TITRE
*
* @author Moi
* @version La nouvelle
* <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
*/J'ai une autre version pour les CSS et une autre pour les Javascript.
En gros, cette ligne dit à Dreamweaver d'ouvrir ce fichier selon l'encodage spécifié.
Moi qui jongle avec des tas d'encodages différents, c'est un pas de géant.
Modifié en dernier par icebreak le 10 avr. 2008, 10:06, modifié 1 fois.
---
J'adore
.« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »
Hoa : http://hoa-project.net (sur @hoaproject).
Hoa : http://hoa-project.net (sur @hoaproject).
Mammouth du PHP |
2937 Messages
De quoi rappeler le sketch de Dany Boon sur la Poste, avec le préposé parlant au micro sans parvenir à se faire comprendre.
"Eh ! la Mairie de Paris, on ne comprend rien ! Was ist das? lis pas l'allemand."
Et c'est là que le panneau affiche le message suivant : "Vous êtes aveugle ou quoi ? Je voulais vous dire : il n'y a rien à lire sur ce panneau".
Ben pour le sujet que j'ai poster pour DW je peux dire :
ca gère l'UTF-8 a la perfection, suffit d'enregistrer comme paramètre l'encodage des nouveaux document et a chaque création il vas directement faire un fichier utf-8 avec le bon doctype.
Et en plus la coloration syntaxique est vraiment bien et supportée pour tout les langages et feuilles de styles : php, css, javascript, html etc ...
Enfin je dis ca c'est pas pour troller hein :p
ca gère l'UTF-8 a la perfection, suffit d'enregistrer comme paramètre l'encodage des nouveaux document et a chaque création il vas directement faire un fichier utf-8 avec le bon doctype.
Et en plus la coloration syntaxique est vraiment bien et supportée pour tout les langages et feuilles de styles : php, css, javascript, html etc ...
Enfin je dis ca c'est pas pour troller hein :p
En fait si tu troll.
Parceque si tu définis un encodage par défaut, c'est logique que ça va marcher.
Je crois que la plupart des éditeurs font ça.
L'ennui avec DW, c'est que si tu changes d'encodage par défaut, il te fout l'encodage précédent en l'air pour peu que tu ai des caractères non-reconnus.
C'est d'ailleurs chez les codeurs Japonais sous DW, la première source d'ennuis. Ma solution à le mérite de marcher. De l'ISO à L'UTF-8 tu risque pas trop de problèmes, mais du SJIS au UTF-8 et inversement, c'est la bérézina.
Parceque si tu définis un encodage par défaut, c'est logique que ça va marcher.
Je crois que la plupart des éditeurs font ça.
L'ennui avec DW, c'est que si tu changes d'encodage par défaut, il te fout l'encodage précédent en l'air pour peu que tu ai des caractères non-reconnus.
C'est d'ailleurs chez les codeurs Japonais sous DW, la première source d'ennuis. Ma solution à le mérite de marcher. De l'ISO à L'UTF-8 tu risque pas trop de problèmes, mais du SJIS au UTF-8 et inversement, c'est la bérézina.
---