Le 10 juillet 2012 20:26, Vincent Pottier <[email protected]> a écrit : > http://www.blueb.fr/_osm/admin.dat > encodage : ? pas d'indication dans les headers > As-tu enregistré ton fichier en UTF-8 no bom ?
Le BOM initial ne pose plus de problème depuis longtemps (même s'il n'est pas recommandé, uniquement à cause de la compatibilité avec les anciennes applications, le trouver en tête d'un flux n'est plus générateur d'une erreur avec les outils actuels et à jour, le caractère est simplement ignoré, même dans les éditeurs de texte un peu à jour ; c'est un traitement de fallback largement recommandé depuis maintenant plusieurs années puisque le caractère en question U+FEFF ZWNJ n'est fortement désapprouvé pour autre chose que le codage d'un BOM, on peut même l'ignorer partout où on le trouve, même hors du début d'un flux, car il y a eu un autre caractère encodé dans l'UCS pour le rare rôle qu'il avait avant). Personnellement je mets des BOM partout même dans les fichiers codés en UTF-8. De toute façon je n'ai plus besoin des vieux logiciels qui n'ont pas été corrigé pour l'ignorer dans un flux UTF-8 et pas corrigé non plus pour reconnaître automatiquement (et de façon fiable) par défaut un flux UTF-8 au lieu d'un flux dans un codage local SBCS sur DBCS sur 7 ou 8 bits. Le cas où on n'a pas besoin d'un BOM est quand un flux UTF-8 est encapsulté dans un autre qui sert d'enveloppe : c'est le format de l'enveloppe qui spécifie le codage explicitement (ou par défaut maintenant dans tous les protocoles Internet développés depuis quelques années, quant l'IETF a pris cette décision salvatrice pour en finir avec le "mojibake" d'avant et qui devient de plus rare). _______________________________________________ dev-fr mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev-fr
