Mes excuses, réponse précédente partie bien trop vite...

Bruno Desthuilliers wrote:
>> Donc pour un site qui n'utilisera que des langues européennes il vaut
>> mieux se contenter de l'ISO-8859-1 (ou 15).
>
> Pas mon avis. Le meilleur moyen que je connaisse à ce jour pour ne pas
> avoir de pb d'encodage est d'utiliser systématiquement utf8 à toutes les
> étapes de la chaine.

Je n'aime vraiment les solutions qui apparaissent idéales et que l'on
applique sans trop réfléchir "parce que ça marche" (jusqu'au jour ou...
ça ne marche plus)

UTF-8 ne peut pas toujours être utilisé ! Dans un site dynamique où le
contenu vient disons de loin, cela peut devenir délicat...

Pour les langues d'Europe de l'Ouest il y a UTF-8 certes, mais aussi ISO
Latin-9 (fortement décrié après sa création mais à ma connaissance
largement supporté aujourd'hui), Windows-1252 (Microsoft mais aussi
visiblement très bien supporté). 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)

Il reste le problème de la récupération de contenus dans des
formulaires... C'est là qu'un codage Unicode prend son intérêt, et vu le
support des navigateurs actuels, ce codage sera UTF-8.

Tout ça pour dire qu'un choix de codage doit être réfléchi et effectué
en prenant en considération nombre de paramètres.

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