Je bricole un site pour un copain et après l'avoir vérifié sous FF 3.5
et Opera 10, vient le pénible moment de regarder ce qui se passe avec
IE.
Sous IE7 je rencontre un bug connu (mauvaise prise en compte du
background dans le <body>, mais je ne trouve plus comment le contourner.
Quand je rafraichis l'affichage de la page, tout rentre dans l'ordre.
Curieusement, je n'ai le problème ni avec IE5.5 ni avec IE6 (pour IE8,
je ne sais pas, je ne l'ai pas).
Le problème n'apparait que pour le <body>, tous les blocs inclus ayant
un comportement correct.
Dans ma CSS, j'ai :
html, body {
margin: 0;
padding: 0;
text-align: center; /* pour corriger le bug de centrage IE */
color: black;
background-color: #162856;
font-family: "Comic Sans MS", Verdana, Helvetica, sans-serif;
font-size: 1px;
position: relative;
}
La page d'accueil du site :
http://www.pagliaghju-di-cannetu.com/
dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen <om+ ecrivait (wrote) :
Le 02/02/2010 21:48, Eric Demeester a écrit : > J'ai pensé à un problème d'encodage du fichier inclus, mais il était > bien en utf-8 comme le reste du site.
C'était pourtant bien un problème d'encodage et tu as trouvé l'explication, un grand merci à toi.
En conclusion : trouve-toi donc un éditeur UTF-8 qui sauve les pages sans ces $#%¬ de saloperies de BOM qui foutent la merde alors que ça ne sert strictement à *rien* en UTF-8 !
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien souvent, le bug se situait entre la chaise et le clavier :)
Le problème venait effectivement de ces *%&§#$!! de BOM, auxquels je ne ne comprends pas grand-chose. J'ai sauvé les fichiers inclus et les pages html avec l'option « encoder en utf-8 (sans BOM) », et hop, le problème d'affichage a disparu, comme on peut le constater en consultant http://www.pagliaghju-di-cannetu.com/ avec IE7 ou IE8.
J'ai ensuite un peu creusé la question et trouvé : http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent un aux fichiers UTF-8. Cependant, [...] cette pratique n'est pas recommandée, car cela peut interférer [...] avec le source pour les langages de programmation qui ne le reconnaissent pas. Par exemple, [...] en PHP, si l'output buffering est désactivé, cela a pour effet subtil de faire que la page commence immédiatement à être envoyée au navigateur, et d'empêcher les custom headers d'être spécifiés par le script PHP. La représentation UTF-8 du BOM est la séquence d'octets EF BB BF, qui apparaît en codage ISO-8859-1 comme "" dans les éditeurs de textes et navigateurs mal préparés pour traiter l'UTF-8. Ils peuvent également échouer à appliquer la première règle d'une feuille CSS »
Échouer à appliquer la première règle d'une feuille CSS correspond pile-poil au problème que j'ai rencontré.
-- Eric
dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen
<om+news@miakinen.net> ecrivait (wrote) :
Le 02/02/2010 21:48, Eric Demeester a écrit :
> J'ai pensé à un problème d'encodage du fichier inclus, mais il était
> bien en utf-8 comme le reste du site.
C'était pourtant bien un problème d'encodage et tu as trouvé
l'explication, un grand merci à toi.
En conclusion : trouve-toi donc un éditeur UTF-8 qui sauve les pages
sans ces $#%¬ de saloperies de BOM qui foutent la merde alors que ça
ne sert strictement à *rien* en UTF-8 !
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien
souvent, le bug se situait entre la chaise et le clavier :)
Le problème venait effectivement de ces *%&§#$!! de BOM, auxquels je ne
ne comprends pas grand-chose. J'ai sauvé les fichiers inclus et les
pages html avec l'option « encoder en utf-8 (sans BOM) », et hop, le
problème d'affichage a disparu, comme on peut le constater en
consultant http://www.pagliaghju-di-cannetu.com/ avec IE7 ou IE8.
J'ai ensuite un peu creusé la question et trouvé :
http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent
un aux fichiers UTF-8. Cependant, [...] cette pratique n'est pas
recommandée, car cela peut interférer [...] avec le source pour les
langages de programmation qui ne le reconnaissent pas. Par exemple,
[...] en PHP, si l'output buffering est désactivé, cela a pour effet
subtil de faire que la page commence immédiatement à être envoyée au
navigateur, et d'empêcher les custom headers d'être spécifiés par le
script PHP. La représentation UTF-8 du BOM est la séquence d'octets
EF BB BF, qui apparaît en codage ISO-8859-1 comme "" dans les
éditeurs de textes et navigateurs mal préparés pour traiter l'UTF-8.
Ils peuvent également échouer à appliquer la première règle d'une
feuille CSS »
Échouer à appliquer la première règle d'une feuille CSS correspond
pile-poil au problème que j'ai rencontré.
dans (in) fr.comp.infosystemes.www.auteurs, Olivier Miakinen <om+ ecrivait (wrote) :
Le 02/02/2010 21:48, Eric Demeester a écrit : > J'ai pensé à un problème d'encodage du fichier inclus, mais il était > bien en utf-8 comme le reste du site.
C'était pourtant bien un problème d'encodage et tu as trouvé l'explication, un grand merci à toi.
En conclusion : trouve-toi donc un éditeur UTF-8 qui sauve les pages sans ces $#%¬ de saloperies de BOM qui foutent la merde alors que ça ne sert strictement à *rien* en UTF-8 !
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien souvent, le bug se situait entre la chaise et le clavier :)
Le problème venait effectivement de ces *%&§#$!! de BOM, auxquels je ne ne comprends pas grand-chose. J'ai sauvé les fichiers inclus et les pages html avec l'option « encoder en utf-8 (sans BOM) », et hop, le problème d'affichage a disparu, comme on peut le constater en consultant http://www.pagliaghju-di-cannetu.com/ avec IE7 ou IE8.
J'ai ensuite un peu creusé la question et trouvé : http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent un aux fichiers UTF-8. Cependant, [...] cette pratique n'est pas recommandée, car cela peut interférer [...] avec le source pour les langages de programmation qui ne le reconnaissent pas. Par exemple, [...] en PHP, si l'output buffering est désactivé, cela a pour effet subtil de faire que la page commence immédiatement à être envoyée au navigateur, et d'empêcher les custom headers d'être spécifiés par le script PHP. La représentation UTF-8 du BOM est la séquence d'octets EF BB BF, qui apparaît en codage ISO-8859-1 comme "" dans les éditeurs de textes et navigateurs mal préparés pour traiter l'UTF-8. Ils peuvent également échouer à appliquer la première règle d'une feuille CSS »
Échouer à appliquer la première règle d'une feuille CSS correspond pile-poil au problème que j'ai rencontré.
-- Eric
Eric Demeester
dans (in) fr.comp.infosystemes.www.auteurs, SAM ecrivait (wrote) :
[CSS]
faudra m'esspliquer pourquoi le conteneur ou ses éléments contenus doivent se refarcir ce qui a déjà été déclaré au body comme : background, font-family, tex-align
Parce que j'ai fait ça à la va-vite, sans prendre en compte l'effet « cascade » des déclarations. J'ai honte.
et même esspliquer ces font-size: 1px;
Ça faisait partie de mes essais destinés à contourner un bug d'affichage d'IE que je pensais être à l'origine de mes malheurs.
[Extrait de code posté ici]
> J'ai passé ça au validateur html du w3c et j'ai été agoni d'injures.
On ne doit pas pratiquer le même validateur ? ! Le mien n'a seulement râlé que pour la balise </html> manquante (avec le copié-collé du code ci-haut)
Je parlais du code de la page indiquée, pas de l'extrait posté ici.
La page elle-même, parsée par le php au préalable, satisfait parfaitement le validateur que je fréquente. Où est le blème ?
C'est passé parce que j'avais corrigé entre-temps, je suppose ?
[...]
faut des méta description et keywords différents d'une page à l'autre sinon le référenceur croit que tu te moques de lui et passe
[...]
Corrige tes IDs et n'utilise pas de balise auto-fermante avec un DocType HTML Elles ne sont requises et obligatoires qu'en XHTML
Ce qu'il y a de surprenant quand on soumet une question ici, c'est qu'on se retrouve comme un insecte sur une table de dissection :)
Ça surprend, mais finalement c'est bien utile. Merci SAM, je vais tenir compte de tes pertinentes remarques.
-- Eric
dans (in) fr.comp.infosystemes.www.auteurs, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> ecrivait (wrote) :
[CSS]
faudra m'esspliquer pourquoi le conteneur ou ses éléments contenus
doivent se refarcir ce qui a déjà été déclaré au body comme :
background, font-family, tex-align
Parce que j'ai fait ça à la va-vite, sans prendre en compte l'effet
« cascade » des déclarations. J'ai honte.
et même esspliquer ces font-size: 1px;
Ça faisait partie de mes essais destinés à contourner un bug d'affichage
d'IE que je pensais être à l'origine de mes malheurs.
[Extrait de code posté ici]
> J'ai passé ça au validateur html du w3c et j'ai été agoni d'injures.
On ne doit pas pratiquer le même validateur ? !
Le mien n'a seulement râlé que pour la balise </html> manquante
(avec le copié-collé du code ci-haut)
Je parlais du code de la page indiquée, pas de l'extrait posté ici.
La page elle-même, parsée par le php au préalable, satisfait
parfaitement le validateur que je fréquente.
Où est le blème ?
C'est passé parce que j'avais corrigé entre-temps, je suppose ?
[...]
faut des méta description et keywords différents d'une page à l'autre
sinon le référenceur croit que tu te moques de lui et passe
[...]
Corrige tes IDs
et n'utilise pas de balise auto-fermante avec un DocType HTML
Elles ne sont requises et obligatoires qu'en XHTML
Ce qu'il y a de surprenant quand on soumet une question ici, c'est qu'on
se retrouve comme un insecte sur une table de dissection :)
Ça surprend, mais finalement c'est bien utile. Merci SAM, je vais tenir
compte de tes pertinentes remarques.
dans (in) fr.comp.infosystemes.www.auteurs, SAM ecrivait (wrote) :
[CSS]
faudra m'esspliquer pourquoi le conteneur ou ses éléments contenus doivent se refarcir ce qui a déjà été déclaré au body comme : background, font-family, tex-align
Parce que j'ai fait ça à la va-vite, sans prendre en compte l'effet « cascade » des déclarations. J'ai honte.
et même esspliquer ces font-size: 1px;
Ça faisait partie de mes essais destinés à contourner un bug d'affichage d'IE que je pensais être à l'origine de mes malheurs.
[Extrait de code posté ici]
> J'ai passé ça au validateur html du w3c et j'ai été agoni d'injures.
On ne doit pas pratiquer le même validateur ? ! Le mien n'a seulement râlé que pour la balise </html> manquante (avec le copié-collé du code ci-haut)
Je parlais du code de la page indiquée, pas de l'extrait posté ici.
La page elle-même, parsée par le php au préalable, satisfait parfaitement le validateur que je fréquente. Où est le blème ?
C'est passé parce que j'avais corrigé entre-temps, je suppose ?
[...]
faut des méta description et keywords différents d'une page à l'autre sinon le référenceur croit que tu te moques de lui et passe
[...]
Corrige tes IDs et n'utilise pas de balise auto-fermante avec un DocType HTML Elles ne sont requises et obligatoires qu'en XHTML
Ce qu'il y a de surprenant quand on soumet une question ici, c'est qu'on se retrouve comme un insecte sur une table de dissection :)
Ça surprend, mais finalement c'est bien utile. Merci SAM, je vais tenir compte de tes pertinentes remarques.
-- Eric
Eric Demeester
dans (in) fr.comp.infosystemes.www.auteurs, SAM ecrivait (wrote) :
Le 2/2/10 4:26 PM, Eric Demeester a écrit : > http://www.pagliaghju-di-cannetu.com/ est-ce vraiment bien nécessaire que les images 860/572px pesassent de 220ko à plus de 300ko
Certes non.
alors qu'à qualité 60% et de poids frisant les 70/80ko elle soient tout à fait supportables, acceptables ?
C'est aussi mon opinion mais le client (c'est un photographe professionnel qui ne connait rien à Internet) m'a envoyé des photos « spécialement optimisées par son agence pour une publication en ligne ». Je lui ai expliqué qu'elles pesaient trop lourd, proposé de les retoucher pour les alléger, il n'a pas compris l'intéret malgré mes explications répétées, alors de guerre lasse j'ai publié tel quel.
avec ma connexion ADSL, l'attente du slide-show est vraiment longuette ! (page: la bergerie)
Je n'aime pas l'idée des diaporama, ni celle de les sonoriser, mais ça aussi, il y tenait. J'ai au moins obtenu l'autorisation de mettre un contrôle sur la page permettant de couper le son, c'est toujours ça...
Tu n'as jamais eu de client qui, après avoir vu un site que tu juges absolument abominable, te dise « wahoo c'est génial, je veux la même chose ! » et ne veuille pas en démordre ?
Si la réponse est oui, tu as de la chance :)
Refroidi (ou échaudé, comme on veut), j'ai évité de voir d'autres pages ou de cliquer où que ce soit.
Je pense que beaucoup des personnes visitant son site feront comme toi ou moi : trop long, allons voir ailleurs.
l'histoire du bogggage IE m'apparait comme broutille en comparaison
Sur ce point, je ne suis pas d'accord parce que ça rend le site moche pour les utilisateurs d'IE7 et 8, mais ce problème a été réglé avec l'aide d'Olivier Miakinen.
-- Eric
dans (in) fr.comp.infosystemes.www.auteurs, SAM
<stephanemoriaux.NoAdmin@wanadoo.fr.invalid> ecrivait (wrote) :
Le 2/2/10 4:26 PM, Eric Demeester a écrit :
> http://www.pagliaghju-di-cannetu.com/
est-ce vraiment bien nécessaire que les images 860/572px
pesassent de 220ko à plus de 300ko
Certes non.
alors qu'à qualité 60% et de poids frisant les 70/80ko
elle soient tout à fait supportables, acceptables ?
C'est aussi mon opinion mais le client (c'est un photographe
professionnel qui ne connait rien à Internet) m'a envoyé des photos
« spécialement optimisées par son agence pour une publication en
ligne ». Je lui ai expliqué qu'elles pesaient trop lourd, proposé de les
retoucher pour les alléger, il n'a pas compris l'intéret malgré mes
explications répétées, alors de guerre lasse j'ai publié tel quel.
avec ma connexion ADSL,
l'attente du slide-show est vraiment longuette !
(page: la bergerie)
Je n'aime pas l'idée des diaporama, ni celle de les sonoriser, mais ça
aussi, il y tenait. J'ai au moins obtenu l'autorisation de mettre un
contrôle sur la page permettant de couper le son, c'est toujours ça...
Tu n'as jamais eu de client qui, après avoir vu un site que tu juges
absolument abominable, te dise « wahoo c'est génial, je veux la même
chose ! » et ne veuille pas en démordre ?
Si la réponse est oui, tu as de la chance :)
Refroidi (ou échaudé, comme on veut),
j'ai évité de voir d'autres pages ou de cliquer où que ce soit.
Je pense que beaucoup des personnes visitant son site feront comme toi
ou moi : trop long, allons voir ailleurs.
l'histoire du bogggage IE m'apparait comme broutille en comparaison
Sur ce point, je ne suis pas d'accord parce que ça rend le site moche
pour les utilisateurs d'IE7 et 8, mais ce problème a été réglé avec
l'aide d'Olivier Miakinen.
dans (in) fr.comp.infosystemes.www.auteurs, SAM ecrivait (wrote) :
Le 2/2/10 4:26 PM, Eric Demeester a écrit : > http://www.pagliaghju-di-cannetu.com/ est-ce vraiment bien nécessaire que les images 860/572px pesassent de 220ko à plus de 300ko
Certes non.
alors qu'à qualité 60% et de poids frisant les 70/80ko elle soient tout à fait supportables, acceptables ?
C'est aussi mon opinion mais le client (c'est un photographe professionnel qui ne connait rien à Internet) m'a envoyé des photos « spécialement optimisées par son agence pour une publication en ligne ». Je lui ai expliqué qu'elles pesaient trop lourd, proposé de les retoucher pour les alléger, il n'a pas compris l'intéret malgré mes explications répétées, alors de guerre lasse j'ai publié tel quel.
avec ma connexion ADSL, l'attente du slide-show est vraiment longuette ! (page: la bergerie)
Je n'aime pas l'idée des diaporama, ni celle de les sonoriser, mais ça aussi, il y tenait. J'ai au moins obtenu l'autorisation de mettre un contrôle sur la page permettant de couper le son, c'est toujours ça...
Tu n'as jamais eu de client qui, après avoir vu un site que tu juges absolument abominable, te dise « wahoo c'est génial, je veux la même chose ! » et ne veuille pas en démordre ?
Si la réponse est oui, tu as de la chance :)
Refroidi (ou échaudé, comme on veut), j'ai évité de voir d'autres pages ou de cliquer où que ce soit.
Je pense que beaucoup des personnes visitant son site feront comme toi ou moi : trop long, allons voir ailleurs.
l'histoire du bogggage IE m'apparait comme broutille en comparaison
Sur ce point, je ne suis pas d'accord parce que ça rend le site moche pour les utilisateurs d'IE7 et 8, mais ce problème a été réglé avec l'aide d'Olivier Miakinen.
-- Eric
romer
Eric Demeester <eric+ wrote:
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent un aux fichiers UTF-8.
J'utilise NotePad et PSPad depuis des lontemps et peut te dire qu'il ne les ajoute pas à moins qu'il existe un réglage dans les options du 1er qui les autorise ou pas. Si c'est réglé sur "autorisé" évidemment, le problème va se poser. Je ne l'ai pas ici pour vérifier. Le problème se pose par ex. avec BBEdit sur Mac car celui-ci propose dans les préférences "enregistement avec Bom" ou "enregistement sans Bom" . Si on ne sait pas ce que cela signifie, on a le pb !
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis une semaine de galère à en découvrir l'origine ! Les aides d'autres internautes étaient bien moins nombreuses que maintenant. -- A+
Romer
Eric Demeester <eric+usenet@galacsys.net> wrote:
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent
un aux fichiers UTF-8.
J'utilise NotePad et PSPad depuis des lontemps et peut te dire qu'il ne
les ajoute pas à moins qu'il existe un réglage dans les options du 1er
qui les autorise ou pas. Si c'est réglé sur "autorisé" évidemment, le
problème va se poser. Je ne l'ai pas ici pour vérifier.
Le problème se pose par ex. avec BBEdit sur Mac car celui-ci propose
dans les préférences "enregistement avec Bom" ou "enregistement sans
Bom" .
Si on ne sait pas ce que cela signifie, on a le pb !
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis
une semaine de galère à en découvrir l'origine ! Les aides d'autres
internautes étaient bien moins nombreuses que maintenant.
--
A+
Beaucoup de logiciels Windows (incluant Windows Notepad) en ajoutent un aux fichiers UTF-8.
J'utilise NotePad et PSPad depuis des lontemps et peut te dire qu'il ne les ajoute pas à moins qu'il existe un réglage dans les options du 1er qui les autorise ou pas. Si c'est réglé sur "autorisé" évidemment, le problème va se poser. Je ne l'ai pas ici pour vérifier. Le problème se pose par ex. avec BBEdit sur Mac car celui-ci propose dans les préférences "enregistement avec Bom" ou "enregistement sans Bom" . Si on ne sait pas ce que cela signifie, on a le pb !
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis une semaine de galère à en découvrir l'origine ! Les aides d'autres internautes étaient bien moins nombreuses que maintenant. -- A+
Romer
Eric Demeester
dans (in) fr.comp.infosystemes.www.auteurs, (Bernd) ecrivait (wrote) :
Bonsoir bernd,
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis une semaine de galère à en découvrir l'origine ! Les aides d'autres internautes étaient bien moins nombreuses que maintenant.
C'est dans ce genre de cas qu'on apprécie Usenet :)
-- Eric
dans (in) fr.comp.infosystemes.www.auteurs, romer@bernd.invalid (Bernd)
ecrivait (wrote) :
Bonsoir bernd,
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis
une semaine de galère à en découvrir l'origine ! Les aides d'autres
internautes étaient bien moins nombreuses que maintenant.
C'est dans ce genre de cas qu'on apprécie Usenet :)
dans (in) fr.comp.infosystemes.www.auteurs, (Bernd) ecrivait (wrote) :
Bonsoir bernd,
J'ai eu ce même problème voilà peut-être une dizaine d'année et ai mis une semaine de galère à en découvrir l'origine ! Les aides d'autres internautes étaient bien moins nombreuses que maintenant.
C'est dans ce genre de cas qu'on apprécie Usenet :)
-- Eric
pdorange
Eric Demeester <eric+ wrote:
> > Dans ma CSS, j'ai : > > font-family: "Comic Sans MS", [...] > Beuah. ;-)
Le 03/02/2010 18:15, Pierre-Alain Dorange a écrit :
<http://bancomicsans.com/home.html>
J'adore :)
Olivier Miakinen
Le 03/02/2010 15:53, Eric Demeester m'a répondu :
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien souvent, le bug se situait entre la chaise et le clavier :)
Tu es trop sévère envers toi-même, car c'était vraiment difficile à détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un « diff -b » entre tes deux pages m'a signalé comme différentes deux lignes qui me semblaient parfaitement identiques, caractère par caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les espaces de débuts de lignes sous vi j'ai vu une des lignes conserver encore des espaces au début. C'est seulement quand le même vi a fini par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au milieu du fichier.
J'ai ensuite un peu creusé la question et trouvé : http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets [...] »
Excellent texte.
Cordialement, -- Olivier Miakinen
Le 03/02/2010 15:53, Eric Demeester m'a répondu :
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien
souvent, le bug se situait entre la chaise et le clavier :)
Tu es trop sévère envers toi-même, car c'était vraiment difficile à
détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un
« diff -b » entre tes deux pages m'a signalé comme différentes deux
lignes qui me semblaient parfaitement identiques, caractère par
caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les
espaces de débuts de lignes sous vi j'ai vu une des lignes conserver
encore des espaces au début. C'est seulement quand le même vi a fini
par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne
pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au
milieu du fichier.
J'ai ensuite un peu creusé la question et trouvé :
http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets
[...] »
Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien souvent, le bug se situait entre la chaise et le clavier :)
Tu es trop sévère envers toi-même, car c'était vraiment difficile à détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un « diff -b » entre tes deux pages m'a signalé comme différentes deux lignes qui me semblaient parfaitement identiques, caractère par caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les espaces de débuts de lignes sous vi j'ai vu une des lignes conserver encore des espaces au début. C'est seulement quand le même vi a fini par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au milieu du fichier.
J'ai ensuite un peu creusé la question et trouvé : http://fr.wikipedia.org/wiki/Marque_d%27ordre_des_octets
« Problèmes liés à l'utilisation de la marque d'ordre des octets [...] »
Excellent texte.
Cordialement, -- Olivier Miakinen
Patrick Texier
[suite sur fr.comp.applications.editeurs-de-texte]
Le Wed, 03 Feb 2010 23:38:35 +0100, Olivier Miakinen a écrit :
> Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien > souvent, le bug se situait entre la chaise et le clavier :)
Il me semble qu'avec Notepad++, il détecte cette m.... de BOM et le coche dans le menu de choix de caractères.
Tu es trop sévère envers toi-même, car c'était vraiment difficile à détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un « diff -b » entre tes deux pages m'a signalé comme différentes deux lignes qui me semblaient parfaitement identiques, caractère par caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les espaces de débuts de lignes sous vi j'ai vu une des lignes conserver encore des espaces au début. C'est seulement quand le même vi a fini par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au milieu du fichier.
Ce n'est pas vi qui affiche <feff> mais Vim.
Le vrai vi version sourceforge <http://ex-vi.sourceforge.net/> travaille dans l'encodage du système et il me semble qu'il ne gère pas le BOM. Il suffit de virer les trois premiers caractères.
Avec Vim, la procédure est la suivante :
Passer l'éditeur en UTF-8 s'il n'y est pas en ajoutant dans .vimrc :
===== .vimrc ====== if has("multi_byte") set enc=utf-8 set fencs=ucs-bom,utf-8,latin1 " si le système n'est pas en UTF-8 mettre : set tenc=latin1 endif =================== Avec un fichier ouvert :
:set fenc? " affiche l'encodage du fichier. :set bomb? " teste la présence de cette saleté de BOM. :set nobomb " vire cette saleté de BOM.
Si on veut écrire dans un autre jeu de caractères, on modifie la valeur de fenc mais on ne touche jamais à enc.
Pour entrer des caractères unicodes, Vim est très pratique :
Par digraphes (oe pour ½, /- pour la croix latine...) : <CTRL-K><2 lettres> On a la liste des digraphes par :dig -- Patrick Texier
vim:syntax=mail:ai:ts=4:et:twr
[suite sur fr.comp.applications.editeurs-de-texte]
Le Wed, 03 Feb 2010 23:38:35 +0100, Olivier Miakinen a écrit :
> Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien
> souvent, le bug se situait entre la chaise et le clavier :)
Il me semble qu'avec Notepad++, il détecte cette m.... de BOM et le
coche dans le menu de choix de caractères.
Tu es trop sévère envers toi-même, car c'était vraiment difficile à
détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un
« diff -b » entre tes deux pages m'a signalé comme différentes deux
lignes qui me semblaient parfaitement identiques, caractère par
caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les
espaces de débuts de lignes sous vi j'ai vu une des lignes conserver
encore des espaces au début. C'est seulement quand le même vi a fini
par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne
pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au
milieu du fichier.
Ce n'est pas vi qui affiche <feff> mais Vim.
Le vrai vi version sourceforge <http://ex-vi.sourceforge.net/> travaille
dans l'encodage du système et il me semble qu'il ne gère pas le BOM. Il
suffit de virer les trois premiers caractères.
Avec Vim, la procédure est la suivante :
Passer l'éditeur en UTF-8 s'il n'y est pas en ajoutant dans .vimrc :
===== .vimrc ====== if has("multi_byte")
set enc=utf-8
set fencs=ucs-bom,utf-8,latin1
" si le système n'est pas en UTF-8 mettre :
set tenc=latin1
endif
===================
Avec un fichier ouvert :
:set fenc? " affiche l'encodage du fichier.
:set bomb? " teste la présence de cette saleté de BOM.
:set nobomb " vire cette saleté de BOM.
Si on veut écrire dans un autre jeu de caractères, on modifie la valeur
de fenc mais on ne touche jamais à enc.
Pour entrer des caractères unicodes, Vim est très pratique :
[suite sur fr.comp.applications.editeurs-de-texte]
Le Wed, 03 Feb 2010 23:38:35 +0100, Olivier Miakinen a écrit :
> Mon excellent éditeur (Notepad++) n'y était pour rien. Comme bien > souvent, le bug se situait entre la chaise et le clavier :)
Il me semble qu'avec Notepad++, il détecte cette m.... de BOM et le coche dans le menu de choix de caractères.
Tu es trop sévère envers toi-même, car c'était vraiment difficile à détecter. Moi-même je n'ai pas du tout pensé au BOM, même quand un « diff -b » entre tes deux pages m'a signalé comme différentes deux lignes qui me semblaient parfaitement identiques, caractère par caractère. Ça n'a pas plus tilté quand, essayant de retirer toutes les espaces de débuts de lignes sous vi j'ai vu une des lignes conserver encore des espaces au début. C'est seulement quand le même vi a fini par m'afficher « <feff> » quelque part (sans d'ailleurs que je comprenne pourquoi) que j'ai enfin compris qu'il y avait une saleté de BOM au milieu du fichier.
Ce n'est pas vi qui affiche <feff> mais Vim.
Le vrai vi version sourceforge <http://ex-vi.sourceforge.net/> travaille dans l'encodage du système et il me semble qu'il ne gère pas le BOM. Il suffit de virer les trois premiers caractères.
Avec Vim, la procédure est la suivante :
Passer l'éditeur en UTF-8 s'il n'y est pas en ajoutant dans .vimrc :
===== .vimrc ====== if has("multi_byte") set enc=utf-8 set fencs=ucs-bom,utf-8,latin1 " si le système n'est pas en UTF-8 mettre : set tenc=latin1 endif =================== Avec un fichier ouvert :
:set fenc? " affiche l'encodage du fichier. :set bomb? " teste la présence de cette saleté de BOM. :set nobomb " vire cette saleté de BOM.
Si on veut écrire dans un autre jeu de caractères, on modifie la valeur de fenc mais on ne touche jamais à enc.
Pour entrer des caractères unicodes, Vim est très pratique :
