> English Polski Português-BR Pусский Svenska ไทย Українська
Utiliser la touche d'accès n pour naviguer au sein de la page. Sauter au début du contenu.
Ce document est une traduction. En cas de divergences ou d'erreurs, la dernière version originale en anglais fait autorité. Comme indiqué ci-dessous, les droits d'auteur reviennent au W3C.
Traducteur: J.SOLARI, yoyodesign.org
Public visé : Toute personne désireuse d'un résumé des informations clés concernant les codages de caractères dans HTML et XML. Pour plus d'informations, suivre les liens dans le texte, ou voir le chapitre « Pour approfondir ».
Le jeu de caractères du document de XML et HTML 4.0 est Unicode (ou ISO 10646). Cela signifie que les navigateurs HTML et les processeurs XML devraient se comporter comme s'ils utilisaient Unicode en interne. Toutefois, ça ne veut pas dire que les documents doivent être transmis en Unicode. Tant que le client et le serveur s'accordent sur un codage, ils peuvent utiliser n'importe quel codage convertible en Unicode. Lire plus à propos du jeu de caractères du document.
Il importe que le codage des caractères d'un document XML ou (X)HTML soit clairement étiqueté, de sorte que les clients puissent aisément le relier à Unicode. On y parvient par les méthodes suivantes :
Envoyer le paramètre charset dans une en-tête
Content-Type HTTP. Exemple :
Content-Type: text/html; charset=utf-8Pour cela, il vous faudra avoir accès au paramétrage du serveur, ou servir votre document via un script (cf. le document « Régler le paramètre charset HTTP » pour des précisions).
Pour du XML (y compris du XHTML), servez-vous du pseudo-attribut encoding dans la déclaration XML au début du
document, ou de la déclaration de texte au début d'une entité. Exemple :
<?xml version="1.0" encoding="utf-8" ?> Sachez que des problèmes potentiels peuvent naître de l'utilisation de cette méthode pour servir du XHTML 1.0 en tant que HTML.
Pour du HTML, ou du XHTML servi en tant que HTML, vous devriez toujours utiliser une balise <meta> au sein de
l'en-tête <head> du document. Exemple :
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >Pour XHTML, il faut rajouter une barre oblique à la fin :
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />Pour une discussion sur la meilleure approche à adopter selon le type du document (X)HTML, cf. le tutoriel « Les jeux de caractères et les codages dans XHTML, HTML et CSS ».
Les exemples précédents montrent des déclarations pour un contenu codé en UTF-8. Ce sera vraisemblablement la meilleure option de codage dans la plupart des cas mais ce n'est pas la seule possibilité.
Si vous n'utilisez pas UTF-8, remplacez la chaîne utf-8 dans les exemples par le nom du codage choisi. Vous pouvez consulter
la liste complète des noms de codages de caractères enregistrés par l'IANA (elle est
longue). En pratique, on préférera quelques codages, souvent les suivants : ISO-8859-1 (Latin-1), US-ASCII,
UTF-16, les autres codages de la série des ISO-8859, iso-2022-jp, euc-kr, et ainsi de suite.
Il importe non seulement d'utiliser les déclarations de codages précédentes dans HTTP ou dans le contenu, mais il faut aussi :
Enregistrer vos données dans le codage approprié depuis votre environnement d'édition ;
S'assurer qu'il n'y ait pas de conflit entre ce que vous déclarez dans le document et ce que le serveur applique automatiquement, car les paramètres du serveur priment sur les déclarations dans le document.
Pour des précisions sur ces questions, suivez les liens dans le document « Changer le codage de la page (X)HTML pour UTF-8 ». Quoique le document décrive une utilisation avec UTF-8, il convient pour tout codage utilisé.
On trouvera les valeurs de l'attribut encoding dans le registre de
l'IANA. Remarquez qu'ils y sont appelés noms de charset, bien qu'ils désignent en réalité des codages, et non des jeux de
caractères.
Si vous souhaitez des renseignements en profondeur à ce sujet, voir un article de Dan Connolly (« "Character Set" Considered Harmful ») et une réponse de Glenn Adams (« Character Set Terminology, SC2 vs. SC18 vs. Internet Standards »).
Note historique : Rick Jellife avait proposé d'utiliser les entités SPREAD de l'ERCS.
Donnez-nous votre avis (en anglais).
Traduit de la version anglaise datée du 20 juillet 2006. La traduction a été modifiée pour la dernière fois le 2006-10-26 17:41 GMT
Pour un résumé des changements importants, recherchez article-O-charset dans le blog i18n.
Copyright © 1996-2006 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Nouvelles publications