Pierre Goiffon a écrit :
> Bruno Desthuilliers wrote:
>> Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
>> monumentale comme seule une certaine firme de Redmond sait en inventer.
>
> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
> fichier ainsi généré sera très facile à reconnaître par un processus
> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
> parait une bonne raison ?
Les éditeurs de textes peuvent reconnaître d'autre manière plus
explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce que
je lui reproche !

un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer
des entêtes personnalisés. La présence du BOM avant <?php fait que les
entêtes standards sont envoyés -> bug

explicit is better than implicit

Le 19/03/2008 16:31, Pierre Goiffon a écrit :
>
> UTF-8 peut être disproportionné pour
> certains contenus... et attention à l'augmentation de volume !
> (un jour je finirai la rédaction de
> http://pgoiffon.free.fr/info/i18n/we...ages_latin.php)

<cit.>
UTF-8 : codage à nombre d'octets variables (entre 1 et 6).
</cit.>

Noter que la plupart des caractères sont définis dans le « Basic
Multilingual Plane (BMP) » de 0x0000 à 0xFFFD, et sont donc encodés
en 3 octets au maximum, et surtout qu'il est maintenant établi que
l'on n'ira jamais au delà de 0x10FFFF, ce qui se code en 4 octets
au maximum.

Alors oui, UTF-8 peut être disproportionné pour l'écriture de certaines
langues dans lesquelles chaque caractère prend 3 octets en UTF-8 contre
seulement 2 dans des encodages spécifiques (tels que Shift-JIS pour le
japonais), mais ça n'ira jamais beaucoup plus loin.

Le 19/03/2008 19:24, BertrandB répondait à Pierre Goiffon :
>
>> [ Mettre un BOM sur de l'UTF-8 ]
>>
>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>> fichier ainsi généré sera très facile à reconnaître par un processus
>> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
>> parait une bonne raison ?

Sauf que le codage Unicode est vraiment *très* facile à détecter, et
surtout à « falsifier ». Je veux dire que les chances sont quasi-nulles
qu'un texte qui ne serait pas en UTF-8 soit pris pour de l'UTF-8. Il
n'y a absolument pas besoin d'un BOM UTF-8 pour cela.

> un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer
> des entêtes personnalisés. La présence du BOM avant <?php fait que les
> entêtes standards sont envoyés -> bug

[OUI]

BertrandB a formulé la demande :

>>> Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
>>> monumentale comme seule une certaine firme de Redmond sait en inventer.
>>
>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le fichier
>> ainsi généré sera très facile à reconnaître par un processus automatique :
>> s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me parait une bonne
>> raison ?
> Les éditeurs de textes peuvent reconnaître d'autre manière plus explicite
> l'encodage, alors que le BOM est *invisible*. Et c'est ce que je lui reproche
> !
>
> un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer des
> entêtes personnalisés. La présence du BOM avant <?php fait que les entêtes
> standards sont envoyés -> bug

Bug dans le processeur PHP ou dans le serveur Web ?

AMHA, le BOM est une très bonne chose, qui permet de connaître (par un
programme) l'encodage d'un fichier. Pourquoi le couple PHP/Apache n'en
tient pas compte ?

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Olivier Miakinen avait soumis l'idée :

>>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>>> fichier ainsi généré sera très facile à reconnaître par un processus
>>> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
>>> parait une bonne raison ?
>
> Sauf que le codage Unicode est vraiment *très* facile à détecter,

explique ? Lire les deux premiers octets du BOM c'est pas plus facile
que de lire tout le fichier et détecter d'éventuels caractères UTF-8,
UTF16 ou que sais-je ?

> et surtout à « falsifier ».

Quel est l'intérêt de falsifier l'encodage d'un fichier sinon pour
socratiser les diptères ?

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

BertrandB a écrit :
> Bruno Desthuilliers a écrit :
>
>>>
>>> va dire ça à ma cliente tiens ... petit plaisantin
>>
>> Non, je te le dis à toi. Mais bon, si tu préfères continuer à te
>> "palucher" ça à la mano, hein...
>
> Bon il faudra que je teste la prochaine fois que je me récupère encore
> un mélange d'UTF et de Latin1 avec un peu de CP-232.

Heu... Le tout dans le même fichier ??? Là, je déclare forfait (et AMHA,
tous les convertisseurs existant aussi).

Sergio a écrit :
> BertrandB a formulé la demande :
>
>>>> Mettre un BOM (nb : Byte Order Mark) sur de l'UTF-8 est une ânerie
>>>> monumentale comme seule une certaine firme de Redmond sait en inventer.
>>>
>>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>>> fichier ainsi généré sera très facile à reconnaître par un processus
>>> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne
>>> me parait une bonne raison ?
>> Les éditeurs de textes peuvent reconnaître d'autre manière plus
>> explicite l'encodage, alors que le BOM est *invisible*. Et c'est ce
>> que je lui reproche !
>>
>> un exemple d'arrachage de cheveu. Dans un fichier php on veut envoyer
>> des entêtes personnalisés. La présence du BOM avant <?php fait que les
>> entêtes standards sont envoyés -> bug
>
> Bug dans le processeur PHP ou dans le serveur Web ?
>
Bug dans le programme puisqu'il ne fait pas ce qui est attendu.

> AMHA, le BOM est une très bonne chose, qui permet de connaître (par un
> programme) l'encodage d'un fichier. Pourquoi le couple PHP/Apache n'en
> tient pas compte ?
>
Parce que ça n'a rien à voir : un langage et un serveur n'a pas à
interpréter les données qu'il traite il doit être neutre c'est le
programme qui doit le faire.
Et du moment qu'il est spécifié dans la documentation de PHP que les
caractères en dehors de <?php et ?> sont émis directement c'est de la
responsabilité du programmeur.
Les béquilles empêchent de courir le 100 mètres

autre exemple de bug comique avec le bom

dans un fichier de paramétrage on a

variable : valeur

dans le programme on cherche donc le mot variable en début de ligne ...
manque de pot le fichier de parmétrage a un bom .... on a un bug et
comme ce putain de bom ne s'affiche pas on se tire une balle dans la tête.

Et si réelment le BOM était un bien on aurait mis un N à la place du M
arf

Bonjour,

Le 20/03/2008 09:49, Sergio a écrit :
>
>>>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>>>> fichier ainsi généré sera très facile à reconnaître par un processus
>>>> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
>>>> parait une bonne raison ?
>>
>> Sauf que le codage Unicode est vraiment *très* facile à détecter,
>
> explique ? Lire les deux premiers octets du BOM c'est pas plus facile
> que de lire tout le fichier et détecter d'éventuels caractères UTF-8,
> UTF16 ou que sais-je ?

Tout d'abord, c'est à celui qui met un fichier à disposition de savoir
dans quel encodage il a été enregistré et de l'annoncer dans les entêtes
HTTP ad-hoc. Un navigateur ne devrait avoir besoin que de lire ces
entêtes et rien de plus (éventuellement un élément META dans le cas où
le fichier aurait été sauvé sur le disque local).

Par ailleurs, les trois (et non pas deux) octets du BOM en UTF-8 sont en
principe absents, auquel cas un navigateur capable de deviner l'encodage
malgré l'absence d'entêtes HTTP sera de toutes façons obligé de chercher
dans le contenu (contenu qu'il lit forcément en entier pour l'afficher).

>> et surtout à « falsifier ».
>
> Quel est l'intérêt de falsifier l'encodage d'un fichier sinon pour
> socratiser les diptères ?

Toutes mes excuses, je n'aurais pas dû employer ce terme (même entre
guillemets) car il s'agit ici d'un anglicisme pour « prouver faux ».

En clair : il est impossible qu'un texte écrit en Latin1 puisse être
confondu avec un texte en UTF-8 -- sauf à le faire exprès évidemment,
et même là ça doit être très difficile -- et donc, quand on a épuisé
toutes les ressources normales de détection du jeu de caractères
(entêtes HTTP puis élément META pour du HTML) cette technique est
largement assez bonne pour ce qu'on veut en faire.

Pour rappel, un caractère encodé en UTF-8 est de l'une des quatre formes
suivantes :
0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Tant qu'il n'y a que de l'ASCII 7 bits, le voir comme de l'UTF-8 est
équivalent à le voir comme de l'ISO-8859-X quel que soit X, ou comme
du CP437, CP850, Win1252, etc.

Dès qu'il y a un caractère 8 bits, alors pour que du Latin1 soit pris
pour de l'UTF-8 il faudrait que chaque séquence commence par une
majuscule accentuée (C0-DF) suivi par un caractère spécial ou un code
de commande (80-BF) ou bien par une minuscule accentuée (E0-F7) suivie
par deux ou trois caractères spéciaux ou codes de commande. Ceci est
impossible en français (et je parierais qu'il en irait de même dans les
autres langues) puisque la plupart du temps les majuscules ou minuscules
accentuées sont suivies d'un caractère ASCII.

Olivier Miakinen avait prétendu :
> Bonjour,
>
> Le 20/03/2008 09:49, Sergio a écrit :
>>
>>>>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>>>>> fichier ainsi généré sera très facile à reconnaître par un processus
>>>>> automatique : s'il y a BOM c'est que c'est un codage d'Unicode. Ca ne me
>>>>> parait une bonne raison ?
>>>
>>> Sauf que le codage Unicode est vraiment *très* facile à détecter,
>>
>> explique ? Lire les deux premiers octets du BOM c'est pas plus facile
>> que de lire tout le fichier et détecter d'éventuels caractères UTF-8,
>> UTF16 ou que sais-je ?
>
> Tout d'abord, c'est à celui qui met un fichier à disposition de savoir
> dans quel encodage il a été enregistré et de l'annoncer dans les entêtes
> HTTP ad-hoc. Un navigateur ne devrait avoir besoin que de lire ces
> entêtes et rien de plus (éventuellement un élément META dans le cas où
> le fichier aurait été sauvé sur le disque local).

Néanmoins, le BOM existant et étant généré par les éditeurs "à l'insu
de son plein gré", ça n'aurait pas cassé trois pattes à un canard pour,
dans Apache vérifier l'existence du BOM, l'interpréter, et le supprimer
avant de l'envoyer à l'interpréteur PHP !

Et ça aurait éviter des prises de tête à des milliers de développeurs
WEB, qui finalement se sont replié sur le Windows-1252 (pour les
francophones et langues annexes) qui ne pose pas de problème.

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

Sergio a écrit :
> Olivier Miakinen avait prétendu :
>> Bonjour,
>>
>> Le 20/03/2008 09:49, Sergio a écrit :
>>>
>>>>>> J'ai entendu plusieurs fois comme raison de procéder ainsi que le
>>>>>> fichier ainsi généré sera très facile à reconnaître par un
>>>>>> processus automatique : s'il y a BOM c'est que c'est un codage
>>>>>> d'Unicode. Ca ne me parait une bonne raison ?
>>>>
>>>> Sauf que le codage Unicode est vraiment *très* facile à détecter,
>>>
>>> explique ? Lire les deux premiers octets du BOM c'est pas plus facile
>>> que de lire tout le fichier et détecter d'éventuels caractères UTF-8,
>>> UTF16 ou que sais-je ?
>>
>> Tout d'abord, c'est à celui qui met un fichier à disposition de savoir
>> dans quel encodage il a été enregistré et de l'annoncer dans les entêtes
>> HTTP ad-hoc. Un navigateur ne devrait avoir besoin que de lire ces
>> entêtes et rien de plus (éventuellement un élément META dans le cas où
>> le fichier aurait été sauvé sur le disque local).
>
> Néanmoins, le BOM existant et étant généré par les éditeurs

par *certains* "éditeurs" (qui de fait ne méritent pas ce nom).

> "à l'insu de
> son plein gré", ça n'aurait pas cassé trois pattes à un canard pour,
> dans Apache vérifier l'existence du BOM, l'interpréter, et le supprimer
> avant de l'envoyer à l'interpréteur PHP !

Bin voyons.

> Et ça aurait éviter des prises de tête à des milliers de développeurs
> WEB, qui finalement se sont replié sur le Windows-1252 (pour les
> francophones et langues annexes) qui ne pose pas de problème.

Tu inverses totalement les responsabilités. Le BOM ne concerne
normalement que les encodage utf-x avec x > 8. Il ne *devrait pas*
exister pour un document encodé en utf-8. Ce n'est pas à Apache / PHP /
qui que ce soit de s'adapter aux fausses bonnes idées de quelques
"éditeurs" (ou éditeurs d'éidteurs !-), mais à ces "éditeurs" de
respecter les normes et conventions (et le simple bon sens).

Quant aux "milliers de développeurs web" dont tu parles, ils feraient
mieux d'apprendre leur boulot et de s'installer un éditeur digne de ce nom.

Après mure réflexion, Bruno Desthuilliers a écrit :

>> Et ça aurait éviter des prises de tête à des milliers de développeurs WEB,
>> qui finalement se sont replié sur le Windows-1252 (pour les francophones et
>> langues annexes) qui ne pose pas de problème.
>
> Tu inverses totalement les responsabilités. Le BOM ne concerne normalement
> que les encodage utf-x avec x > 8. Il ne *devrait pas* exister pour un
> document encodé en utf-8. Ce n'est pas à Apache / PHP / qui que ce soit de
> s'adapter aux fausses bonnes idées de quelques "éditeurs" (ou éditeurs
> d'éidteurs !-), mais à ces "éditeurs" de respecter les normes et conventions
> (et le simple bon sens).

> Quant aux "milliers de développeurs web" dont tu parles, ils feraient mieux
> d'apprendre leur boulot et de s'installer un éditeur digne de ce nom.

Toujours la même rengaine "c'est pas moi, c'est l'autre". C'est comme
ça que des solutions propriétaires (comme Flash) prennent le pas sur
les solutions standardisées et libres.

Je n'y mettrais pas ma main au feu, mais je parierais bien qu'avec le
couple IIS/ASP le BOM est traité correctement depuis longtemps...

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org

À (at) Fri, 21 Mar 2008 09:08:14 +0100,
Sergio <laposte@serge.delbono.net.invalid> écrivait (wrote):
> Néanmoins, le BOM existant et étant généré par les éditeurs "à l'insu
> de son plein gré", ça n'aurait pas cassé trois pattes à un canard
> pour, dans Apache vérifier l'existence du BOM, l'interpréter, et le
> supprimer avant de l'envoyer à l'interpréteur PHP !

Je crois que vous ne mesurez absolument pas l'impact de votre
"solution" en terme de performances... Apache cherche à être rapide.
Il n'a pas pour rôle de corriger les erreurs de conception de quelques
outils externes mal conçus et que le mauvais programmeur a bêtement
choisi.

> Et ça aurait éviter des prises de tête à des milliers de développeurs
> WEB, qui finalement se sont replié sur le Windows-1252 (pour les
> francophones et langues annexes) qui ne pose pas de problème.

Un développeur qui se replie sur une solution sans comprendre pourquoi
une autre ne marche pas, j'appelle cela un bidouilleur. On le fait
tous de temps à autre mais on ne vient pas se plaindre... ;-)

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Le 21/03/2008 09:08, Sergio a écrit :
>>
>> Tout d'abord, c'est à celui qui met un fichier à disposition de savoir
>> dans quel encodage il a été enregistré et de l'annoncer dans les entêtes
>> HTTP ad-hoc. Un navigateur ne devrait avoir besoin que de lire ces
>> entêtes et rien de plus (éventuellement un élément META dans le cas où
>> le fichier aurait été sauvé sur le disque local).
>
> Néanmoins, le BOM existant et étant généré par les éditeurs "à l'insu
> de son plein gré", ça n'aurait pas cassé trois pattes à un canard pour,
> dans Apache vérifier l'existence du BOM, l'interpréter, et le supprimer
> avant de l'envoyer à l'interpréteur PHP !

Non seulement une telle verrue dans Apache ne suffirait pas à contourner
complètement le bug, mais en outre ce serait une mauvaise idée car il ne
peut pas savoir si le fichier est censé être de l'UTF-8 avant de virer
ces trois octets !


1) Pourquoi ça ne marcherait pas :

<?php
include 'read_vars.php'; // contrôle et extrait les variables $_POST
if ($safe_content == 'png') {
header('Content-Type: image/png');
include 'make_png.php';
exit;
}
header('Content-Type: text/html; charset=utf-8');
// ... suite du code ...
?>

Un éventuel BOM dans read_vars.php ne peut pas être traité par Apache.


2) Pourquoi c'est une fausse bonne idée :

Un fichier binaire pourrait parfaitement commencer par les octets EF,
BB et BF, et ce serait un énorme bug de les enlever. D'ailleurs même
un fichier Latin1 a le droit de commencer par  quoique je t'accorde
que ce serait assez bizarre. Pour qu'Apache soit sûr qu'il s'agisse
bien d'un BOM UTF-8, il faudrait d'abord qu'il lise la totalité du
fichier pour s'assurer que c'est bien de l'UTF-8, chose dont tu dis
que même les navigateurs ne devraient pas avoir à le faire.


En outre, tu parles « des » éditeurs de texte. Il y en a vraiment
plusieurs qui ont ce bug sur Windows ? Et en dehors de Windows, tu
crois qu'il en existe ne serait-ce qu'un ?

Le 21/03/2008 11:47, je répondais à Sergio :
>
> 2) Pourquoi c'est une fausse bonne idée :
>
> Un fichier binaire pourrait parfaitement commencer par les octets EF,
> BB et BF, et ce serait un énorme bug de les enlever. D'ailleurs même
> un fichier Latin1 a le droit de commencer par  quoique je t'accorde
> que ce serait assez bizarre. Pour qu'Apache soit sûr qu'il s'agisse
> bien d'un BOM UTF-8, il faudrait d'abord qu'il lise la totalité du
> fichier pour s'assurer que c'est bien de l'UTF-8, chose dont tu dis
> que même les navigateurs ne devraient pas avoir à le faire.

Ah, je n'avais même pas pensé à l'argument imparable : le caractère ZERO
WIDTH NO-BREAK SPACE (U+FEFF), qui est surnommé Byte-Order Mark ou BOM,
est un caractère Unicode tout-à-fait valide, qui a parfaitement le droit
de se trouver dans un fichier en UTF-8. Il n'y a donc aucune raison de
le supprimer d'un fichier UTF-8 sous prétexte qu'en UTF-16 et UTF-32 on
lui a attribué une seconde signification.

Bruno Desthuilliers a écrit :
> Sergio a écrit :
>> Et ça aurait éviter des prises de tête à des milliers de développeurs
>> WEB, qui finalement se sont replié sur le Windows-1252 (pour les
>> francophones et langues annexes) qui ne pose pas de problème.
>
> Quant aux "milliers de développeurs web" dont tu parles, ils feraient
> mieux d'apprendre leur boulot et de s'installer un éditeur digne de ce nom.

Non, non surtout pas malheureux. Qu'ils continuent à utiliser des outils
pourris pour des résultats pourris. Ca me fait plein de réalisations à
rectifier que je peux facturer "presque" aux tarifs que je veux.

J'en ai au moins 10 par semaine des problèmes d'encodage à rectifier sur
des projets qui viennent de partout, donc moi je dit très bien, qu'ils
continuent à faire du 1252 parce que l'UTF8 c'est - wow - trop compliqué

--
laurent

Olivier Miakinen a écrit :
>
> En outre, tu parles « des » éditeurs de texte. Il y en a vraiment
> plusieurs qui ont ce bug sur Windows ? Et en dehors de Windows, tu
> crois qu'il en existe ne serait-ce qu'un ?

Si je comprends bien tout :
oui c'est très facile dans BBEdit de choisir le bom
il suffit d'une faute d'inattention.
(bon ... on peut aussi se l'enlever de la liste des choix)

--
sm

Le 21/03/2008 13:44, SAM a écrit :
>>
>> En outre, tu parles « des » éditeurs de texte. Il y en a vraiment
>> plusieurs qui ont ce bug sur Windows ? Et en dehors de Windows, tu
>> crois qu'il en existe ne serait-ce qu'un ?
>
> Si je comprends bien tout :
> oui c'est très facile dans BBEdit de choisir le bom
> il suffit d'une faute d'inattention.
> (bon ... on peut aussi se l'enlever de la liste des choix)

Merci !

Donc il existe au moins un éditeur en dehors du monde Windows qui permet
d'insérer un BOM en UTF-8, mais je comprends que ce n'est quand même pas
le mode par défaut.

Olivier Miakinen a écrit :
> Le 21/03/2008 13:44, SAM a écrit :
>> c'est très facile dans BBEdit de choisir le bom
>> il suffit d'une faute d'inattention.
>> (bon ... on peut aussi se l'enlever de la liste des choix)
>
> Merci !
>
> Donc il existe au moins un éditeur en dehors du monde Windows qui permet
> d'insérer un BOM en UTF-8, mais je comprends que ce n'est quand même pas
> le mode par défaut.

Je ne saurais dire ...
le mode par défaut il y a longtemps qu'il a été oublié ;-)
(par défaut il doit n'il y avoir aucun utf, par contre Mac Roman ... !)

C'est un éditeur à coloration syntaxique multi langages.
Il fourmille de possibilités, et y compris pour le mettre "à sa main".
J'ai donc la liste réduite des principaux charset utilisables.
(mais par inadvertance ou méconnaissance on peut bien avoir la liste
complète et choisir l'inapproprié - le soft convertit en direct dès
qu'on change le meta charset, on n'y voit que du feu)

C'est celui-là (en version lightée) qui fait le rendu mode-source dans
DreamWeaver (du moins dans les versions de DW que j'ai vues)

Il n'est pas francisé :-( (à ma connaissance)
ni même son mode d'emploi :-(
pourtant excellemment fait question reg expressions

--
sm

À (at) Fri, 21 Mar 2008 15:30:47 +0100,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):
> Donc il existe au moins un éditeur en dehors du monde Windows qui permet
> d'insérer un BOM en UTF-8, mais je comprends que ce n'est quand même pas
> le mode par défaut.

Heu... L'éditeur (certains le qualifie d'usine à gaz) que j'utilise
sur toutes mes plateformes (Unix, Linux, BSD, Windows, Mac OS, etc.)
et qui me sert en ce moment à poster cet article, sait aussi le faire
si je lui demande explicitement d'insérer la bonne série d'octets au
début du fichier (il faudrait que je vérifie s'il reconnaît ensuite
cela comme un BOM).

Par contre, il ne lui viendra jamais à l'idée de le faire tout seul
même si je lui indique que le fichier est en UTF-8. ;-)

--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Le 21/03/2008 16:27, Paul Gaborit a écrit :
>
> Heu... L'éditeur (certains le qualifie d'usine à gaz) que j'utilise
> sur toutes mes plateformes (Unix, Linux, BSD, Windows, Mac OS, etc.)
> et qui me sert en ce moment à poster cet article, sait aussi le faire
> si je lui demande explicitement d'insérer la bonne série d'octets au
> début du fichier (il faudrait que je vérifie s'il reconnaît ensuite
> cela comme un BOM).
>
> Par contre, il ne lui viendra jamais à l'idée de le faire tout seul
> même si je lui indique que le fichier est en UTF-8. ;-)

Bon, vous êtes bien sympas, Stéphane et toi, d'aller me chercher des
exemples d'éditeurs qui sauraient insérer un BOM si on le leur demandait
gentiment. Mais la question était de savoir quels sont les éditeurs qui
imposent un BOM et pour lesquels il est difficile voire impossible de
les en empêcher, au point de voir s'il ne faudrait pas introduire une
verrue dans d'autres logiciels afin de contourner ce bug ! Ce n'est
évidemment pas le cas de BBEdit, Emacs ou Vim.

À (at) Fri, 21 Mar 2008 16:48:44 +0100,
Olivier Miakinen <om+news@miakinen.net> écrivait (wrote):
> Bon, vous êtes bien sympas, Stéphane et toi, d'aller me chercher des
> exemples d'éditeurs qui sauraient insérer un BOM si on le leur demandait
> gentiment.

Désolé d'être taquin en ce vendredi...

> Mais la question était de savoir quels sont les éditeurs qui
> imposent un BOM et pour lesquels il est difficile voire impossible
> de les en empêcher, au point de voir s'il ne faudrait pas introduire
> une verrue dans d'autres logiciels afin de contourner ce bug ! Ce
> n'est évidemment pas le cas de BBEdit, Emacs ou Vim.

Nous sommes d'accord : un soi-disant éditeur qui impose un BOM (quel
que soit l'encodage pour lequel il l'impose) ne mérite pas
l'appellation 'éditeur'.

En fait, personnellement, je n'en connais pas. Il a été évoqué ici un
tel 'éditeur' sur Windows. Mais pourriez-vous être plus explicite et
donner son nom. Ça me permettra de donner des bonnes raisons de
l'éviter. Merci.


--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>

Le 21/03/2008 17:01, Paul Gaborit a écrit :
>
> Désolé d'être taquin en ce vendredi...

Ah, c'est vrai, c'est vendredi : le jour des trolls ! :-p

> En fait, personnellement, je n'en connais pas. Il a été évoqué ici un
> tel 'éditeur' sur Windows. Mais pourriez-vous être plus explicite et
> donner son nom. Ça me permettra de donner des bonnes raisons de
> l'éviter. Merci.

Je n'en étais pas sûr, mais je viens de vérifier que c'est le cas de
Notepad. J'ai créé un fichier utf8.txt ne contenant qu'un « é », or
voici ce que cela donne via od (cygwin) :

$ od -t x1 utf8.txt
0000000 ef bb bf c3 a9
0000005
$

Alors que les eleveurs et agriculteurs polluent toujours la Bretagne,
Olivier Miakinen nous narre ce qui suit en ce 21/03/2008 17:37 :

> Je n'en étais pas sûr, mais je viens de vérifier que c'est le cas de
> Notepad.

Notepad ++ n'impose pas un BOM par défaut : il permet le choix, entre
autres, d'encodage en UTF-8 ou UTF-8 *sans* BOM. Par défaut, il
s'installe sous encodage ANSI, si mes souvenirs sont bons.
C'est donc une question de paramétrage à effectuer lorsqu'on l'utilise.

Cordialement,
--
docanski

Portail et annuaire du nord-Bretagne : http://armorance.free.fr/
Guide des champignons d'Europe : http://mycorance.free.fr/
La vallée de la Rance maritime : http://valderance.free.fr/
Les côtes du nord de la Bretagne : http://docarmor.free.fr/

Olivier Miakinen <om+news@miakinen.net> wrote:

> Je n'en étais pas sûr, mais je viens de vérifier que c'est le cas de
> Notepad. J'ai créé un fichier utf8.txt ne contenant qu'un « é », or
> voici ce que cela donne via od (cygwin) :
>
> $ od -t x1 utf8.txt
> 0000000 ef bb bf c3 a9
> 0000005
> $

En effet c'est sans doute un bug de notepad - il faut changer
d'encodage, en prendre un au hasard, repasser ensuite en utf8 et
enregistrer et là ça marche.

--
A+

Romer