bonjour,

prenons le cas d'un site multilingue :

les pages en français sont en 8859-1 .

les pages en anglais doivent elles être en US-ASCII ou rester en 8859 ?
sachant que la cible visée est avant tout l'amérique du nord.

de même pour les pages en espagnol, ou on vise également l'amérique du nord et du sud.

Merci de vos réponses.

Le charset permet d'encoder les caractères.
Il doit être respecter pour que ces caractères soient correctement interprétés par les agent-utilisateurs (dont les spiders).

Le choix du charset pour les spiders n'a pas d'importance, il faut juste le respecter.
Maintenant le choix du charset va dépendre de tes besoins.
Il semblerait que tu aies un site ayant pour cible l'international, préfère l'UTF-8.

ok merci !

actuellement les pages anglais et espagnol sont en 8859-1, on passera donc en utf8 a la prochaine mise a jour...

Aucun problème, tout ces languages utilisent les caractères de l'iso-8859-1.

Dans la mesure où les langues en question sont largement couvertes par le 8859-1, quel serait l'intérêt pour lui de passer en UTF-8 ?
Ne risque t-il pas d'avoir des pages inutilement plus lourdes ?

j'ai lu quelque part sur le forum que l'utf8 était préféré en xhtml strict...

donc ça ne peut pas faire de mal?

remi : qu'entends tu par "plus lourd"?

merci de vos réponses.

Au contraire Aucun risque d'avoir à encoder des caractères étrangers (type &xxx; ), il suffira de les écrire tout simplement et c'est le navigateur qui se tapera le sale boulot (décoder les caractères sur je-ne-sais-combien de bits).
Quelques minuscules octets de gagnés, mais en tous cas aucun de trop.


Amalgame
L'UTF-8 est le langage d'XML. Donc en utilisant XHTML avec le type MIME d'XML (1% des cas à tout casser) on est forcé d'utiliser UTF-8. Sinon c'est libre choix.


Sinon, les moteurs savent très bien se débrouiller avec les différents encodages existants. Ce qui est logique puisqu'ils font partie d'une norme définie.

Salut Dudu, pourrais-tu me confirmer qu'en utilisant le charset UTF-8 il n'y a pas besoin d'encoder les caractères ?
Sur certaines de mes pages en UTF-8 j'encode les caractères accentués français et les caractères cyrilliques (les deux langues français + bulgare sont sur une même page).

Je me posais la question sur les pages éventuellement plus lourdes puisque l'UTF-8 est un charset sur 16 bits.

Mais tu as raison Dudu, c'est plus compact puisque (je viens d'essayer) les caractères normaux restent sur 1 octet, seuls les caractères étrangers sont sur 16 bits. Donc, on gagne un peu sur ces fameuses séquences &emachin...
J'ignorais cela...

Salut Nullette
Le cyrillique fait partie des caractères gérés par UTF-8, à en croire cette page sur le site d'Unicode: Tableaux de caractères.

Cela étant dit, il existe plusieurs moyens de déclarer l'encodage d'une page: par les en-têtes d'Apache, et par les métas HTML.
En cas de conflit, c'est Apache qui l'emporte. Apache est configuré par défaut pour envoyer de l'ISO 8859-1. Or je sais que ton site n'utilise aucun langage de programmation (type PHP) capable de jouer sur les en-têtes serveurs.
Si tu veux réellement envoyer de l'UTF-8, il te faudra passer par une directive .htaccess telle que celle-ci

D'accord.

Ce n'est pas tout à fait exact. En cas de conflit, c'est le logiciel client qui décide: la plupart des navigateurs donnent la priorité au choix de Apache, mais Googlebot donne la priorité au choix de la META. Il faut donc absolument éviter un conflit entre l'encodage spécifié par Apache et celui de la META.

Beaucoup de serveurs Apache envoient seulement l'en-tête de codage "text/html", ce qui laisse toute liberté pour l'encodage des pages.

Ce n'est pas nécessaire. J'ai testé la page d'accueil du site de Nullette avec mon petit outil http://www.annuaire-info.com/simulateur-google.html et, à la fin du rapport, on peut constater que son serveur ne spécifie pas le codage et qu'elle utilise une balise META qui spécifie "iso-8859-1". Si elle réenregistre toutes ces pages en UTF-8 et si elle change cette balise META en "UTF-8", l'encodage sera bien UTF-8 pour tout le monde.

Jean-Luc

J'ai des pages en UTF-8, d'autres (la majorité) en ISO 8859-1 - charset déclaré dans les balises meta.

Une page en UTF-8 en français et en bulgare

Mais ma question était de savoir si pour les accents en français je dois continuer à mettre &xxx
et le code pour le cyrillique.

Tu peux taper les mots français et bulgares "normalement". Aucun problème! D'ailleurs, dans la page que tu indiques le mot "appétit" est écrit avec é et non & eacute;. C'est pareil pour les caractères cyrilliques.

Jean-Luc

Ne remplir que les métas, et ne rien envoyer en en-tête ? Un changement d'hébergeur plus tard (c'est si vite arrivé) et tout est à l'eau.
Ce n'est pas nécessaire. Non. C'est juste du bon sens.
Mais puisque ton outil (qui a l'air de nécessiter beaucoup de messages pour publicité) dit le contraire, je ne saurais que m'incliner devant lui bien entendu.

En plus, le dieu Google ne lit que les métas, donc tant mieux.

Cordialement.

Dudu,

Merci pour cette réponse particulièrement constructive.

Jean-Luc

Merci Dudu et merci Jeanluc pour vos réponse.
Il faudra que je fasse un test avec les mots en cyrillique non encodés &xxx tels qu'ils le sont actuellement.
x Dudu, le jour où je changerai d'hébergeur, j'espère que tu me donneras les bons conseils

Les entités HTML (&xxx;) ont été implémentées pour pallier le problème d'encodage que certains webmasters ont eu en écrivant des caractères accentués en ISO alors que le document était en UTF-8.
Leur usage n'est donc qu'une solution de facilité

Merci yep.

Bonjour les gens, juste un denier point que l'on oublie bien souvent au niveau de l'UTF8.

Il faut également, si tu veux éviter des problèmes d'affichage, que tes pages soient "encodées" à la source en UTF-8 avec ton éditeur de texte préféré (en fait avec un éditeur qui gère les encodages de fichiers).

Petit article traitant des jeux de caractères : http://openweb.eu.org/articles/jeux_caracteres/

Merci du renseignement

Salut ;-)

Pour encoder facilement les caractères spéciaux, google docs & spreadsheets propose une petite fonction find & replace (dans le menu file) qui est très pratique et très performante.

Perso plus aucun soucis d'encodage. Par contre faut récupèrer le code en copier/coller, sinon il transforme les & en &

je trouve google docs vraiment top du coup (peut être que d'autres outils le propose mais j'avais pas trouver jusque là)