Bulle d'aide (tooltip) en javascript

Bonsoir à tous,

voilà j'utilise SciTE depuis pas mal de temps, et je commence à être aggacé de devoir (re)selectionné le mode d'encodage UTF-8 à chaque fois que je le lance. En effet, l'encodage se met sur 8 Bit à chaque fois que je le lance et je n'arrive pas à mettre la main sur le bonne variable dans le fichier de configuration de SciTE. Si quelqu'un sait comment faire donc...

De plus, je lis sur OpenWeb :

Steve Frécinaux a écrit :

SciTE : éditeur très léger, sous Windows et Linux, qui gère la coloration syntaxique, l'UTF-8 et l'ISO-8859-1, de façon très souple. L'un de mes préférés. Attention, dans le cas de SciTE, l'enregistrement sans BOM se fera en sélectionnant le jeu «UTF-8 Cookie».

J'aurrais aimer savoir ce que signifie exactement "l'enregistrement sans BOM se fera en sélectionnant le jeu «UTF-8 Cookie»".

D'avance merci,
Antoine
Modifié par Bouda (20 Mar 2005 - 16:25)

Je pense que le Salon "Encodage et Internationalisation" me paraît bien plus approprié
Je déplace...

Salut,

Je poursuis le problème : j'ai essayé (pour coder en utf-8) pas moins de 5 éditeurs.
Scite fait partie de ceux qui, apparemment, savent gérer l'utf-8, et semble intéressant en raison de sa fonction de "collapsing" (repliage) des zones de codes.
Malheureusement, il faut lui indiquer à chaque fois le codage, et ça c'est pénible.

J'ajoute donc :
1) N'existe-t-il pas un éditeur qui soit capable de détecter l'encodage d'un fichier correctement ?
2) Différence entre utf-8 et utf-8 cookie ?

Quand l'éditeur lit le fichier, il n'a aucun moyen pour savoir si il a préalablement été enregistré en UTF8 ou en ISO8859-1. Pour résoudre cette ambiguité, il prend par défaut le codage de l'OS ou de sa configuration (le tien doit être ISO8859-1 d'après ce que tu dis). Si tu ouvres ton fichier UTF8 il va falloir le déclarer explicitement à chaque ouverture.

Pour gérer ce problème, et d'autres problèmes qui apparaissent avec l'UTF16 (big ou little endian), Unicode a prévu qu'on puisse inscrire un "BOOM" en début de fichier. Ce sont quelques caractères non imprimables qui permette de déclarer le type de codage unicode et la variante utilisée.

Si ton scite lit ce BOOM en début de fichier il saura que c'est de l'UTF8, donc il saura qu'il doit passer ne UTF8 sans que tu lui précises et même si le mode par défaut est ISO8859-1

L'écriture de ce BOOM est facultative. Elle amène certains problèmes qui font que sur les systèmes Unix on déconseille son utilisation. Par défaut Scite ne le met donc pas quand tu écris en UTF8.

Si tu lui sélectionne "UTF8 cookie" à l'enregistrement il va laisser une trace dans le fichier, le BOOM. A la relecture il saura donc reconnaitre le bon codage.

Rajout : Dans la plupart des éditeurs tu dois pouvoir spécifier le codage "par défaut". Si tu codes uniquement en UTF8 il suffit de changer ce codage par défaut et de ne plus t'en préoccuper.

Euh les tests que j'ai fait ne semblent pas compatibles avec ce que tu dis, Ganf.
En utilisant Unired, j'ai pu constater qu'il détectait très bien tout seul le type de fichier : je lui passe un fichier UTF-8 avec BOM, il le voit comme tel, UTF-8 sans BOM ça marche aussi, et ISO-8859-1 ça marche encore.
Précision : je dis qu'il "le voit comme tel" car ce sont les infos affichés dans le menu fichier, item propriétés.

Bonsoir,

Ganf a écrit :
Si tu lui sélectionne "UTF8 cookie" à l'enregistrement il va laisser une trace dans le fichier, le BOOM. A la relecture il saura donc reconnaitre le bon codage.

Ah ? Dans une mail, Steve Frécinaux me disait justement le contraire..

Steve Frécinaux a écrit :
> J'aimerais, dans une premier temps, savoir ce que vous
> entendez par :
> "Attention, dans le cas de SciTE, l'enregistrement
> sans BOM se fera en sélectionnant le jeu «UTF-8 Cookie»"

Et bien c'est simple. Dans le sous-menu "Encoding" du menu
"File", Scite propose deux choix intitulés "UTF-8". Il y a
"UTF-8" «tout court» et "UTF-8 Cookie". Dans le premier cas, le
fichier sera enregistré avec une BOM (Byte Order Mark), et dans
le second cas, celle-ci sera omise. À savoir que cette BOM pose
de nombreux problèmes dans le cadre de l'internet, il faut donc
éviter son utilisation et choisir "UTF-8 Cookie" pour enregistrer
vos fichiers HTML ou PHP.

Ganf a écrit :
Rajout : Dans la plupart des éditeurs tu dois pouvoir spécifier le codage "par défaut". Si tu codes uniquement en UTF8 il suffit de changer ce codage par défaut et de ne plus t'en préoccuper.

J'ai malheureusement retourner le fichier de configuration de SciTE dans tous les sens, et là encore, Steve me donne la réponse :

Steve Frécinaux a écrit :
> Ensuite, comment (par quelle variable et quelle valeur) faire
> pour que le type d'encodage par defaut, sous SciTE, soit
> l'UTF-8 ou «UTF-8 Cookie» ?

Ce n'est à ma connaissance pas possible dans la version actuelle
de l'éditeur. Cepentant vous pouvez harceler Mat
<http://mat.virgule.info> pour qu'il propose son patch à l'équipe
de développement

Amicalement,
Steve

Modifié le 08 Feb 2005 - 23:52

Un truc que j'ai découvert depuis, c'est que si SciTE trouve coding: utf-8 dans les deux premières lignes du fichier, alors il passe automatiquement en mode cookie. La technique est alors de mettre un commentaire contenant cette ligne, au début du fichier.

En PHP ça donne :

<?php # coding: utf-8
...

et en XHTML :

<?xml version="1.0" encoding="utf-8"?><!-- coding: utf-8 -->
<!DOCTYPE ... >
...

Ahhh, parfait, merci Steve !

Edit : A préciser, pour que le hack soit pris en compte, il faut écrire utf-8 et non UTF-8.

Edit 2 : http://tw.apinc.org/weblog/2005/03/20/scite-et-utf-8
Modifié par Bouda (29 Dec 2005 - 13:03)

Un hack de plus dans nos merveilleux codes

Peut être que faire "pression" sur les dev de SciTE serait une meilleure solution, sinon changer d'éditeur (crimson editor par exemple) en attendant mieux de la part de SciTE par ailleurs un excellent éditeur.

Mouais... Je l'aime mon SciTE moi.

Alors si tu l'aimes, raison de plus pour pousser les dev de SciTE à faire mieux pour la prochaine version

Si un hack fait passer en UTF, ils doivent pas avoir grand chose à faire pour ajouter un menu qui fasse pareil

Le menu y est. Le problème est juste qu'il faut aller dans ce menu

Cherchant des infos sur autre chose, je suis tombé sur votre post, et voulant intervenir j'ai du m'inscrire ...
Car vous parliez de mon éditeur préféré SciTE, de l'utf8 et de la BOM ... (des sujets qui me tiennent à coeur

Donc il y a qques explications à donner ...

UTF8 est l'encodage du futur, permettant d'encoder tous les caractères de la planete, tout en offrant une certaine compatibilité avec beaucoup de progs/libs existantes (en effets, les carac ascii sont toujours sur 8bits, et seuls les spéciaux sont sur plus)

La BOM sont qques caractères "à la con"/magiques placés en début d'un fichier, pour dire à son intérpréteur que c'est de l'utf8 ... C'est qqchose qui nous vient du monde windows, et existe nulle par ailleurs ! (il faudrait d'ailleurs éviter ce genre de choses)

SciTE est justement le meilleur editeur du monde (ça c'est mon avis uniquement ), au niveau encodage ... car il respecte tout !
Il ouvre tout en 8bit, ce qui permet de prendre en compte tous les jeux de caractères (aussi bien utf8 que windows-1252, ascii etc ...), et surtout resauvegarde tout en flux de 8 bits, sans casser quoi que ce soit au fichier ... même si au niveau affichage ça peut paraître suprenant qqfois

Dire à scite qu'un fichier est en utf8 (via le menu ou le cookie) fera juste en sorte de modifier l'affichage dans lequel vous voyez le fichier : c'est absolument tout ! (si le fichier est effectivement en utf8, il vaut mieux l'afficher en utf8, c certain)

Ce "hack" comme certain l'appel, est certainement moins un hack que le coup du BOM (incompatible un peu partout ou après un transfer) ... et est très visuel également ...
De par sa nature, et cette compatibilité ascendante de l'utf8 avec l'ascii, il n'existe pas de moyen évident de detecter si un fichier est de l'utf8 ou autre (certains éditeurs de texte tente de deviner l'encoding du fichier à l'ouverture, mais c'est risqué aussi)... Ce pourquoi cette BOM (sous win), et ce commentaire sous scite ...
Moi je trouve le principe du commentaire excellent, simple et elegant ...

Il n'y a vraiment pas lieu d'embeter les devs de scite/scintilla avec ça ...
mettez ce cookie, c'est TRES visuel pour vous, c'est un identifiant pour scite, et en aucun cas ça peut foutre le bordel avec autre chose ...

On est dans une période de transition, on sera un jour tous en utf8 qu'on le veuille ou non

Personne n'a jamais dit que le contenu binaire du fichier était modifié lorsqu'on passe en mode 8 bits ou en mode UTF-8. SciTE n'est pas un convertisseur ! (pour convertir un fichier 8 bits en utf-8, il y a iconv)

La BOM n'a rien d'un hack. Ça existe partout, et pas uniquement sous Windows, contrairement à ce que tu peux penser. C'est défini dans la norme et ces quelques octets sont obligatoires dans d'autres formats unicodes comme, par exemple, UTF-16. Le fait qu'en utf-8 l'absence de BOM soit tolérée vient juste du fait qu'on a défini une valeur « par défaut » pour l'ordre des octets (Little Endian ou Big Endian). Le format sans BOM est apparu plus parce que ça arrangeait bien que par respect pour le standard. À la base, en UTF-8, y'a une BOM, point. Mais c'est sûr que c'est emm**** quand tu veux inclure un fichier dans un autre et que tu te retrouves avec 26 BOM disséminées dans ton fichier, ce qui est invalide, par contre.

Scite n'est sans doute pas le meilleur au niveau encodage, parce qu'en fait, à y réfléchir, je ne connais pas d'éditeur qui ne respecte pas le contenu binaire d'un fichier. En l'occurence, tous les éditeurs que je cite ici, mais aussi gedit, kwrite et tant d'autres, respectent à ma connaissance ce contenu binaire. À ceci près que unired, gedit et d'autres détectent automatiquement l'encodage d'un fichier utf-8, même sans BOM. (il suffit de vérifier que tous les octets du fichiers sont "valides utf-8" pour pouvoir postuler que le fichier est en utf-8. Ce n'est pas infaillible mais assez fiable.)

Ensuite, embêter les développeurs de SciTE ? ben dans la mesure où les informations reprises sont des infos passées sur la mailing-list des développeurs de SciTE, justement, et patches à l'appui, je ne vois pas comment on les embêterait.

Ah, aussi. "afficher" un fichier en UTF-8 ou en 8 bits, ce n'est pas que visuel, contrairement à ce que tu penses croire. Moi, quand j'ouvre un fichier, le but est de le modifier immédiatement. Si je dois faire un clic en plus à chaque fois, ça m'énerve, et donc, de ce fait, je change d'éditeur.

Et pour « UTF-8 vaincra », ça reste encore à prouver. Une distrib comme Debian fonctionne encore en iso-latin1, par exemple...

oula ... que de violence dans ton post ...

Pour la BOM dans les standards : ça m'étonnerait beaucoup, y a une rfc là dessus ?!? (je suis prêt à le croire, mais j'ai un gros doute)

Les techniques "je scane le fichier, s'il est valide utf8, j'en conclue que c utf8", evidemment que ça marche ... mais perso je trouve ça pas beau du tout, et suis pas certain que ça n'amene pas de problèmes ...

Il y a du choix dans les editeurs, qu'à celà ne tienne : change d'editeur ... si t'es pas prêt à mettre un commentaire/cookie dans ton fichier ... on a énormément de choix, profitons en !

Et apparemment tu mets en doute l'avenir de utf-8 comme encodage mondial définitif ?!? C'est donc que tu n'as pas l'air d'être très au courant ...
Redhat, depuis bien longtemps déjà, est passé au tout utf-8 (au moins la rhel3)... ma ubuntu ((hoary)debian) est également tout utf8 ... la mdk, c dans les tuyaux ... les autres vont suivre ... Le seul réel frein, c'est toutes les applis "mal codés" qui posent problèmes ... mais l'utf8, par rapport aux 16 et 32, offre justement une certaine compatibilité avec l'existant, pour une migration plus en douceur ..

Et si t'as un doute sur les avantages d'utf8, je te conseille cette lecture, très très instructive:
http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF

a écrit :
Pour la BOM dans les standards : ça m'étonnerait beaucoup, y a une rfc là dessus

http://www.unicode.org/faq/utf_bom.html ça te suffit comme URL ?

Oui le concept du BOM est standard (autant que l'UTF8 UTF16 et les autres).


Non ce n'est pas un hack, si l'utilité n'est pas là pour UTF8, c'est plus qu'utile quand tu manipules de l'UTF16. Ca sert à l'origine à repérer dans quel ordre tu met tes octets.

Non il ne vient pas du monde Windows, il n'a rien de plus propre à Windows qu'il n'a de propre à Unix. Win a pris comme convention de toujours l'insérer, ça ne veut pas dire que c'est plus proche de Win que d'Unix. Si c'est très peu utilisé sous Unix c'est plutot parce que les applis Unix sont ne sont pas si souvent que ça compatibles avec autre chose que l'ascii ou l'iso-8859-1. La plupart des petits softs systèmes ne connaissent pas Unicode et ne savent pas se servir du BOM. Du coup forcément on ne le met pas parce que sinon ça risque de dérapper sur les vieux softs.
Dites plutot qu'Unix est en retard et du coup ne peut pas se permettre d'utiliser le BOM alors que Windows arrive à l'imposer assez bien sur son parc, vous serez plus proches de la vérité.

Et ... se baser sur Debian pour dire si c'est le futur ou pas ... c'est un gros appeau à Troll tout de même

J'aime quand on me fait dire ce que je n'ai pas dit.

Premièrement, aucune violence dans mes propos précédents, juste une relativisation. J'aime bien les enthousiastes, mais à petite dose.

Pour la BOM, sans plonger dans les tréfonds d'unicode.org, la FAQ dit bien qu'un fichier UTF-8 peut contenir une BOM. Je dis pas que j'ai pas un peu mélangé avec UTF-16 pour le coup de l'endian, mais une BOM en UTF-8 est tout à fait légale, même si elle pose de nombreux problèmes dans le cadre de l'internet (en effet, certains parsers XML, par exemple, attendent <? comme premiers octets, et la BOM peut les faire planter. Erreur de conception sans doute)

Je n'ai ensuite rien dit contre le fait de mettre le petit commentaire. Pour mémoire, c'est moi qui ai fourni la solution, et ce commentaire, je le mets depuis belle lurette. J'ai peut-être parlé d'améliorer le bousain, de détecter automatiquement l'utf-8, mais... et alors ? Tous les éditeurs modernes le font, que je sache. Pas la peine d'être désagréable pour si peu.

Pour ce qui est de l'utf-8 comme encodage mondial définitif, ça reste à voir, comme je l'ai dit. D'abord, pourquoi un seul encodage ? Certes celui-ci propose une compatibilité avec ASCII (comme je l'ai expliqué, un jour, dans mon article), mais il se révèle assez compliqué à mettre en oeuvre, par rapport à d'autres encodages codés sur plusieurs octets, mais permettant d'avoir tous les caractères codés sur le même nombre d'octets, ce qui est un avantage considérable en termes de facilité et de rapidité de traitement. D'ailleurs, Java, pour ne citer que lui, utilise de l'UTF-16 en interne.

Ensuite, je disais juste que l'UTF-8 est encore loin d'être universel. Une grande distribution comme Debian est toujours en ISO-Latin1 par défaut, même si de nombreuses autres distributions (dont ma Gentoo et ma Hoary) sont en UTF-8.

Et encore, merci de ne pas me prendre pour un idiot, je fais peut-être parfois des erreurs mais en rêgle générale je sais ce que je dis...

PS. Je ne me basais pas sur Debian pour dire que l'UTF-8 c'est nul, je disais juste qu'à l'heure actuelle, UTF-8 comme langage universel, c'est pas vraiment un état de fait. J'aurais aussi pu dire que le support de l'UTF-8 dans PHP est foireux, par exemple... Fait, pas forcément troll.
Modifié par S.F. (04 Apr 2005 - 19:40)

Ganf a écrit :

http://www.unicode.org/faq/utf_bom.html ça te suffit comme URL ?

Oui le concept du BOM est standard (autant que l'UTF8 UTF16 et les autres).

quand je disais standard, je voulais dire obligatoire ... désolé !
Dans la faq d'unicode, il est aucunement dit qu'il faut mettre cette bom devant les utf8 ...

Ganf a écrit :

Non ce n'est pas un hack, si l'utilité n'est pas là pour UTF8, c'est plus qu'utile quand tu manipules de l'UTF16. Ca sert à l'origine à repérer dans quel ordre tu met tes octets.

ça, ok ... mais l'utf16 ?! à quoi bon ? (cf l'url plus bas)

Ganf a écrit :

Non il ne vient pas du monde Windows, il n'a rien de plus propre à Windows qu'il n'a de propre à Unix. Win a pris comme convention de toujours l'insérer, ça ne veut pas dire que c'est plus proche de Win que d'Unix. Si c'est très peu utilisé sous Unix c'est plutot parce que les applis Unix sont ne sont pas si souvent que ça compatibles avec autre chose que l'ascii ou l'iso-8859-1. La plupart des petits softs systèmes ne connaissent pas Unicode et ne savent pas se servir du BOM. Du coup forcément on ne le met pas parce que sinon ça risque de dérapper sur les vieux softs.
Dites plutot qu'Unix est en retard et du coup ne peut pas se permettre d'utiliser le BOM alors que Windows arrive à l'imposer assez bien sur son parc, vous serez plus proches de la vérité.

Je suis d'accord sur le fait que microsoft a une belle longueur d'avance, pour ce qui est du tout utf8 ...
Les distribs linux, on est en plein dedans ... et des problèmes surgissent d'un peu partout ...
Concernant les "petits soft" qui gravitent autour du noyau, je pense qu'ils connaissent l'unicode (la bom, c une autre histoire)

S.F a écrit :

D'ailleurs, Java, pour ne citer que lui, utilise de l'UTF-16 en interne.

l'url que je donnais (http://www.tbray.org/ongoing/When/200x/2003/04/26/UTF ), c'étais l'avis de Tim Bray (co inventeur du XML, et bosse chez sun), il doit quand même s'y connaître un peu sur le sujet de l'encodage et de l'unicode
Et il parle très bien des faux espoirs de l'utf-16 et des erreurs de java ...

et sauf erreur de ma part (faudrait que je relise l'article de tim bray), l'utf-16 n'arrive pas à encoder tous les caracs de la terre.

Si la debian stable est encore en iso, c'est une autre histoire à mon avis

S.F a écrit :

je disais juste qu'à l'heure actuelle, UTF-8 comme langage universel, c'est pas vraiment un état de fait

tout à fait, on est même dans la pire des phase : la transition ...

S.F a écrit :

Et encore, merci de ne pas me prendre pour un idiot,

je suis désolé, si tel étais le cas ... là n'était pas mon intention

mais j'aime pas qu'on dise du mal de SciTE
et j'aime pas trop les "trucs magiques" en informatique, qui tente de deviner l'encodage de ton fichier à ta place ... ça me plairait vraiment pas
ça peut peut être marcher pour différencier un utf8 d'un iso8559, mais pour le différencier des autres encodages : j'ai un doute ... et je pense que ça ne fera que repousser le problème à plus tard ...
Modifié par manatlan (07 Apr 2005 - 22:02)