même si on a choisi comme préférence le jeu 8859-1.
Pire, on ouvre le fichier, on enregistre tout de suite en
changeant le jeu en 8859-1, ce qui transforme tous les accents
en entités html, mais si on ouvre de nouveau le même fichier,
c'est redevenu 1252 et les entités ont disparu...
En fait, si on regarde le code source d'une page avec le
navigateur, on ne trouve nulle part 1252, mais quand on regarde
le jeu, SM nous dit que c'est 1252. Il y a donc un gros problème
de ce côté.
Le problème ne semblait pas exister autrefois, comme je l'ai
constaté en regardant des fichiers modifiés il y a plus d'un an.
même si on a choisi comme préférence le jeu 8859-1.
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
Denis
Le Thu, 11 Jul 2013 09:39:27 -0400, Denis Beauregard
<denis.b-at-francogene.com.invalid@nospam.com.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Bonjour,
Je viens de constater un problème vraiment gênant dans les
dernières versions de Seamonkey.
J'ai édité de nombreuses pages pour remplacer les accents par
des entités HTML.
Quand on ouvre un fichier html contenant cette méta :
même si on a choisi comme préférence le jeu 8859-1.
Par contre, si on a tout transformé en entités html et qu'on
enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur
fait de nouveau disparaître les entités HTML.
même si on a choisi comme préférence le jeu 8859-1.
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
Denis
SAM
Le 11/07/13 15:42, Denis Beauregard a écrit :
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
Les navigateurs ont toujours un peu transformé le code html reçu (ils se rajoutent les balises manquantes, analysent le code et en déduisent le charset (avec +/- de bonheur), etc.)
enfin ... en supposant que le texteur responsable de l’édition des fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur (ce que TextEdit fait avec beaucoup de conviction, par exemple)
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Le 11/07/13 15:42, Denis Beauregard a écrit :
Par contre, si on a tout transformé en entités html et qu'on
enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur
fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
Les navigateurs ont toujours un peu transformé le code html reçu
(ils se rajoutent les balises manquantes, analysent le code et en
déduisent le charset (avec +/- de bonheur), etc.)
enfin ... en supposant que le texteur responsable de l’édition des
fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur
(ce que TextEdit fait avec beaucoup de conviction, par exemple)
Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
Les navigateurs ont toujours un peu transformé le code html reçu (ils se rajoutent les balises manquantes, analysent le code et en déduisent le charset (avec +/- de bonheur), etc.)
enfin ... en supposant que le texteur responsable de l’édition des fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur (ce que TextEdit fait avec beaucoup de conviction, par exemple)
Cordialement, -- Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8
Denis Beauregard
Le Thu, 11 Jul 2013 17:10:50 +0200, SAM écrivait dans fr.comp.infosystemes.www.auteurs:
Le 11/07/13 15:42, Denis Beauregard a écrit :
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
En local. Édition en local et le fichier tel que lu immédiatement après l'enregistrement. Mais cela ne change rien. En envoyant le fichier au serveur, les lignes META et les entités ou accents ne sont pas modifiés.
Les navigateurs ont toujours un peu transformé le code html reçu (ils se rajoutent les balises manquantes, analysent le code et en déduisent le charset (avec +/- de bonheur), etc.)
Mais Seamonkey est aussi un éditeur. Il a remplacé l'ancien Mozilla.
enfin ... en supposant que le texteur responsable de l’édition des fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur (ce que TextEdit fait avec beaucoup de conviction, par exemple)
C'est édité avec Seamonkey...
Denis
Le Thu, 11 Jul 2013 17:10:50 +0200, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:
Le 11/07/13 15:42, Denis Beauregard a écrit :
Par contre, si on a tout transformé en entités html et qu'on
enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur
fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
En local. Édition en local et le fichier tel que lu immédiatement
après l'enregistrement. Mais cela ne change rien. En envoyant le
fichier au serveur, les lignes META et les entités ou accents ne
sont pas modifiés.
Les navigateurs ont toujours un peu transformé le code html reçu
(ils se rajoutent les balises manquantes, analysent le code et en
déduisent le charset (avec +/- de bonheur), etc.)
Mais Seamonkey est aussi un éditeur. Il a remplacé l'ancien Mozilla.
enfin ... en supposant que le texteur responsable de l’édition des
fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur
(ce que TextEdit fait avec beaucoup de conviction, par exemple)
Le Thu, 11 Jul 2013 17:10:50 +0200, SAM écrivait dans fr.comp.infosystemes.www.auteurs:
Le 11/07/13 15:42, Denis Beauregard a écrit :
Par contre, si on a tout transformé en entités html et qu'on enlève cette méta, le navigateur détecte du UTF-8 et l'éditeur fait de nouveau disparaître les entités HTML.
C'est hallucinant...
bis repetita : "c'est en local ou sur serveur" ?
En local. Édition en local et le fichier tel que lu immédiatement après l'enregistrement. Mais cela ne change rien. En envoyant le fichier au serveur, les lignes META et les entités ou accents ne sont pas modifiés.
Les navigateurs ont toujours un peu transformé le code html reçu (ils se rajoutent les balises manquantes, analysent le code et en déduisent le charset (avec +/- de bonheur), etc.)
Mais Seamonkey est aussi un éditeur. Il a remplacé l'ancien Mozilla.
enfin ... en supposant que le texteur responsable de l’édition des fichiers html n'ait pas de lui-même édité en utf-8 à l'insu du programmeur (ce que TextEdit fait avec beaucoup de conviction, par exemple)
même si on a choisi comme préférence le jeu 8859-1.
Pire, on ouvre le fichier, on enregistre tout de suite en changeant le jeu en 8859-1, ce qui transforme tous les accents en entités html, mais si on ouvre de nouveau le même fichier, c'est redevenu 1252 et les entités ont disparu...
En fait, si on regarde le code source d'une page avec le navigateur, on ne trouve nulle part 1252, mais quand on regarde le jeu, SM nous dit que c'est 1252. Il y a donc un gros problème de ce côté.
Le problème ne semblait pas exister autrefois, comme je l'ai constaté en regardant des fichiers modifiés il y a plus d'un an.
Je ne sais pas si le problème existait auparavant mais je confirme que la version actuellement diffusée de seamonkey (v2.19) a ce comportement tout à fait bizarre (en tous cas sur mon linux).
Cela ne fait que renforcer ma conviction qu'un éditeur WYSIWYG n'a aucun sens pour des pages Web. Il vaut mieux utiliser un vrai éditeur de texte. C'est le seul moyen d'être sûr du résultat.
même si on a choisi comme préférence le jeu 8859-1.
Pire, on ouvre le fichier, on enregistre tout de suite en
changeant le jeu en 8859-1, ce qui transforme tous les accents
en entités html, mais si on ouvre de nouveau le même fichier,
c'est redevenu 1252 et les entités ont disparu...
En fait, si on regarde le code source d'une page avec le
navigateur, on ne trouve nulle part 1252, mais quand on regarde
le jeu, SM nous dit que c'est 1252. Il y a donc un gros problème
de ce côté.
Le problème ne semblait pas exister autrefois, comme je l'ai
constaté en regardant des fichiers modifiés il y a plus d'un an.
Je ne sais pas si le problème existait auparavant mais je confirme que
la version actuellement diffusée de seamonkey (v2.19) a ce comportement
tout à fait bizarre (en tous cas sur mon linux).
Cela ne fait que renforcer ma conviction qu'un éditeur WYSIWYG n'a aucun
sens pour des pages Web. Il vaut mieux utiliser un vrai éditeur de
texte. C'est le seul moyen d'être sûr du résultat.
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
même si on a choisi comme préférence le jeu 8859-1.
Pire, on ouvre le fichier, on enregistre tout de suite en changeant le jeu en 8859-1, ce qui transforme tous les accents en entités html, mais si on ouvre de nouveau le même fichier, c'est redevenu 1252 et les entités ont disparu...
En fait, si on regarde le code source d'une page avec le navigateur, on ne trouve nulle part 1252, mais quand on regarde le jeu, SM nous dit que c'est 1252. Il y a donc un gros problème de ce côté.
Le problème ne semblait pas exister autrefois, comme je l'ai constaté en regardant des fichiers modifiés il y a plus d'un an.
Je ne sais pas si le problème existait auparavant mais je confirme que la version actuellement diffusée de seamonkey (v2.19) a ce comportement tout à fait bizarre (en tous cas sur mon linux).
Cela ne fait que renforcer ma conviction qu'un éditeur WYSIWYG n'a aucun sens pour des pages Web. Il vaut mieux utiliser un vrai éditeur de texte. C'est le seul moyen d'être sûr du résultat.
