Bon...soir/jour à tous !

Voici un extrait de ce que donne mon site vu par Google...
"La galerie Nouveautés se remplit régulièrement de"



Ouaip. Et c'est un petit extrait tout minus. :nono:

C'est pas que ça me gène mais j'ai tout de même un petit pincement au coeur pour cette présentation de mon joujou d'un mois aujourd'hui. (C'est la fête ! 1 mois !! 1 Google Dance, 7 mises à jour de site, beaucoup plus de mises à jours de contenu et 630 visiteurs !)

Enfin tout ça pour demander de l'aide. Je suis passé par un logiciel de création de site pour lancer le bébé et je le modifie maintenant tout seul (ne rigolez pas...). L'écriture est du Arial 12 : un classique.

Que dois-je faire ? attendre la prochaine Google Dance et espérer plus de clémence de mon dieu Google ou trouver le codage HTML correspondant aux é è ' et autres réjouissances ?

Merci d'avance !!

Le problème ne se situe pas au niveau de google, mais de l'encoding utilisé. Vérifie que celui que tu utilises est adapté à ton contenu, en europe on utilise généralement : iso-8859-1 .

@++

[edit] tien carrément l'article d'openweb http://openweb.eu.org/articles/jeux_caracteres/ , ca devrait etre plus clair

Bonjour

Ta déclaration de charset n'est pas bonne.

Elle devrait être
et non

Mais dans ton cas, UTF-8 n'est pas nécessaire comme tu n'utilises que des caractères européens. Je te conseille donc

:up: Merci de la rapidité !!

Je vais voir ce que je peux faire d'après vos conseils !

Vivement la prochaine GD !


-----------
Je viens de remplacer le mauvais code ! Merci à vous deux !!

Aïe aïe aïe ça n'est pas tout à fait ça.

Il y a d'abord l'éditeur HTML utilisé par RaccOOn, localement ou en ligne.
Cette application "encode" le document dans un charset à déterminer, les plus fréquents étant :
- UTF-8
- ISO-8859-1 (ça ne semble pas être ça)
- Windows-1252 (apparemment, ce n'est pas non plus le cas)

Il y a ensuite le serveur qui héberge le site, et qui envoie au navigateur avec chaque page un en-tête HTTP spécifiant l'encodage de la page. Pour que la page soit correctement interprétée, cette information HTTP doit correspondre à l'encodage "réel" ci-dessus. Dans le cas de RaccOOn, son serveur indique au navigateur que les pages sont en UTF-8... ce qui semble être effectivement le cas.

Il y a ensuite la répétition de cette information d'encodage dans le corps du document, sous forme d'un éventuel prologue XML (il n'y en pas ici) et/ou d'une <meta http-equiv="content-type"... Mais en cas de contradiction, c'est l'en-tête HTTP qui l'emporte sur la meta et le prologue... Modifier seulement la meta ne changera donc rien si le serveur n'envoie pas le bon charset.

Donc, il faut:
- s'assurer du charset réellement utilisé par ton éditeur HTML
- modifier en conséquence le charset spécifié par le serveur, ou à l'inverse, utiliser un éditeur qui fasse de l'utf-8
- corriger la meta en conséquence.

Voir Spécifier l'encodage des caractères d'un document (X)HTML

Pour reprendre en résumant, j'ai deux possibilités alors :

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
OU
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">

D'après LaurentDenis, la deuxième solution ne convient pas ?
Je passe sur la première ? UTF-8 ?

L'éditeur avait intégré cette méta d'origine : <META HTTP-EQUIV="CHARSET" CONTENT="text/html; charset=utf-8">

Bonjour,

Je pensais simplement que META HTTP-EQUIV="CHARSET" n'est pas correct.
J'ai cherché des informations mais...
Je n'ai rien trouvé à ce sujet dans les spécifications pour http-equiv
J'ai suivi les liens proposés vers [RFC822] et [RFC2616]
Je suis arrivée sur les pages STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES et Hypertext Transfer Protocol -- HTTP/1.1

Euh... C'est grave docteur ? J'avoue n'avoir rien compris Monique.

Il faut faire plus que modifier la ligne de méta ?
Je viens de prendre celle proposée par Monique en UTF-8. Le serveur a l'air d'être en UTF-8 aussi d'après LaurentDenis... Je vais peut-être contacter Tiscali pour savoir si c'est le cas réellement ?

Monique, j'ai été un peu rapide peut-être : ta correction sur la syntaxe de la balise meta était tout à fait exacte. En revanche, l'encodage iso n'était pas le bon.

Après quelques vérifications :

L'encodage spécifié par le serveur est bel et bien utf-8. Au passage, il est facile à vérifier, par exemple :
- directement dans le navigateur (Opera le signale au survol de l'onglet)
- ou par l'intermédiaire du validateur HTML du W3C, qui signalait la contradiction entre l'en-tête HTTP (utf-8) et la meta ISO précédente. Il ne signale plus de problème depuis que c'est remis avec une meta utf-8.

De fait, la page semble bien être en utf-8 puisqu'elle a même une BOM, c'est à dire une petite signature dans les premiers caractères qui signale l'encodage. Cette signature est ajoutée par l'éditeur HTML. Elle est inutile dans un document Web, et pose souvent des problèmes (voir le lien ci-dessus). Peut-être est-ce ce qui fait tousser Google ?

Pour les valeurs possibles de http-equiv, ce n'est pas dans les spécifications HTML qu'il faut les chercher, mais bien dans la RFC HTTP, puisque "meta http-equiv" a pour but de fournir un équivalent à un en-tête HTTP. En l'occurrence, l'en-tête "charset" n'existe effectivement pas, il faut utiliser "Content-type".

Attention aussi à la BOM, car il semblerait qu'elle soit plus sujet à problèmes dans le cas d'internet (surtout avec les documents dynamique, qui, à force d'includes, se retrouvent rapidement avec une demi-douzaine de BOMs... ce qui est tout à fait incorrect.

Il est probable aussi que google ne lise pas les en-têtes http mais juste le http-equiv...

Ah ! J'espérais bien l'intervention de notre spécialiste maison de l'encodage



Ici, il y a une BOM unique pour l'instant, mais Opera, très susceptible sur ce point, ne manque pas de l'afficher.



Ce qui expliquerait les problèmes de RaccOOn. Maintenant, que la meta http-equiv correcte en utf-8 est rétablie, il n'y a plus qu'à attendre que Google se mette à jour. En espérant qu'il ne bugue pas sur la BOM

Bonjour,
je me permets de m'introduire dans cette discussion pour vous demander si vous savez si cela gêne d'avoir des pages html d'un même site en :
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
et d'autres en
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> ?

Qu'un site comprenne des pages dans des encodages différents n'est pas un problème pour le visiteur. Mais peut-être plus délicat à gérer pour les auteurs

:up: Merci à tous alors !

On peut donc dire qu'il y a des chances que ce soit réglé avec la bonne correction que Monique m'avait fournie dès le début en UTF-8 ? J'ai remplacé mes métas avec ça.

Reste à pister la prochaine GD pour voir si ça fonctionne !

Je vous remercie tous pour votre aide (même Nullette passk je me posais la même question ) et euh...

Merci !!

Dans WebRankInfo j'ai fait faire une analyse de densité d'un mot clé. Pas de chance, toujours les ennuis de caractère. Le problème n'est apparement pas résolu avec la correction de Monique pour la méta en UTF-8.

Au secours !!

-----------

J'ai passé la page index avec la méta en ISO-8859-1, toujours la même réaction sur WRI.
En plus IE me dit que la page est en UTF-8.

Alors le problème serait beaucoup plus embêtant ? BOM ?
Retour de la méta en UTF-8.

-----------

Je viens d'approfondir ma lecture du lien de LaurentDenis sur la BOM. Elle peut (ou doit ?) être enlevée. Je travaille avec Notepad sur mon HTML et apparement j'ai cru comprendre que celui-ci rajoutait une BOM inutile. La solution est-elle de passer par un vrai éditeur HTML ?

Mieux vaudrais en effet éliminer cette BOM et les problèmes qu'elle suscite, en utilisant un autre éditeur.

Yes !!!!

C'est ce que j'ai fait !! Passage de toutes mes pages html à la moulinette de WebExpert6 et en fait j'ai dû les mettre en ISO 8859-1 pour que ça passe nikel au test de WRI (en UTF-8 ça faisait les mêmes erreurs). Les accents disparaissent mais plus de mauvais caractères et les apostrophes sont affichées !



Merci à tous pour votre aide et longue vie à WebmasterHUB !!

Je pensais en fait au problème éventuel de lire des encodages différents non pas par les visiteurs, mais par les I.E., Netscape, Opera et tous les autres.
Sinon, j'ai abandonné tous les tests de WRI, de mots clés, nombre de liens et autres positionnements. J'arrive toujours en dernière ligne avec "des mauvaises notes", alors que mon site se positionne souvent en première place ou troisième avec Google !!! Je ne cherche plus à comprendre
Merci à RaccOOn. J'apprends plein de choses
(Je vais relire les posts pour savoir qu'est-ce qu'un BOM )
et pour conclure, je vais peut-être mettre toutes mes pages en UTF-8 pour me simplifier la vie

Non, cela ne pose pas de problème au navigateur tant que, pour chaque page, l'encodage est correctement indiqué, et notamment que l'éventuel en-tête HTTP est identique à l'encodage réel du document.

Merci Laurent Denis
La pluspart de mes pages sont agréées par le W3C (Au moins ça !!)