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 ?