11
Et BOM ! Dans ta face.
Alors que j’aidais un peu Robix à refondre le site de locations à Tignes de sa belle maman (réécriture d’URL, i18n…), on est tombé sur un os. Un vrai, un dur. Un put…n d’espace apparaissait dans nos navigateurs (firefox windows et linux, ie8…). Ce n’était ni un margin, ni un padding… Et pile à des endroits où il y avait des inclusions en PHP, mais c’était pas systématique. Comment perdre deux heures de notre vie, qu’on ne rattrapera jamais plus !
Cela venait d’un caractère UTF8 appelé le BOM (Byte Order Mark – U+FEFF) qui est censé donné l’ordre de lecture des données. Sauf qu’en UTF8, il n’y a qu’un sens, donc ce BOM ne sert à rien. Du coup, je sais même pas pourquoi il existe. Ils se trouvent au tout début de fichier.
Si ce n’était que cela, ça irait. Mais voilà, PHP les envoie et les navigateurs les affichent ces cons de BOM. Cela pose donc deux problèmes : un possible envoi de header prématuré avec PHP (génant) et ce fameux espace à la noix dont on a mis 2h à trouver d’où il sortait.
Les symptômes :
- Erreur PHP « headers already sent » alors que vous avez apparemment rien envoyé au navigateur ;
- Vous avez l’encodage UTF8 de détecté : l’espace blanc à la c..n (si votre fond est blanc, sinon ça peut être un espace bleu…);
- Vous forcez l’encodage du navigateur en ISO-8859-1 :  apparait à la place de l’espace blanc ;
Pour résoudre ça, si vous avez l’option (idiote soit dit en passant) de pouvoir enregistrer en UTF8 avec ou sans BOM dans votre éditeur favori, vous choisirez la version sans BOM.
Sinon, vous sortez votre éditeur héxadécimal et la séquence à éradiquer est EFBBBF. En général il se trouve au tout début du fichier. Mais attention, ce caractère de 3 octets est vil et mesquin, avec des copiés-collés, il peut se multiplier et se retrouver pas qu’au début. (Sous VIM il apparait en tant que <FEFF> mais uniquement s’il n’est pas au début, s’il l’est, on le voit pas).
Il aura fallu que je rapatrie des fichiers PHP UTF8 de Windows pour voir arriver ce genre de merdouille. Robix, Linux, c’est pour quand ?
Je compatis. Je l’ai déjà eu celui la il y a quelques années dans le cadre d’un dev entre ordis sous win et sous linux
Merci de l’info, c’est intéressant.
Par contre, UTF8 BOM est obligatoire dans certains cas pour des sessions PHP, sinon tu auras droit à une erreur en début de page.
@keeg: Dans quels cas ?
Sachant qu’Apache le renvoie tel quel, s’il en rencontre un avant session_start(), ça provoque surtout un « headers already sent ».
Je vais difficilement pouvoir t’en dire plus, je suis pas un grand expert du domaine. J’ai eu (entre autres) ce problème sur un extranet pas plus tard qu’en fin de semaine dernière, résolu de cette manière (UTF8 BOM).
Tu seras peut-être plus à même que moi à répondre à ta propre question.
@keeg: Tu as mis en UTF8 avec BOM et ça a marché ?
C’était pas sous Windows didonc ?
Plus sérieusement, si la conf de PHP est en ISO, le BOM passe sans-doute mieux dans un cas précis. L’UTF8 vu comme iso ne pose pas de problème d’exécution (c’est rare les accents dans les variables, les fonctions, je sais même pas si ça se fait !)
Sans détails, c’est dur à voir. Vivement un monde full UTF8 (50% des sites pour l’instant) et sans BOM (du coup) !
Heureusement que t’étais un tonton du code pour trouver la source… J’aurais tourné un moment !