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