coloration syntaxique pour php

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : coloration syntaxique pour php

par icebreak » 10 avr. 2008, 10:08

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.

par agité » 10 avr. 2008, 10:03

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

par Victor BRITO » 09 avr. 2008, 22:54

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

:mrgreen:

par Hywan » 09 avr. 2008, 12:36

J'adore :mrgreen:.

par albat » 09 avr. 2008, 12:10

par icebreak » 09 avr. 2008, 11:40

Code : Tout sélectionner

/** * TITRE * * @author Moi * @version La nouvelle * <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> */
J'ai pris l'habitude sous DreamWeaver de rajouter la dernière ligne dans mes commentaires phpDoc.
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.

par Hywan » 09 avr. 2008, 11:37

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

par albat » 09 avr. 2008, 08:25

Pourquoi désirez-vous absoluement que le fichier soit ouvert en UTF-8?
Parce que c'est dans les specs ! :langue:

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

par naholyr » 09 avr. 2008, 08:03

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 :
  • 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 :P
  • 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.

par Xenon_54 » 09 avr. 2008, 05:11

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 :)
Ça résume bien les informations que j'ai pu trouver sur l'Internet. :)

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.

par Hywan » 07 avr. 2008, 15:08

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

par Nagol » 07 avr. 2008, 14:45

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

par Hywan » 07 avr. 2008, 12:12

vim accepte également cette syntaxe (mais il faut le coder il me semble). On passe quelques paramètres de cette façon :

Code : Tout sélectionner

vim:expandtab,tabstop=4,shiftwidth=4,encoding=utf-8,...
et à l'ouverture, hop il applique ses paramètres.

Mais c'est pas très propre de redéfinir l'encodage de cette façon.

par naholyr » 06 avr. 2008, 23:24

Et l'ajout de "coding: UTF-8" dans les deux première lignes du fichier (en commentaire par exemple) ? C'est ce qui fonctionne pour SciTE et quelques autres éditeurs.

par albat » 06 avr. 2008, 22:22

Il faudrait enregister le fichier au format "UTF-8 with BOM".
Cependant Apache/PHP n'aimera pas ce BOM, donc on est pas plus avancé. :)
Ouf ! Tu m'as fait peur... :langue: