Aller au contenu

Le Charset joue-t-il un rôle ?


baulet

Sujets conseillés

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.

;)

Lien vers le commentaire
Partager sur d’autres sites

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.

Modifié par yep
Lien vers le commentaire
Partager sur d’autres sites

Il semblerait que tu aies un site ayant pour cible l'international, préfère l'UTF-8.

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 ?

Lien vers le commentaire
Partager sur d’autres sites

Ne risque t-il pas d'avoir des pages inutilement plus lourdes ?
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.

j'ai lu quelque part sur le forum que l'utf8 était préféré en xhtml strict...
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.

Lien vers le commentaire
Partager sur d’autres sites

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).

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).

Lien vers le commentaire
Partager sur d’autres sites

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...

Lien vers le commentaire
Partager sur d’autres sites

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).

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

AddDefaultCharset UTF-8

Lien vers le commentaire
Partager sur d’autres sites

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.
D'accord.

En cas de conflit, c'est Apache qui l'emporte.
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.

Apache est configuré par défaut pour envoyer de l'ISO 8859-1.
Beaucoup de serveurs Apache envoient seulement l'en-tête de codage "text/html", ce qui laisse toute liberté pour l'encodage des pages.

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

AddDefaultCharset UTF-8

Ce n'est pas nécessaire. J'ai testé la page d'accueil du site de Nullette avec mon petit outil [i]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

Modifié par Jeanluc
Lien vers le commentaire
Partager sur d’autres sites

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

Modifié par Jeanluc
Lien vers le commentaire
Partager sur d’autres sites

Ce n'est pas nécessaire. J'ai testé la page d'accueil du site de Nullette avec mon petit outil [i]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.
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.

Lien vers le commentaire
Partager sur d’autres sites

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 :)

Modifié par Nullette
Lien vers le commentaire
Partager sur d’autres sites

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

et le code pour le cyrillique.

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é :P

Lien vers le commentaire
Partager sur d’autres sites

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/

Lien vers le commentaire
Partager sur d’autres sites

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 & :unsure:

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

Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...