UTF-8 ou ISO-8859-1 ?

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é :D

--
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