Encodage en utf-8

Bonjour à tous,

Je m'arrache les cheveux depuis un petit moment pour que mes fichiers soient bien encodés en utf-8.
Je travail sous TopstylePro qui ne propose pas dans ses options la possibilité de choisir l'encodage, il endode de base en iso-8859-1.
J'ai donc suivi les conseils d'un article d'OpenWeb http://openweb.eu.org/articles/jeux_caracteres/ en utilisant le logiciel Unired. Après paramétrage dans les options et en précisant bien en charset : utf-8 rien à faire j'ai toujours l'encodage iso-8859-1 d'après les validateurs http://www.validome.org et http://validator.w3.org/

J'ai aussi testé sous le bloc-notes mais pareil avec une nuance j'avais la chance d'avoir un beau "" dans mon code.

Si qq'un sait comment faire merci d'avance.

Alors avec un peu plus de lecture, cela proviendrait de l'entête HTTP qu'il faut préciser en php.

header('Content-Type: text/html; charset=utf-8');

Je me pose alors la question, cette méthode force-t-elle l'encodage des caractères en utf-8 ou est ce simplement l'unique méthode pour que le fichier soit bien en utf-8 ?

Ah ce que j'avais compris sur OpenWeb c'est l'éditeur de texte qui permet d'encoder la page au bon format.

korigan a écrit :
Ah ce que j'avais compris sur OpenWeb c'est l'éditeur de texte qui permet d'encoder la page au bon format.

C'est effectivement le cas. Tout le reste (en-tête HTTP ajoutée via PHP ou via la configuration du serveur, balise META avec information d'encodage), ce n'est que du déclaratif, pour renseigner les agents utilisateurs (navigateurs) : « mon document est dans tel encodage ».

Si ton éditeur de texte n'est pas fiable sur la question des encodages, change d'éditeur ! Je ne connais pas TopstylePro, mais a-t-il des fonctionnalités qui te le rendent irremplaçables ? Et ne peut-il pas être configuré, via les préférences ?

Pour être sûr de l'encodage utilisé, il n'y a qu'une seule méthode fiable : ouvrir le fichier texte avec un éditeur héxadécimal, et vérifier comment sont encodés les caractères. Suivant l'encodage, un caractère non-ASCII comme la lettre « é » sera codé avec des valeurs différentes, sur un voire deux octets (un octet pour du iso-8859-1, du windows1552 ou du MacRoman ; deux octets pour de l'UTF-8).

mpop a écrit :
Si ton éditeur de texte n'est pas fiable sur la question des encodages, change d'éditeur !

Après verification Topstyle Pro ne gère pas utf-8 il est bien la cause du problème mais pourquoi les autres que j'ai testés n'encodent t-ils pas en utf-8 ?
J'ai testé sous UltraEdit, PsPad et Unired mais rien n'y fait.
J'ai fait des copié collé, est ce que ça peut y jouer ?

Si l'entête http n'est qu'une information destiné aux agents utilisateurs, est-elle obligatoire ? Le navigateur n'utilise donc pas la métadonnée pour définir le format d'encodage des caractères ?

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

Tu peux simplement ouvrir ton fichier avec notepad (sous windows) et sélectionner Fichier > enregistrer sous... et dans la liste déroulante, prendre UTF-8 à la place de ANSI
Ca marche très bien

Pour la validation, ça doit être dans tes balises meta, le validateur lit simplement ce que contient ton fichier.

korigan a écrit :
J'ai aussi testé sous le bloc-notes mais pareil avec une nuance j'avais la chance d'avoir un beau "" dans mon code.

J'ai déjà testé mais cela ne fonctionne pas et j'ai même des caractères qui sortent d'ou je ne sais ou.

Mais si le copié collé est en cause tout s'explique

korigan a écrit :
Si l'entête http n'est qu'une information destiné aux agents utilisateurs, est-elle obligatoire ? Le navigateur n'utilise donc pas la métadonnée pour définir le format d'encodage des caractères ?

<meta http-equiv="Content-type" content="text/html; charset=utf-8" />

Le mieux est de mettre les deux. La meta sera utilisée si l'entête HTTP de précise rien, ou s'il est absent. Mais c'est quand-même mieux de le transmettre par l'entête HTTP, comme ça ton navigateur saura cash l'encoding de la page.

Je dubite tout de même sur le copié collé, si à chaque fois que l'on fait un copié collé d'une application à une autre cela change l'encodage du fichier je pense que plus d'une page aurait des problèmes d'encodage.

J'ai recréé une page avec un simple <p>bonne journée</p> dans mon body.

Sous Unired avec les options sur utf-8 sans copié collé en ne spécifiant que la metadonnée d'encodage de caractère :

Sans entête http

page web : bonne journée
validateur : Ce document est valide XHTML 1.0 Strict
Jeu de caractères utilisé : iso-8859-1
l'encodage de l'entête HTTP (iso-8859-1) diffère de celui (utf-8) figurant dans les données Meta.

Avec l'entête http en utf-8

page web : bonne journée
validateur : Ce document est valide XHTML 1.0 Strict
Jeu de caractères utilisé: utf-8

Sous Topstyle Pro qui ne gère pas l'utf-8 :

Sans entête http

page web : bonne journée
validateur : Ce document est valide XHTML 1.0 Strict
Jeu de caractères utilisé : iso-8859-1

Avec l'entête http en utf-8

page web : bonne journ?e
validateur : Ce document est invalide XHTML 1.0 Strict
Jeu de caractères utilisé : utf-8

Donc je change d'éditeur et il est donc indispensable d'utiliser l'entête http car même si le fichier est codé en utf-8 il ne le voit pas et le met en iso-8859-1.
Modifié par korigan (21 Jun 2006 - 18:11)

Je me cherche donc un nouvel éditeur de code je test UltraEdit mais petit problème, UltraEdit gère mal l'utf-8 puisque qu'il ne sait pas créer une page en utf-8 sans BOM. (BOM pose apparement des problèmes avec PHP)

J'ai testé une page en utf-8 avec BOM j'ai des caractères bizarre au début du code "" et avec le logiciel UniRed qui permet l'enregistrement sans le BOM j'obtient une page en utf-8 valide qui fonctionne.

Je me rend compte que d'utiliser de l'utf-8 est un vrai parcours du combatant, et que finalement peu d'outil sont développer pour.

Je pense que je vais rester en iso cela pose beaucoup moins de problème et ca m'évitera de racheter un logiciel pour rien.

Je reste quand même déçu
Modifié par korigan (22 Jun 2006 - 11:00)

notepad fonctionne très bien

korigan a écrit :
Je me cherche donc un nouvel éditeur de code je test UltraEdit mais petit problème, UltraEdit gère mal l'utf-8 puisque qu'il ne sait pas créer une page en utf-8 sans BOM. (BOM pose apparement des problèmes avec PHP)

Même problème citer au dessus

korigan a écrit :
Je me rend compte que d'utiliser de l'utf-8 est un vrai parcours du combatant, et que finalement peu d'outil sont développer pour.

Tiens, moi tous ceux que j'utilise le gèrent parfaitement. Les seules fois où j'ai eu des difficultés, c'est en travaillant avec un logiciel sous Mac (ce con voulait m'utiliser du MacRoman par défaut…), ou avec les logiciels par défaut de Microsoft (il faut bien penser à enregistrer dans le bon format avec Notepad, par exemple).

Par contre sous Linux, pas de problème. J'utilise Bluefish qui m'affiche l'encodage actuellement utilisé pour le document, et qui me permet de changer, c'est assez royal.

Sous Windows, il y a tout de même un certain nombre de logiciels qui devraient gérer ça bien ! Je suis étonné de voir que des outils payants comme UltraEdit ne gèrent pas ça correctement, alors que tous les éditeurs de code libre le font sans problème. Par exemple Scite, Notepad2 ou Notepad++.

En tout cas, « parcours du combattant », ça m'étonne…


PS : c'est quoi BOM ?
Modifié par mpop (22 Jun 2006 - 19:43)

korigan a écrit :
mais pourquoi les autres que j'ai testés n'encodent t-ils pas en utf-8 ?
J'ai testé sous UltraEdit, PsPad et Unired mais rien n'y fait.

J'utilise en ce moment PSPad et je ne rencontre aucun problème en utf-8
Modifié par Alan (22 Jun 2006 - 20:03)

Alan a écrit :


J'utilise en ce moment PSPad et je ne rencontre aucun problème en utf-8

Idem, il faut le configurer au départ dans les options, puis il fonctionne bien en uft-8.

Méa coulpa, j'ai refait mes tests avec PSPad et du 1er coup ma page est en utf-8 sans problème.

mpop a écrit :
PS : c'est quoi BOM ?

A ce que j'ai compris, Il y a deux variante de utf-8, avec et sans BOM (Byte Order Mark).
Le BOM est une informations au début du fichier qui permet de dire que le fichier est en utf-8.

plus d'info sur OpenWeb BOM (fr) et sur Wikipedia BOM (en)



Merci à tous pour vos réponses.

J'ai une autre question sur le même sujet.

Pourquoi la meta qui identifie l'encodage de la page n'est telle pas appelée avant le title ?
Bien souvent on la retouve juste après.
Si dans notre title on utilise des cararctères spéciaux et qu'on ne previent pas par une entête http l'encodage des caractères (se qui est bien souvent le cas) ils ne pourront être lu.

EDIT : Je remarque à l'instant que sur le forum la balise title est la dernière du head.
Modifié par korigan (24 Jun 2006 - 16:50)

korigan a écrit :
Si dans notre title on utilise des cararctères spéciaux et qu'on ne previent pas par une entête http l'encodage des caractères (se qui est bien souvent le cas) ils ne pourront être lu.

Ils sont lus techniquement (le navigateur met les valeurs en mémoire). Ensuite le navigateur décide de l'encodage à utiliser grâce à l'indication. Puis il traite les valeurs en mémoire en fonction de l'encodage trouvé.

Enfin je dis ça, ça n'a peut-être absolument rien à voir avec le fonctionnement réel du navigateur (différent avec chaque navigateur, de plus), mais en gros c'est pour souligner que les navigateurs ne font pas tout linéairement et en un seul passage !