Métadonnées hors de portées ??

Bonjour,

Je suis intégrateur HTML depuis un certains temps, et là suis assez stupéfais d'une découverte. Si le problème a déjà été évoqué, j'en suis désolé, mais je n'ai rien trouvé.

Voilà le phénomène (auquel j'ai été confronté plusieurs fois) que j'aimerais maintenant comprendre :

Je fais un site à partir d'un template php déclaré en utf-8 dans le meta. Jusque là pas de problème et rien d'exceptionnel. Sauf qu'à l'affichage des caractères spéciaux (accents etc.) => problème d'affichage. Evidemment, tous les tutos du net réfèrenet ce genre de problèmes aux différentes déclarations d'encodage dans les <meta _______ />.
Sauf que dans mon cas, rien à voir.
Pour "corriger" le problème, j'ai du avoir recour à une manipulation laborieuse mais efficace (exemple avec un fichier "index.php"):
Le fichier index.php affiche mal les caractères spéciaux. Donc sous DW, je crée un nouveau document dans lequel je copie tout le code de mon index.php. Ensuite je crée un 3eme document en utf-8 sous DW, je sélectionne tout le code (pour avoir l'entete etc.) et je le colle dans mon index.php. Ctrl+s pour sauvegarder et ctrl+w pour quitté. Et la, chose étrange, alors que je viens juste de sauvegarder, il me redemande si je veux sauvegarder mon document avant de quitter. Je répond "oui". Ensuite je réouvre mon document, et je recolle tout le code que j'avais stocké dans mon fichier temporaire. Je sauvegarde, et là c'est bon.

Conclusion : il est possible de se trouver avec 2 fichiers php (et même html j'imagine) totalement identique dans leur contenu, mais qui n'ont pas le même encodage. De plus, j'ai remarqué qu'outre leur aspect identique, les 2 fichiers n'avaient pas tout à fait le même poids, ce qui confirme bien que des métadonnées (ou sont-elles stockée ?)ont le dernier mot en ce qui concerne l'encodage.

Question : existe-il un logiciel, un éditeur etc. capable de traiter par lot ces fichiers afin de les convertir en masse à l'encodage souhaité ?

Bonjour,

Sauf mauvaise lecture de ma part, ton message montre que tu n'as pas compris la notion d'encodage.

Mettons que je crée un fichier au format texte brut, et que j'y enregistre un simple «é». J'enregistre ce fichier en ISO-8859-1, et j'en enregistre une deuxième version en UTF-8.

Voici ce que j'obtiens:


Les deux fichiers n'auront pas le même poids car ils n'ont pas le même contenu. En effet, «é» n'est pas le contenu réel de mes fichiers. Le contenu réel de mes fichiers, autrement dit les données enregistrées, ce sont des nombres (des 0 et des 1). Exprimés en hexadécimal, voici le contenu de ces deux fichiers (pour lesquels j'ai juste tapé «é» à chaque fois):
- test-latin1: E9 (soit un octet)
- test-utf8: C3A9 (soit deux octets)

En ISO-8859-1 (dit aussi Latin1), un «é» c'est E9, c'est à dire le nombre 233. En UTF-8, le même caractère est une série de deux octets, C3A9, c'est à dire les nombres 195 et 169.

Ce n'est donc pas une question de métadonnées, mais de données tout court: un même texte enregistré dans deux encodage différents, ce sont des données différentes.

wayer a écrit :
il est possible de se trouver avec 2 fichiers [...] totalement identique dans leur contenu, mais qui n'ont pas le même encodage

C'est une évidence. Rien n'interdit d'enregistrer un même texte dans plusieurs fichiers, avec des encodages différents. Le logiciel utilisé pour créer les fichiers va utiliser l'encodage demandé comme table de correspondance, pour savoir quel(s) nombre(s) il doit écrire pour chaque caractère du texte.

Quand tu réouvres tes fichiers, le logiciel va utiliser la table de correspondance (l'encodage) pour faire la conversion inverse. C'est pourquoi il est important de bien déclarer l'encodage d'un fichier, pour que le logiciel sache quelle table de correspondance utiliser lors de la lecture (c'est en tout cas indispensable pour les navigateurs web... les éditeurs de code fonctionnent généralement en détectant tout seul l'encodage utilisé, et le font plutôt bien... mais ils peuvent se tromper par moments).

Pour ta question finale, il existe des utilitaires en ligne de commande pour ce genre d'opération. Côté logiciels avec interface graphique, il y a Kaboom (sous Windows), par exemple.

Merci pour la réponse.
En fait ce que je voulais dire c'est qu'il semble qu'il existe des métadonnées (hors du contenu html/php) qui définissent l'encodage d'un fichier.
Pour faire très simple, j'ai crée 2 fichiers html ne comportant rien d'autre que le mot "dictée" (pas de <meta>, <head>, <body> etc. juste le mot "dictée").
L'un est capable d'afficher les accents, l'autre non.

Les fichiers sont ici.

En ce qui concerne mes connaissances en encodage, c'est effectivement une de mes lacunes, c'est pour ça que j'ai décidé d'y remédier.

MAJ : je n'y comprend plus rien, je viens de me rendre compte que le code source des fichiers était différent, alors qu'en les créeant j'ai marqué le mot de la même manière...

wayer a écrit :
En fait ce que je voulais dire c'est qu'il semble qu'il existe des métadonnées (hors du contenu html/php) qui définissent l'encodage d'un fichier.

Pas vraiment, non.

wayer a écrit :
j'ai crée 2 fichiers html ne comportant rien d'autre que le mot "dictée" (pas de <meta>, <head>, <body> etc. juste le mot "dictée").
L'un est capable d'afficher les accents, l'autre non.

Alors déjà ce ne sont pas les fichiers qui sont «capables» d'afficher les «accents». S'il y a un capable ou un incapable dans l'affaire, c'est le navigateur. Donc ça se passe comme ça:
1. le navigateur ouvre un fichier pour lequel il n'a aucune information sur l'encodage (pas de balise META, et pas d'information sur l'encodage dans les en-têtes HTTP);
2. si le navigateur est en mode «détection automatique de l'encodage», il essaye de s'y retrouver automatiquement, et il se peut que ça marche;
3. si le navigateur n'est pas en mode de détection automatique, il va utiliser l'encodage par défaut (que l'on peut modifier dans les préférences du navigateur);
4. si l'encodage par défaut est ISO-8859-1, le fichier en ISO-8859-1 s'affichera correctement, et pas l'autre (le navigateur va afficher le fichier UTF-8 comme si c'était de l'ISO-8859-1, c'est à dire qu'il va utiliser la mauvaise table de correspondance, donc afficher n'importe quoi); à l'inverse, si l'encodage par défaut est UTF-8, le fichier en UTF-8 sera bien affiché et l'autre non.

wayer a écrit :
MAJ : je n'y comprend plus rien, je viens de me rendre compte que le code source des fichiers était différent

En le visualisant dans le navigateur? Auquel cas c'est normal: si le navigateur a choisi le mauvais encodage pour afficher les caractères, et que donc le texte affiché ne correspond pas à ce qui est souhaité, ce problème impactera aussi bien l'affichage normal que l'affichage du code source.

À lire aussi: http://openweb.eu.org/articles/jeux_caracteres/

wayer a écrit :
j'ai marqué le mot de la même manière...

... Tu as marqué le mot de la même manière et il a été enregistré de manière différente. Les encodages servent à ça, enregistrer des données, et s'ils fonctionnaient de la même manière on n'aurait qu'un seul encodage...

wayer a écrit :

En fait ce que je voulais dire c'est qu'il semble qu'il existe des métadonnées (hors du contenu html/php) qui définissent l'encodage d'un fichier.

Par exemple BOM. Mais ce n'est pas vraiment utile (voir même à désactiver?), il vaut mieux enregistrer avec le bon encodage (dans dreamweaver -> édition -> préférences -> nouveau document -> codage par défaut - la tu peux aussi choisir d'inclure ou non la signature BOM) et spécifier au navigateur l'encodage à utiliser via une entête http et/ou la meta.

Merci à vous deux pour vos réponses.
Le problème c'est qu'aujourd'hui il est rare de faire un site de A à Z, inutile de réinventer la roue maintenant que les CMS sont devenu courrant. Avec certains fichiers php qui ne représentent généralement qu'une portion de contenu affiché, on se rend compte qu'ils comportent des métadonnées hors contenu html/php. Un exemple concret :
Sur le thème d'un CMS, le container.php affiche correctement les caractères, alors que le footer.php ne les affichent pas correctement.

bzh a écrit :


Par exemple BOM. Mais ce n'est pas vraiment utile (voir même à désactiver?), il vaut mieux enregistrer avec le bon encodage (dans dreamweaver -> édition -> préférences -> nouveau document -> codage par défaut - la tu peux aussi choisir d'inclure ou non la signature BOM) et spécifier au navigateur l'encodage à utiliser via une entête http et/ou la meta.

Merci pour l'info. Seulement maintenant comme je l'explique plus haut, il devient rare que je crée mes documents, j'utilise le plus souvent des .php de thèmes de CMS, dont certains m'oblige a recourir à la manipulation que j'xplique au début (créer un nouveau document sous DW comme tu dis, et recopier le code etc.) mais c'est relativement laborieux.

Bonjour,

perso j'aime PSPad pour sa gestion de l'encodage: tu ouvres le(s) document(s), tu choisis l'encodage, immédiatement il affiche que le document a été modifié, Ctrl-S et Ctrl-F4 et on passe au suivant ...

bzh a écrit :


Par exemple BOM. Mais ce n'est pas vraiment utile (voir même à désactiver?)

BOM = BOUM dans IE6.
IE6 détecte 'quelque chose' autre que du whitespace avant le Doctype et donc il passe en quirks mode et donc c'est mort ...

EDIT: quirks mode != quirksmode le blog de PPK
Modifié par Felipe (16 Mar 2009 - 12:28)

Donc pas de BOOUM, j'avais déjà eu des soucis avec cette fameuse signature.

wayer a écrit :
Merci à vous deux pour vos réponses.
Le problème c'est qu'aujourd'hui il est rare de faire un site de A à Z, inutile de réinventer la roue maintenant que les CMS sont devenu courrant. Avec certains fichiers php qui ne représentent généralement qu'une portion de contenu affiché, on se rend compte qu'ils comportent des métadonnées hors contenu html/php. Un exemple concret :
Sur le thème d'un CMS, le container.php affiche correctement les caractères, alors que le footer.php ne les affichent pas correctement.

Comme précisé par Florent, c'est l'encodage en lui même des fichiers qui joue. Si tu utilise des CMS à mon avis, les fichiers sont créés en UTF-8, du moins ça semble logique. Donc soit garder cet encodage, soit réenregistrer les fichiers qui génèrent l'affichage en ISO.

Pour convertir les fichiers :
- Un logiciel : Kaboom
- Sous linux en : ligne de commande
- La même chose que sous linux mais pour : windows (iconv)

Bref y a de quoi s'en sortir .