29Close31
Kevin KoflerOn the 2013-08-09 at 03:32pm
GoldenCrystal (./29) :
C'est pas du tout contraire au standard Unicode.

Si. Lis la spec. Le BOM n'est prévu que pour l'UTF-16 et l'UTF-32. Il n'a aucun sens en UTF-8 où il n'est pas question d'ordre des octets.
C'est juste déconseillé

"Déconseillé" dans le sens où c'est non-standard (cf. ci-dessus) et donc forcément les outils conformes au standard ne comprennent pas.
principalement à cause de tous les outils de merde obsolètes codés par des linuxiens, qui ne gèrent pas le BOM...

Au contraire, le BOM UTF-8 existe principalement à cause de tous les outils de merde obsolètes codés par des fenêtriens, qui utilisent un charset obsolète par défaut…
La seule justification valide contre le BOM c'est que contrairement à l'UTF-16, l'endianness ne joue pas dans l'UTF-8...

Effectivement, c'est bien pour ça que ce n'est pas prévu par le standard!
Mais ça sert quand même comme identificateur de flux,

Mais cet "identificateur de flux" n'est pas dans le standard, c'est une extension non-standardisée et crée donc beaucoup plus de problèmes qu'il ne résout.
et c'est bien plus pratique que de scanner un fichier texte à la recherche de caractères spéciaux.

Scanner les fichiers texte est un hack de compatibilité que certains outils comme Kate implémentent, mais qui ne devrait pas être nécessaire. Il suffit de partir du principe que tous les textes sont en UTF-8 en 2013! (Sinon, tu n'as qu'à utiliser iconv manuellement pour convertir tes fichiers obsolètes.)