Sunfox

Le journal de Sunny Ripert


ProblÄ~me d’encodage

Seul hic au déménagement, un problème d’encodage par endroits.

Edit

Le problème a été résolu en forçant l’envoi dans les headers du type d’encodage des caractères, à savoir ici l’utf-8. Il semblerait que le serveur ne voit pas par défaut l’utf-8.

Pas de problème, j’utilise donc tout simplement le PHP : <?php header('Content-Type: text/html; charset=utf-8'); ?>.

Edit 2

Un peu de recherche plus tard, il se trouve que je ne sert mon XHTML en content-type text/html alors qu’il devrait en tout état de cause être servi au format application/xhtml+xml. Malheureusement ce dernier content-type a du mal entre autres avec Google.

L’origine du problème que j’ai là se trouve dans la configuration Apache du serveur sur lequel je suis actuellement, qui a la fonction AddDefaultCharset par défaut sur quelque chose de différent de mon encodage à moi, ici le Western ISO-8859-1.

J’ai donc contourné ce problème en supprimant mon morceau de PHP et en ajoutant dans un .htaccess AddDefaultCharset none pour qu’aucun charset ne prenne le dessus sur celui spécifié dans le meta <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />. Et cela fonctionne bien.

Reste encore mon content-type mal servi, mais tout ça est une autre histoire…

Articles probablement reliés

6 Commentaires

  1. 1 docLegi :

    tu débarques, neg ;)

    Pour l’encodage : il y a plusieurs niveaux
    – en quoi le contenu est-il réellement encodé dans ta base ? En général, tu peux le choisir dans les options de ton CMS. Il faut savoir que ce que tu tapes dans un formulaire sera envoyé avec l’encodage défini par la page où il se trouve.
    – ensuite, l’encodage peut être spécifié dans les entêtes HTTP, dans le prologue xml et dans une meta balise (uniquement en HTML (text/html)). Tu peux en apprendre plus dans ce document.

    Pour le XHTML :
    Le XHTML peut être envoyé soit en text/html, soit en application/xhtml+xml. On peut se servir de l’astuce suivante : le navigateur envoie dans ses entêtes HTTP un champ Accept, qui est une liste de types MIME. Par exemple mon Mozilla envoie :
    Accept: text/xml,application/xml,
    application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,
    image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1

    On se base sur cette liste pour déterminer avec quel type on envoie le fichier, si le champ Accept contient application/xhtml+xml on l’envoie en xml, sinon on l’envoie en text/html. Ça permet de respecter les vieux navigateurs et IE, vu que ce boulet envoie uniquement */* comme Accept.

    À lire absolument :
    Le minimum absolu que tout développeur doit absolument, positivement savoir sur Unicode et les jeux de caractères
    Pas mal non plus :
    Openweb  : Introduction aux jeux de caractères (suivre également les liens à la fin)

    Voilà, j’espère que ça t’aidera (et que mon commentaire n’est pas rempli de fautes, il manque un bouton prévisualiser amha)

  2. 2 docLegi :

    et merde j’ai tout cassé :/

    et puis il est boulet à transformer les occurences de XML dans les types MIME :D

  3. 3 Sunny :

    en quoi le contenu est-il réellement encodé dans ta base ?

    En utf-8, comme le contenu statique des pages.

    ensuite, l’encodage peut être spécifié dans les entêtes HTTP, dans le prologue XML et dans une meta balise (uniquement en HTML (text/html))

    C’est exactement les etapes par lesquelles je suis passé :p. Le problème est résolu hein ;).

    Vérifier à chaque fois les Accept: est une bonne idée, notemment pour présenter du text/html à IE et monsieur Google.

    Mais tout compte fait je préfère présenter à tout le monde du xhtml en text/html dans les meta que de rajouter un morceau de PHP à chaque requète.

    Ça pose problème le meta text/html sur du xhtml tu penses ?

    PS:
    J’ai réparé le post ;). Pour les preview à commentaires je vais réfléchir à implanter ça :P. Et pour les acronymes automatiques ça soule mais c’est sympa quand-même :P.

  4. 4 docLegi :

    Il y a aucun problème à utiliser la balise pour du xhtml, à condition que tu le serves en tant que text/html, de préférence sans prologue xml, autrement dit, vraiment aucun problème !!

    Par contre, plutôt que de forcer ton serveur à ne rien envoyer comme charset, je rétablirais personnellement le code PHP, surtout si tu décides de servir de toute façon en tant que text/html.

  5. 5 Sunny :

    En fait j’ai fait mieux que ça, j’ai mis un AddDefaultCharset utf-8 en plus de la balise meta :)

  6. 6 Sunny :

    Les recommendations du w3c sur le XHTML™ 1.0 stipulent dans les Compatibility Guidelines du Document Object Model que l’on peut utiliser « text/xml, application/xml, or application/xhtml+xml » :)

Commenter


Vous pouvez avoir une jolie icône vous aussi en créant un gravatar.

Vous pouvez y saupoudrer de l'HTML5 avec les balises et suivantes : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>.


:D Sunny Ripert

est un développeur web vivant à Paris.

CV, me contacter


Textes et contenus sous licence Creative Commons.
Site crée par mes soins et propulsé par WordPress.