UTF-8, accents et entités numériques...

info@desimagesparmilliers.com wrote:

Je m'interroge toujours sur la méthode à utiliser pour les
caractères accentués d'une page web, à savoir, est-il préférable
d'encoder la page en UTF-8 et de laisser les caractères accentués
tels quels dans le code source ou bien vaut-il mieux les remplacer par
leur entité numérique correspondante ? Je pose cette question surtout
par rapport à l'indexation des sites sur les moteurs de recherche.
Certains outils d'analyse ne comprennent pas les caractères accentués
du coup les robots les interprêtent-ils tous de la même façon ?

Dans tous les cas, il *faut* que vous sachiez quel codage vous utilisez,
que ce codage soit bien déclaré, et que vous sachiez pourquoi ce codage
a été choisit.
Lire :
http://pgoiffon.free.fr/info/i18n/web_charset.php

Par rapport à votre post :
- les entités ne sont à employer que dans de très rares cas, et c'est
ainsi depuis des années !
- UTF-8 n'est pas forcément le choix idéal (bien que très largement
implémenté dans les navigateurs de nos jours). à voir selon votre contexte

Le 19/10/2006 15:49, info@desimagesparmilliers.com a écrit :

Je m'interroge toujours sur la méthode à utiliser pour les
caractères accentués d'une page web, à savoir, est-il préférable
d'encoder la page en UTF-8 et de laisser les caractères accentués
tels quels dans le code source ou bien vaut-il mieux les remplacer par
leur entité numérique correspondante ?

Ne serait-ce que pour faciliter la relecture du code HTML, il vaut cent
fois mieux encoder la page avec un charset contenant la plupart (sinon
tous) des caractères utilisés et laisser les caractères accentués tels
quels plutôt que de faire appel à des entités numériques.

Le choix de ce charset peut être UTF-8, mais cela peut très bien être
ISO-8859-1 pour du français ou de l'allemand, Shift_JIS pour du
japonais, et ainsi de suite.

Je pose cette question surtout
par rapport à l'indexation des sites sur les moteurs de recherche.
Certains outils d'analyse ne comprennent pas les caractères accentués
du coup les robots les interprêtent-ils tous de la même façon ?

Si un robot ne sait pas interpréter un « é » écrit « é », il saura
d'autant moins le faire s'il est écrit « é » ou « é ».
Bien sûr cela vaut aussi pour le relecteur humain (du moins à
moi ça me paraît évident). ;-)


Cordialement,
--
Olivier Miakinen

On 19 Oct 2006, info@desimagesparmilliers.com wrote:

Je m'interroge toujours sur la méthode à utiliser pour les
caractères accentués d'une page web, à savoir, est-il préférable
d'encoder la page en UTF-8 et de laisser les caractères accentués
tels quels dans le code source ou bien vaut-il mieux les remplacer par
leur entité numérique correspondante ?

Il est préférable de donner *réellement* le codage ("charset")
dans le "HTTP header":
http://www.w3.org/International/O-HTTP-charset.html

Il n'importe pas vraiment si tu utilises &#number; ou pas.
http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.html#s6
http://ppewww.ph.gla.ac.uk/~flavell/charset/checklist.html#s7

http://www.desimagesparmilliers.com

| Content-Type: text/html

Pas de "charset"!

info@desimagesparmilliers.com a écrit :

Je m'interroge toujours sur la méthode à utiliser pour les
caractères accentués d'une page web, à savoir, est-il préférable
d'encoder la page en UTF-8 et de laisser les caractères accentués
tels quels dans le code source ou bien vaut-il mieux les remplacer par
leur entité numérique correspondante ? Je pose cette question surtout
par rapport à l'indexation des sites sur les moteurs de recherche.
Certains outils d'analyse ne comprennent pas les caractères accentués
du coup les robots les interprêtent-ils tous de la même façon ? Si
vous avez des précisions à ce sujet... je suis preneur.

Pour ma part, je préfère utiliser un bon htmlentities() pour deux raisons:
1) lorsque les données sont enregistrées en base, il vaut mieux éviter
les accents car on ne sait pas toujours comment est configuré le serveur
2) je me fout un peu des robots et préfère donner la priorité aux
visiteurs en utilisant des codes valables partout.

Maintenant, l'entité numérique? pourquoi aller chercher si loin? c'est
bien moins lisible qu'un superbe î :)

--
Astuces pour webmasters: http://www.crazycat.info
Tchat francophone: http://www.crazy-irc.net

Bonjour,

Voilà quelques mois, j'ai commis le texte suivant que je reproduis en
partie, sans retouche. Peut-être répondra-t-il à la question...

Encodage des caractères

Afin de promouvoir l'intéropérabilité, Sgml exige de chaque
application (y compris de son fils Html) qu'elle spécifie son jeu de
caractères du document. Or, le jeu de caractères Ascii n'est pas
suffisant pour un système d'information international comme le web ;
en effet, l'Ascii de base représente les caractères sur 7 bits
(c'est-à-dire 128 caractères possibles, de 0 à 127) , & ne
contient donc pas de caractères accentués ou spécifiques à une
langue. Aussi utilise-t-on un jeu de caractères universel défini par
la norme Iso 10646, qui équivaut caractère par caractère à la norme
Unicode. Unicode est un système d'encodage des caractères sur 16
bits, mis au point en 1991, qui permet de représenter n'importe quel
caractère, indépendamment de tout système d'exploitation ou de
langage de programmation.

Les encodages de caractères couramment utilisés sur le Web
comprennent Iso-8859-1 (appelé aussi Latin-1, utilisable pour la
plupart des langues d'Europe de l'Ouest), Iso-8859-5 (qui gère le
cyrillique), Shift_Jis (un encodage du japonais), Euc-Jp (un autre
encodage du japonais) & Utf-8, encodage de la norme Iso 10646 qui
utilise un nombre différent d'octets pour différents caractères.

Utf-8 est le plus répandu, car il peut afficher la plupart des
caractères de langues les plus courants & fonctionne sur la plupart
des ordinateurs.

Cependant, les navigateurs doivent savoir comment sont codés les
caractères pour pouvoir les restituer correctement. Il faut donc
préciser son encodage dans la source du document : c'est le charset.

L'encodage Utf-8 doit être déclaré comme suit dans l'en-tête du
document : <meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" />. Avec le langage de script Php, le code est : <?
header("Content-Type: text/html; charset= UTF-8"); ?>. On peut aussi
utiliser le fichier .htaccess à la racine d'un serveur Apache &
associer tous les fichiers avec l'extension .html au jeu de
caractères voulu en écrivant : AddType text/html;charset=UTF-8 html.
Références des caractères

Un encodage de caractères donné peut ne pas exprimer tous les
caractères du jeu de caractères du document. Avec ces encodages ou
lorsque les configurations matérielles ou logicielles ne permettent
pas aux utilisateurs d'entrer directement certains caractères, les
auteurs peuvent avoir recours aux références de caractères Sgml. Les
références de caractères sont un mécanisme, indépendant de
l'encodage, utilisé pour ajouter n'importe quel caractère issu du
jeu de caractères du document. Les références de caractères en Html
peuvent se présenter sous deux formes : entités de caractères ou
caractères numériques (décimaux ou hexadécimaux).

Ainsi, par exemple, la lettre "î" (le "i" avec le symbole diacritique
du circonflexe) peut être codé : & icirc; avec son entité de
caractère, & #238; avec son entité numérique décimale & & #x00EE;
avec son entité numérique hexadécimale.

Néanmoins, & l'exemple était délibérément mal choisi, il est
inutile d'encoder un "î", puisque Utf-8 est capable de le
reconnaître.
Quels caractères encoder ?

Après avoir constaté que le jeu de caractères Utf-8 ne permettait
pas une reconnaissance universelle conformément à la norme, nous
n'avons pas trouvé de réponses satisfaisantes dans les arcanes du
Web sur les caractères à encoder. Aussi avons-nous procéder à des
tests empiriques sur une grande variété de navigateurs, y compris
ceux des téléphones mobiles. Nous cherchions une règle applicable
dans toutes les circonstances. Nous sommes parvenus à la conclusion
que devaient être encodés les caractères non accessibles au clavier.
Le travail d'encodage n'est pas plus long qu'un "copier-coller"
aux résultats aléatoires !
Comment encoder les caractères ?

Au cours des mêmes tests, nous avons constaté que le codage
hexadécimal était le plus souvent reconnu.

Pour connaître le code hexadécimal d'un caractère donné, il
suffit de consulter (voire d'enregistrer) une page comme celle de
Digital Minute, Xhtml Character Entity Reference, qui présente pour
chaque caractère les trois références : le code hexadécimal
apparaît sur la troisième ligne ; il suffit de remplacer le U par &
#x & d'ajouter à la fin & . Par exemple, pour le guillemet français
ouvrant, le tableau indique : u00AB. Après réécriture, le code
hexadécimal devient : & #x00AB;.

Une autre variante, sous Windows ®, est d'utiliser la "table des
caractères". Sous n'importe quelle police de caractères latins, je
sélectionne le guillemet français ouvrant. Un message dans la barre
d'état indique "U+00AB GUILLEMET GAUCHE". Je remplace U+ par & #x &
j'ajoute à la fin & . (Dans l'"affichage avancé", l'option
"Unicode" doit être sélectionnée.)

Le recours à l'encodage permet d'éviter l'écueil des
caractères dont la signification est particulière en Html ou en Php
(l'échappement de l'apostrophe n'est plus un souci).

Certains caractères "exotiques" ne sont pas reconnus par l'ensemble
des navigateurs.

Cordialement,

P.V.

CrazyCat wrote:

Pour ma part, je préfère utiliser un bon htmlentities() pour deux raisons:
1) lorsque les données sont enregistrées en base, il vaut mieux éviter
les accents car on ne sait pas toujours comment est configuré le serveur
2) je me fout un peu des robots et préfère donner la priorité aux
visiteurs en utilisant des codes valables partout.

Nous en avions déjà discuté et je juge vos propos particulièrement
dangereux. il n'y a *aucunes* raisons valables de systématiquement
utiliser des entités ! Cela doit être réservé à des usages bien
particuliers et surtout : maitrisés.

Pour moi vous appliquer sans vous poser de question la même vieille
recette, en vous donnant bonne conscience par des raisons qui ne sont
que mauvaises. Encore une fois, je trouve cela dangereux.

Mon précédent message démontre l'utilite d'utiliser les caractères
appropriés !

Voilà quelques mois, j'ai commis le texte suivant que je reproduis en
partie, sans retouche. Peut-être répondra-t-il à la question...

Encodage des caractères

Afin de promouvoir l'intéropérabilité, Sgml exige de chaque
application (y compris de son fils Html) qu'elle spécifie son jeu de
caractères du document. Or, le jeu de caractères Ascii n'est pas
suffisant pour un système d'information international comme le web ;
en effet, l'Ascii de base représente les caractères sur 7 bits
(c'est-à-dire 128 caractères possibles, de 0 à 127) , & ne
contient donc pas de caractères accentués ou spécifiques à une
langue. Aussi utilise-t-on un jeu de caractères universel défini par
la norme Iso 10646, qui équivaut caractère par caractère à la norme
Unicode. Unicode est un système d'encodage des caractères sur 16
bits, mis au point en 1991, qui permet de représenter n'importe quel
caractère, indépendamment de tout système d'exploitation ou de
langage de programmation.

Les encodages de caractères couramment utilisés sur le Web
comprennent Iso-8859-1 (appelé aussi Latin-1, utilisable pour la
plupart des langues d'Europe de l'Ouest), Iso-8859-5 (qui gère le
cyrillique), Shift_Jis (un encodage du japonais), Euc-Jp (un autre
encodage du japonais) & Utf-8, encodage de la norme Iso 10646 qui
utilise un nombre différent d'octets pour différents caractères.

Utf-8 est le plus répandu, car il peut afficher la plupart des
caractères de langues les plus courants & fonctionne sur la plupart
des ordinateurs.

Cependant, les navigateurs doivent savoir comment sont codés les
caractères pour pouvoir les restituer correctement. Il faut donc
préciser son encodage dans la source du document : c'est le charset.

L'encodage Utf-8 doit être déclaré comme suit dans l'en-tête du
document : <meta http-equiv="Content-Type" content="text/html;
charset=UTF-8" />. Avec le langage de script Php, le code est : <?
header("Content-Type: text/html; charset= UTF-8"); ?>. On peut aussi
utiliser le fichier .htaccess à la racine d'un serveur Apache &
associer tous les fichiers avec l'extension .html au jeu de
caractères voulu en écrivant : AddType text/html;charset=UTF-8 html.

Références des caractères

Un encodage de caractères donné peut ne pas exprimer tous les
caractères du jeu de caractères du document. Avec ces encodages ou
lorsque les configurations matérielles ou logicielles ne permettent
pas aux utilisateurs d'entrer directement certains caractères, les
auteurs peuvent avoir recours aux références de caractères Sgml. Les
références de caractères sont un mécanisme, indépendant de
l'encodage, utilisé pour ajouter n'importe quel caractère issu du
jeu de caractères du document. Les références de caractères en Html
peuvent se présenter sous deux formes : entités de caractères ou
caractères numériques (décimaux ou hexadécimaux).

Ainsi, par exemple, la lettre "î" (le "i" avec le symbole diacritique
du circonflexe) peut être codé : & icirc; avec son entité de
caractère, & #238; avec son entité numérique décimale & & #x00EE;
avec son entité numérique hexadécimale.

Néanmoins, & l'exemple était délibérément mal choisi, il est
inutile d'encoder un "î", puisque Utf-8 est capable de le
reconnaître.

Quels caractères encoder ?

Après avoir constaté que le jeu de caractères Utf-8 ne permettait
pas une reconnaissance universelle conformément à la norme, nous
n'avons pas trouvé de réponses satisfaisantes dans les arcanes du
Web sur les caractères à encoder. Aussi avons-nous procéder à des
tests empiriques sur une grande variété de navigateurs, y compris
ceux des téléphones mobiles. Nous cherchions une règle applicable
dans toutes les circonstances. Nous sommes parvenus à la conclusion
que devaient être encodés les caractères non accessibles au clavier.
Le travail d'encodage n'est pas plus long qu'un "copier-coller"
aux résultats aléatoires !

Comment encoder les caractères ?

Au cours des mêmes tests, nous avons constaté que le codage
hexadécimal était le plus souvent reconnu.

Pour connaître le code hexadécimal d'un caractère donné, il
suffit de consulter (voire d'enregistrer) une page comme celle de
Digital Minute, Xhtml Character Entity Reference, qui présente pour
chaque caractère les trois références : le code hexadécimal
apparaît sur la troisième ligne ; il suffit de remplacer le U par &
#x & d'ajouter à la fin & . Par exemple, pour le guillemet français
ouvrant, le tableau indique : u00AB. Après réécriture, le code
hexadécimal devient : & #x00AB;.

Une autre variante, sous Windows ®, est d'utiliser la "table des
caractères". Sous n'importe quelle police de caractères latins, je
sélectionne le guillemet français ouvrant. Un message dans la barre
d'état indique "U+00AB GUILLEMET GAUCHE". Je remplace U+ par & #x &
j'ajoute à la fin & . (Dans l'"affichage avancé", l'option
"Unicode" doit être sélectionnée.)

Le recours à l'encodage permet d'éviter l'écueil des
caractères dont la signification est particulière en Html ou en Php
(l'échappement de l'apostrophe n'est plus un souci).

Certains caractères "exotiques" ne sont pas reconnus par l'ensemble
des navigateurs.

Cordialement,

P.V.

paul.volfoni@gmail.com wrote:

Voilà quelques mois, j'ai commis le texte suivant que je reproduis en
partie, sans retouche. Peut-être répondra-t-il à la question...

D'abord avant de commencer, bravo de vos efforts. Cependant je trouve
quelques petites choses qui me posent question ou me paraissent
inexactes dans votre texte... J'emplois moi aussi des termes qui sont
sans doutes inexacts, merci aux contributeurs de corriger s'il y a lieu :

Afin de promouvoir l'intéropérabilité, Sgml exige de chaque
application (y compris de son fils Html) qu'elle spécifie son jeu de
caractères du document.

Auriez vous une référence pour cette affirmation ? Je crains que vous
confondiez des choses... En effet HTML n'exige à ma connaissance
aucunement de préciser le codage utilisé pour chaque page rédigée par un
concepteur (c'est d'ailleurs bien plus le rôle de HTTP de le faire), par
contre le jeux de caractères "utilisé" dans HTML est lui bien définit :
http://www.w3.org/TR/html4/intro/intro.html#h-2.3.1

Or, le jeu de caractères Ascii n'est pas
suffisant pour un système d'information international comme le web ;

Attention : beaucoup de documents ne parlent que d'ascii... il n'existe
pas que ascii ! Plusieurs codages ne sont en rien basés et/ou
compatibles avec Ascii... les plus fameux étant la famille EBCDIC d'IBM.

Unicode est un système d'encodage des caractères sur 16
bits

NON : Unicode est un consortium, une norme, un jeux de caractères
Il existe plusieurs codages du jeux de caractères Unicode : UTF-7,
UTF-8, UTF-16, UTF-32 (le nombre représentant la taille des code units,
un caractère étant représenté par une ou plusieurs code unit)

Utf-8, encodage de la norme Iso 10646

UTF-8 est plutôt un codage d'Unicode... Les codages de ISO 10646 sont
les UCS-*
Cela dis l'ISO a parfois quelques débordements de vocabulaire, disons

Utf-8 est le plus répandu, car il peut afficher la plupart des
caractères de langues les plus courants & fonctionne sur la plupart
des ordinateurs.

Sa popularité est surtout du au fait qu'il est compatible avec us-ascii...

Cependant, les navigateurs doivent savoir comment sont codés les
caractères pour pouvoir les restituer correctement. Il faut donc
préciser son encodage dans la source du document : c'est le charset.

Pas dans le source HTML, du moins pas seulement : c'est dans l'entête
HTTP Content-Type qu'il faut *ABSOLUMENT* que cette information soit
présente.
Vous indiquez d'ailleurs ensuite des méthodes (via PHP ou .htaccess)
pour le faire...

Un encodage de caractères donné peut ne pas exprimer tous les
caractères du jeu de caractères du document.

Ce passage me parait un peu confus : ne serait-il pas plus simple de
partir sur un exemple d'une page multilingue ?

Après avoir constaté que le jeu de caractères Utf-8 ne permettait
pas une reconnaissance universelle conformément à la norme, nous
n'avons pas trouvé de réponses satisfaisantes dans les arcanes du
Web sur les caractères à encoder.

Pas bien compris ce passage ??

[entités numériques]

Pour connaître le code hexadécimal d'un caractère donné

Voir :
http://www.w3.org/TR/html4/charset.html#h-5.3.1

Le numéro présent dans l'entité est le numéro de caractère dans Unicode
(ou ISO 10646, ce qui revient au même)

Le site Unicode.org fournit tout ce qu'il faut pour arriver à le
retrouver ("where is my character"), sinon des outils comme celui
développé par Ian Hickson aident grandement :
http://lachy.id.au/dev/mozilla/sidebar/Unicode/character-tools
Ou encore l'excellent outil développé par notre indispensable Olivier
Miakinen :
http://www.miakinen.net/vrac/charsets/

Le Thu, 19 Oct 2006 18:39:38 +0200, Pierre Goiffon
<pgoiffon@free.fr.invalid> écrivait dans
fr.comp.infosystemes.www.auteurs:

CrazyCat wrote:

Pour ma part, je préfère utiliser un bon htmlentities() pour deux raisons:
1) lorsque les données sont enregistrées en base, il vaut mieux éviter
les accents car on ne sait pas toujours comment est configuré le serveur
2) je me fout un peu des robots et préfère donner la priorité aux
visiteurs en utilisant des codes valables partout.

Nous en avions déjà discuté et je juge vos propos particulièrement
dangereux. il n'y a *aucunes* raisons valables de systématiquement
utiliser des entités ! Cela doit être réservé à des usages bien
particuliers et surtout : maitrisés.

Pour moi vous appliquer sans vous poser de question la même vieille
recette, en vous donnant bonne conscience par des raisons qui ne sont
que mauvaises. Encore une fois, je trouve cela dangereux.

Il y a au moins un problème potentiel avec les accents. L'ancien
serveur que j'utilisais avait le suédois comme langue par défaut
(avec un hébergeur en Californie). Alors, je me dis que le serveur
mySQL par exemple peut être mal configuré et qu'on peut perdre des
accents en cours de route.

Sinon, moi non plus, je ne vois pas pourquoi enregistrer les entités
sachant que cela prend plus de place dans la BDD.


Denis

Le 19/10/2006, Pierre Goiffon a supposé :

Pour ma part, je préfère utiliser un bon htmlentities() pour deux raisons:
1) lorsque les données sont enregistrées en base, il vaut mieux éviter les
accents car on ne sait pas toujours comment est configuré le serveur
2) je me fout un peu des robots et préfère donner la priorité aux visiteurs
en utilisant des codes valables partout.

Nous en avions déjà discuté et je juge vos propos particulièrement dangereux.
il n'y a *aucunes* raisons valables de systématiquement utiliser des entités
! Cela doit être réservé à des usages bien particuliers et surtout :
maitrisés.

Pour moi, j'utilise les entités, quand je ne sais pas le taper
directement avec mon clavier !

--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org