UTF-8 en source

Bonjour,


Je dois taper mon texte directement en mode source, dans Dreamweaver, puisqu'une page en comprend plusieurs, avec des <?php if ($page == "page1") { ?>. J'ai décidé d'opter pour l'UTF-8 dans l'encodage de ma base de données gérée par phpMyAdmin.

Pour faire plus simple, je me suis dit : "autant taper mes pages (x)html en utf-8 aussi, n'est-ce pas ..."


Bref, j'aimerais trouver un tableau complet et clair des correspondances, pour pouvoir taper du utf-8.

Jusqu'à présent, pour obtenir un é, je tapais &eacute;, ce qui ne me posait aucun problème (!).



Maintenant, je tape quoi ? Est-ce que je dois taper é ou bien &#233; ou indiféremment ? Et surtout, où puis-je trouver le tableau normatif des correspondances ?


Merci,

JG
Modifié par bul.fr (24 Jun 2006 - 18:09)

Petite précision :

Juste pour essayer, je tape

&eacute; &#233; é

dans une seule et même page, et j'obtiens 3 fois "é" (!).

Etant donné que je déclare la page de la façon suivante :

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

je ne comprend pas bien pourquoi &eacute; sort correctement...

Le but d'utf-8 est de pouvoir tapé é € à directement dans ton code

A partir du moment ou ton fichier est codé en utf-8 il n'y a aucun problème, tu pourra afficher tous les caractères que tu désires.

Verifie bien que ton logiciel encode ta page en utf-8, sans cela ça ne marchera jamais.

Pense à mettre ton entête http au debut du fichier :

<?php header('Content-Type: text/html; charset=utf-8'); ?>

et la méta suivante au debut du head

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

Modifié par korigan (24 Jun 2006 - 20:18)

Attention, il faut bien distingueré l'encodage réel du document et l'encodage déclaré.

Encodage réel
Un document texte brut (page HTML, fichier texte, fichier XML…) est une suite de valeurs numériques (des octets), pas une suite de lettres. Quand tu enregistres un document, tu enregistres des valeurs numériques.

Ensuite, c'est l'encodage utilisé pour l'enregistrement du document qui décide si ton "é" correspond à la valeur numérique 233 (en iso-8859-1 ou en iso-8859-15), ou bien à la valeur 50089 (en UTF-8).

Pour beaucoup de lettres du français (en fait, il s'agit des 26 lettres minuscules et des 26 lettres capitales de l'anglais, qui sont communes à la majeure partie des lettres du français), les valeurs sont communes dans tous les encodages (ou presque). Il s'agit des valeurs dites "ASCII", car elles viennent de l'encodage ASCII.

Par exemple, la lettre A (A majuscule) a pour valeur numérique 65. La lettre z (Z minuscule) a pour valeur numérique 122.

C'est pour cela que si on affiche un texte en UTF-8 en disant au navigateur qu'il s'agit d'iso-8859-1, on obtient un texte dont seuls les caractères non-ASCII sont modifiés, car les valeurs de ces lettres de base sont communes aux deux encodages, mais pas celles des lettres « spéciales ».

Déclaration de l'encodage réel du document
Ces déclarations n'ont qu'une valeur… déclarative. Elles se contentent de dire au navigateur quel encodage il faut utiliser. En d'autres termes : le navigateur va voir la valeur numérique 50089, mais il ne peut pas deviner qu'il s'agit de la lettre "é" codée en UTF-8. On va donc lui dire que le document est en UTF-8, et à partir de là il se dépatouille tout seul.

Deux types de déclaration :
– la déclaration via les en-têtes HTTP (des informations sur le document, que le serveur envoie au navigateur avec le code du document) ;
– la déclaration via la balise meta http-equiv (qui en gros signifie que l'on met dans le code un équivalent à une ligne d'en-tête HTTP).

Notes :
– les valeurs numériques données ci-dessus sont toutes en décimal (système classique à dix chiffres). J'aurais aussi pu donner la valeur numérique 233 en héxadécimal (ce qui donne : ) ou en binaire (ce qui donne : );

– &#233; est une entité HTML, écrite uniquement avec des caractères ASCII. Pour info, il n'y a qu'une centaine de caractères ASCII en tout, ce qui ne permet pas de coder des caractères autres que l'alphabet (sans accents ou autres diacritiques) et une série de signes de ponctuation et de typographie. On indique donc au navigateur quel caractère afficher grâce à un code. On aurait aussi pu utiliser le code &eacute; (toujours que des caractères ASCII) qui désigne le même caractère.

– é est un affichage incorrect de la valeur numérique 50089 (la lettre "é"). En gros, ça signifie que le fichier a été encodé en UTF-8, mais pas déclaré comme tel, et affiché en iso-8859-1 par exemple. Je peux rentrer dans les détails si ça intéresse quelqu'un, mais j'en reste là pour l'instant.

Merci pour vos réponse.


J'ai encore une précision à recquérir : dans phpMyAdmin 2.8.0.2, je dois préciser l'encodage de chaque champ. J'ai 21 utf-8 différents, parmi lesquels utf8_bin, utf8_unicode_ci, utf8_general_ci, etc.


Je choisis lequel ?

bul.fr a écrit :
Je choisis lequel ?

Bonne question. Il me semble qu'il y a deux choses : l'encodage, et le ???. Là où tu as une trentaine de choix, c'est pour le ??? (rhââ je me souviens plus du nom !)…

Mais là tout de suite, la documentation en ligne de MySQL a l'air d'être complètement en rade (pages vides, database error – assez ironique pour un SGBD).

mpop a écrit :
Il me semble qu'il y a deux choses : l'encodage, et le ???.

Non, là en l'occurence, c'est dans un seul et même menu, et ça se présente ainsi :

utf8
utf8_bin
utf8_general_ci
utf8_swedish_ci
utf8_turkish_ci
utf8_unicode_ci

A peu près toutes les langues courantes sont mentionnées, mais pas le français. De toute façon, j'ai besoin de qq chose de général, puisque j'écris parfois en cyrillique.

Et malheureusement, l'option utf8 tout court n'est pas permise. Elle renvoie automatiquement à utf8_bin. Est-ce que ça signifie que utf8_bin est en quelque sorte la valeur par défaut d'utf8 ??

bul.fr a écrit :
Non, là en l'occurence, c'est dans un seul et même menu

Ben si, ce sont deux choses différentes.
L'encodage est l'UTF-8. Il n'existe pas d'encodage UTF8_bin ou UTF-8_swedish_ci.

À partir de MySQL 4.1, ce SGBDR utilise – en plus de l'encodage – une donnée qui est l'interclassement (ou collation en anglais). Le terme vient de me revenir.

L'interclassement sert par exemple au tri « alphabétique » (quand on demande un tri ASC ou DESC). Suivant la langue de référence, la manière de trier « alphabétiquement » les caractères peut varier, et MySQL intègre des tables de référence pour savoir que « b est plus grand que a » et « a est plus grand que 9 », par exemple.

Bref, à moins que les tris ou comparaison de champs ne soient super importants pour ton projet, garde le choix par défaut, ou utilise le « general ».

Au passage, par défaut pour du Latin1, l'interclassement choisi est du latin1_swedsih_ci…

mpop a écrit :

Bref, à moins que les tris ou comparaison de champs ne soient super importants pour ton projet, garde le choix par défaut, ou utilise le « general ».

Au passage, par défaut pour du Latin1, l'interclassement choisi est du latin1_swedsih_ci…

Super,

Thank you, merci. Maintenant, c'est plus clair.

Du coup, je suis en train de repasser toute ma bdd, pour virer tous les anciens &eacute; &egrave; &ccedil; etc. ...

Encore merci,

JG

pour écrire mes scripts (html, php,css) en utf-8 ou autre j'ai trouvé ce petit éditeur Notepad++ (menu: Format > Encode in ...), mais il n'est certainement pas le seul a pouvoir permettre le choix de l'encodage...
mon problème d'origine était l'encodage d'une feuille css
Modifié par Coyote (01 Jul 2006 - 18:50)

Coyote a écrit :
petit éditeur Notepad++ (menu: Format > Encode in ...), mais il n'est certainement pas le seul a pouvoir permettre le choix de l'encodage...

Merci pour cette indication, Coyote. Je suppose que Notepad++ est utilisable avec Windows (je suis sur Mac).

Moi j'utilise Dreamweaver, qui permet en effet de choisir l'encodage : Modifier > Propriétés de la page...

Le fait est que je pensais, jusqu'à recevoir les réponses ci-dessus, que l'"encodage", c'était quand Dreamweaver transforme (sans me demander mon avis, du reste) tous les é è à ç que j'entre en tapant dans le mode création par des &eacute &egrave &agrave &ccedil dans la source.

Du coup, quand je tapais moi-même dans la source, et que j'entrais directement des &eacute, JE CROYAIS EN TOUTE BONNE FOIS FAIRE DE L'ENCODAGE. Que n'étais-je innocent et ignorant !

Voilà l'origine inavouable de la publication de ce spot...
Modifié par bul.fr (03 Jul 2006 - 07:01)

bul.fr a écrit :
Du coup, quand je tapais moi-même dans la source, et que j'entrais directement des &eacute, JE CROYAIS EN TOUTE BONNE FOIS FAIRE DE L'ENCODAGE. Que n'étais-je innocent et ignorant !

Je te rassure, l'erreur est courante. J'ai même eu un prof cette année, pourtant professionnel du web, qui n'a pas voulu me croire quand je lui disais que les entités HTML (les &eacute; et compagnie) ne servaient pour l'essentiel que si le document étant en encodage ASCII (alphabet anglais et caractères de base).