UTF-8 avec ou sans BOM ?

La question peut sembler simpliste à première vue, mais… Elle l’est !

En fait, c’est un problème que l’on peut facilement rencontrer sans vraiment s’en apercevoir et sur lequel il est possible de rester des heures sans trouver de réponse.

Qu’est-ce que UTF-8 avec BOM ou sans ?

UTF-8, pour « UCS transformation format 8 bits », est un format de codage de caractères. L’avantage principal de ce format est qu’il permet de coder des milliers de caractères et donc d’être utilisable dans de nombreuses langues.

L’inconvénient principal est que tous les logiciels ne l’utilisent pas.

Mais comme tous les navigateurs comprennent l’UTF-8, il est de bon goût d’utiliser cet encodage pour vos pages HTML.

Le codage UTF-8 « standard », donc avec BOM (pour « Byte Order Mark ») rajoute un caractère en début de fichier. Un espace insécable de largeur nulle « zero-width no-break space ». Ce caractère est invisible pour l’utilisateur. En fait, ce caractère n’a pas d’intérêt en UTF-8. Il est utile en UTF-16 ou UTF-32.

Le codage sans BOM ne place pas ce caractère, tout simplement.

Quel est le problème alors ?

Étant donné qu’un caractère est ajouté en début de fichier, vous comprendrez peut-être que cela va poser problème pour certain fichiers PHP. En effet, si vous désirez faire une redirection dans le fichier PHP avec « header()« , vous risquez d’avoir une erreur car un contenu aura déjà été envoyé au navigateur avant même que votre redirection commence.

Prenons par exemple le code suivant :

<?php
//————- Test d’encodage
header(« Location: ma-page.php »);
?>

Si vous codez votre fichier en UTF-8, vous aurez une erreur. Si vous le codez en UTF-8 sans BOM, vous n’aurez pas d’erreur.

L’erreur que vous risquez d’obtenir est la suivante :

Warning: Cannot modify header information – headers already sent by (output started at C:\www\monsite\test.php:1) in C:\www\monsite\test.php on line 3

Vous risquez également d’obtenir des décalages dans votre page si vous incluez un fichier codé en UTF-8.

Les solutions

En fait, la première solution consiste tout simplement à coder vos fichiers en UTF-8 sans BOM si votre éditeur de texte préféré le permet. Sinon, changez d’éditeur

L’autre solution, si vous avez accès au php.ini de votre serveur, est de configurer « output_buffering » avec une valeur de 4096 (par exemple). Cela permet de mettre en buffer les pages avant de les envoyer au navigateur. Ce qui permet de corriger le problème de la redirection, mais pas des décalages dans vos pages. En même temps, vous accélérerez un peu la vitesse de création de pages.

Dernière solution, utilisez un autre codage que l’UTF-8. Pas forcément une bonne solution, mais si vous n’avez pas le choix…

Vous voilà prévenu maintenant. Si vous rencontrez un problème de redirection qui ne marche pas ou des décalages dans vos pages (avec des fichier inclus), et que vous n’arrivez vraiment pas à savoir pourquoi, vérifiez le codage de vos fichiers !



12 réponses à “UTF-8 avec ou sans BOM ?”

  1. pier dit :

    informations précises, complètes, sans « flafla… » et totalement utiles.

    Je garde votre site bien au chaud
    Merci!

  2. Bve dit :

    Merciiiiiiiiiiiiiiiiiiiiiiiiii pour ces infos.

    J’ai galéré pendant un certain temps avec ce « warning » et une fois le « warning » corrigé j’avais ce problème de caractères;
    Vive les gens qui donnent des solutions simples et claires

    Encore MERCI

  3. KrapOO_05 dit :

    Un seul regret :
    Que cette page ne soit pas la PREMIERE référencée dans Google quand on cherche sur cette fichue erreur « Warning: Cannot modify header information – headers already sent »

    Que de temps perdu alors que tout est là…

    Même le DVD de formation d’Elephorm (PHP/MySQL) conseille UTF-8 au lieu de UTF-8 (sans BOM)… du coup on se coltine dans plantages pour « rien », à part se former un peu plus par le biais des forums 😐

  4. Fab dit :

    La solution ne fonctionne pas chez moi.
    Le soucis auquel je suis confronté à l’heure actuelle rassemble tous les stigmates du BOM / no BOM. Suis en dev de site sous joomla 2.5 sur lequel j’ai un formulaire à partir duquel il faut que je génère un document pdf de fpdf. Donc les 2 entités (formulaire et fpdf) marchent bien indépendemment mais des lors que je mets mon output() pour fpdf dans traitement php du formulaire, j’obtiens un « FPDF error: Some data has already been output, can’t send PDF file »…
    J’ai essayé de modifier le php.ini de mon serveur (MAMP) mais cela ne change rien. Je travaille sous mac : pas de notepad++.

  5. Prélude dit :

    C’est très spécifique comme cas.
    Quoi qu’il en soit, on en revient, à priori, toujours au même problème : il y a au moins un caractères, visible ou non, qui est envoyé avant le début du Php.
    Soit c’est le Php qui a déjà envoyé un truc, soit le coup du BOM.
    Une erreur qui arrive souvent en Php : il faut éviter de fermer les balises Php à la fin des fichiers inclus. Cela évite de se retrouver avec un retour à la ligne juste après la balise de fermeture (et question sécurité, c’est mieux).

  6. Marco dit :

    un grand MERCI !

    votre article vient de mettre un terme à plusieurs heures de recherche sur un problème d’affichage incorrect d’une page web!

    Que de temps perdu pour un petit caractère invisible…

  7. Jean-marc dit :

    Bonjour, et merci.

    Je viens, moi aussi de comprendre ce qui se passait chez moi. J’ai donc « transformer » mes pages en utf-8 sans BOM. Reste un souci, toutes les lettres accentuées se sont « transformées » aussi à l’affichage.

    Y a-t-il une solution simple que de repasser sur toutes les lettres accentuées ? Merci.

    • Prélude dit :

      L’encodage a très certainement été perdu, il va être difficile de le récupérer.
      À moins que ce ne soit qu’un problème d’affichage dans le navigateur, auquel cas, il faut juste indiquer que l’encodage de la page est en UTF-8 et non en ISO-8859 ou autre.

  8. jean-marc dit :

    Mais oui bien sûr !!! c’est ça que j’ai oublié de faire. Modifier l’encodage des pages.

    Merci. Merci. Merci.

  9. Thierry dit :

    Que des compliments pour les explications. Précis simple et appliqué.
    Par contre le gris des caractères et un peu trop clair à mon goût.

  10. Prélude dit :

    Je viens de modifier ce gris un peu trop clair 😉

  11. Boris Paing dit :

    Merci, j’avais une marge verticale trop importante avant un titre parce que le navigateur passait en mode Quirks (ce qui arrive quand on a quoi que ce soit avant le <!DOCTYPE …). Merci encore 🙂

Leave a Reply

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Share This