Charset en HTML 5

Otomatic

20/04/2013 à 19:22

GR écrivait :

Tu veux dire qu'une page comportant un Doctype valide et un Charset
explicite et ne comportant aucune erreur détectée par le w3c peut être
mal interprétée alors que c'est le but du w3c ? C'est grave ça !

Si il y avait une erreur entre le charset déclaré explicitement et celui
utilisé dans la page, la validation W3C l'aurait détecté.

Ce que je voulais dire, c'est que certains serveurs envoient - si pas
d'envoi par la page ou dans un fichier .htaccess - une entête déclarant
un charset qui sera prioritaire sur celui d'une balise <meta
--
Le logiciel de courrier d'Opera n'a rien de révolutionnaire
Forté Agent en faisait déjà autant, et même beaucoup plus, depuis trois lustres
Tout comme The Bat depuis belle lurette !

Olivier Miakinen

04/05/2013 à 23:17

Bonjour,

Je reviens sur une réponse donnée voilà plus d'une semaine :

[...] En HTML5 :

<!DOCTYPE html>
<html lang="fr">
<head>
<meta charset="utf-8" />
...
</head>

J'allais critiquer en disant que si c'est du HTML il ne faut pas de
« / » final dans le cas d'une balise auto-fermante, mais j'ai voulu
le vérifier d'abord et j'ai trouvé que les deux sont autorisés :
<http://www.web1.pro/balises-auto-fermantes-html5.htm>.

voir aussi :
<http://www.pompage.net/traduction/html5-et-le-futur-du-web>.

Bonne lecture !

Pierre Goiffon

07/05/2013 à 11:47

Bonjour,

Le 19/04/2013 10:08, Jean Francois Ortolo a écrit :

Ceci, même si le contenu de ma base de données reste en mode latin1.

Convertir la database existante en mode utf8 ce serait un sacré boulot.

Attention, ne pas confondre la manière dont est stocké le contenu dans
la base et la manière dont on le récupère ! On peut très bien avoir un
stockage iso latin-1 et récupérer en utf-8 par exemple...

Le stockage, c'est du côté de la collation qu'il faut regarder. Ca
inclus le stockage, mais aussi la comparaison et le tri (est-ce que c
est équivalent à ç ? é avant e ?), la prise en compte ou non de la casse.

L'application qui se connecte elle utilisera les propriétés de la
connexion. On pourra donc récupérer le contenu en utf-8 par exemple.
Là, tout dépend du middleware que vous utilisez (odbc, jdbc, ...)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

A ma connaissance les langages proposent d'abord des fonctions se basant
sur le nombre de caractère, décoléré de la représentation binaire. Et
les chaines sont traitées en interne avec un charset unicode ou dérivé.

Pierre Goiffon

07/05/2013 à 11:52

Le 20/04/2013 11:51, Sergio a écrit :

vous aurez beau mettre une balise html <meta charset="utf-8" />
c'est la déclaration du serveur qui prévaudra.

(belle absurdité, en passant)

Pour lire la balise meta, il faut savoir lire le flux html, et pour lire
ce dernier il faut connaitre son charset !

Si l'on n'avait que la balise meta, il faudrait donc que tous agents
utilisateurs se débrouillent à essayer de deviner le charset pour
pouvoir enfin avoir confirmation qu'ils ne se sont pas trompés en lisant
la valeur de la balise meta !
Il y a plusieurs cas assez tordus, je n'ai pas retrouvé trace des pages
sur lesquelles j'étais tombé en me posant moi même cette question il y a
plusieurs années... Mais déjà, songez qu'il y a de nombreux charset qui
ne sont pas DU TOUT dérivés de ascii (toute la famille EBCDIC par
exemple) ou aussi simples à détecter qu'un UTF-16 avec BOM, et que bien
sûr il existe des recouvrements (des suites de bits valides dans
plusieurs charsets).

Il est donc naturel que l'information de charset soit en meta dans le
protocole de transport. Dans le cas de http, vous constaterez d'ailleurs
que l'entête utilisé est... content-type.

Oui mais comment intervenir sur le serveur ?

Soit dans le .htaccess avec la directive "CharsetDefault", soit en
balançant le header adhoc en PHP.

Le W3C avait mis en place pas mal de pages sur le sujet, il y en a une
dédiée... Oui elle est toujours là, voici l'url :
http://www.w3.org/International/O-HTTP-charset.fr.php

Tout le monde est invité à la compléter !

Pierre Goiffon

07/05/2013 à 11:55

Le 19/04/2013 17:23, Eric Demeester a écrit :

Je reste donc en windows-1252, non mais !

C'est une _très_ mauvaise idée, car ce jeu de caractères, spécifique à
Ms-Windows, risque d'être mal interprété sur MacOs, Linux, etc.

J'ai lu très souvent cette assertion... Sans jamais trouver d'exemple
concret.

Moi-même, j'ai eu à choisir windows-1252 dans des cas contraints (mail
avec source copié/collée depuis office par exemple) et si j'ai eu
quelques rares prb chez certains clients, le compromis était bien le
moins pire.

Est-ce que vous auriez plus de détails Eric ?

Jean Francois Ortolo

07/05/2013 à 12:16

Le 07/05/2013 11:47, Pierre Goiffon a écrit :

Bonjour,

Le 19/04/2013 10:08, Jean Francois Ortolo a écrit :
Ceci, même si le contenu de ma base de données reste en mode latin1.

Convertir la database existante en mode utf8 ce serait un sacré
boulot.

Attention, ne pas confondre la manière dont est stocké le contenu dans
la base et la manière dont on le récupère ! On peut très bien avoir un
stockage iso latin-1 et récupérer en utf-8 par exemple...

Le stockage, c'est du côté de la collation qu'il faut regarder. Ca
inclus le stockage, mais aussi la comparaison et le tri (est-ce que c
est équivalent à ç ? é avant e ?), la prise en compte ou non de la casse.

L'application qui se connecte elle utilisera les propriétés de la
connexion. On pourra donc récupérer le contenu en utf-8 par exemple.
Là, tout dépend du middleware que vous utilisez (odbc, jdbc, ...)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

A ma connaissance les langages proposent d'abord des fonctions se basant
sur le nombre de caractère, décoléré de la représentation binaire. Et
les chaines sont traitées en interne avec un charset unicode ou dérivé.

Bonjour Monsieur

Pour la conversion automatique de ma base de données, j'ai utilisé un
script php "convert.php", dont voici les caractéristiques techniques :

- Connexion à la database en utf8, avec SET NAMES='utf8' ( ou sans le
signe égal je ne sais splus ;( ),

- Lectures des noms de tables ( qui sont d'abord toutes en latin1 ):
SHOW TABLES, et mise en variable indicée de ces noms de table,

- Compte tenu du fait qu'aucun des champs de ces tables n'ont de
liens externes ( je ne sais plus ce que c'est, genre FOREIGN qqchose, je
n'utilise jaamais cette fonctionnalité de MySQL ), pour chaque valeurs
$table de cette variable indicée :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8";

"COMMIT";

"ANALYZE TABLE " . $table;

Je prend le résultat et l'affiche sur la sortie par défaut 1 avec echo.

Donc, après avoir lancé ce script en cli ( serveur web Apache2 arrêté ):

php -q -f convert.php > 1>result.txt 2>result_err.txt

J'ai regardé le deuxième fichier : pas d'erreur.

Le premier fichier result.txt ne m'a indiqué que ces deux commentaires :

"OK" , ou

"This table is already up to date".

Donc, cette conversion de la database ( 43 tables MySQL ), n'a duré
qu'un demi-minute, est s'est faite correctement.

Il n'y a aucune différence pour les voyelles accentuées, à
l'affichage en utf8, entre les anciens enregistrements théoriquement
convertis, et ceux récents ( hier par exemple ), qui sont bien
enregistrés en utf8.

L'affichage est normal, tel que vous pouvez le constater dans les
listes de courses anciennes des dix derniers jours, accessibles à partir
du lien :

www.pronostics-courses.fr/php/courses_anciennes/old_courses.php

Il est vrai que 'ai fait cette conversion, je crois, le lundi 29
Avril au soir, mais vous pouvez très bien voir comment afficher ces
listes de courses plus anciennes que çà.

Merci de me dire, si cette instruction "ALTER TABLE CONVERT", a bien
converti le contenu des tables MySQL aussi bien que leurs déclarations.

Bien amicalement.

Jean François Ortolo

Le 07/05/2013 11:47, Pierre Goiffon a écrit :

Bonjour,

Le 19/04/2013 10:08, Jean Francois Ortolo a écrit :

Ceci, même si le contenu de ma base de données reste en mode latin1.

Convertir la database existante en mode utf8 ce serait un sacré
boulot.

Attention, ne pas confondre la manière dont est stocké le contenu dans
la base et la manière dont on le récupère ! On peut très bien avoir un
stockage iso latin-1 et récupérer en utf-8 par exemple...

Le stockage, c'est du côté de la collation qu'il faut regarder. Ca
inclus le stockage, mais aussi la comparaison et le tri (est-ce que c
est équivalent à ç ? é avant e ?), la prise en compte ou non de la casse.

L'application qui se connecte elle utilisera les propriétés de la
connexion. On pourra donc récupérer le contenu en utf-8 par exemple.
Là, tout dépend du middleware que vous utilisez (odbc, jdbc, ...)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

A ma connaissance les langages proposent d'abord des fonctions se basant
sur le nombre de caractère, décoléré de la représentation binaire. Et
les chaines sont traitées en interne avec un charset unicode ou dérivé.

Bonjour Monsieur

Pour la conversion automatique de ma base de données, j'ai utilisé un
script php "convert.php", dont voici les caractéristiques techniques :

- Connexion à la database en utf8, avec SET NAMES='utf8' ( ou sans le
signe égal je ne sais splus ;( ),

- Lectures des noms de tables ( qui sont d'abord toutes en latin1 ):
SHOW TABLES, et mise en variable indicée de ces noms de table,

- Compte tenu du fait qu'aucun des champs de ces tables n'ont de
liens externes ( je ne sais plus ce que c'est, genre FOREIGN qqchose, je
n'utilise jaamais cette fonctionnalité de MySQL ), pour chaque valeurs
$table de cette variable indicée :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8";

"COMMIT";

"ANALYZE TABLE " . $table;

Je prend le résultat et l'affiche sur la sortie par défaut 1 avec echo.

Donc, après avoir lancé ce script en cli ( serveur web Apache2 arrêté ):

php -q -f convert.php > 1>result.txt 2>result_err.txt

J'ai regardé le deuxième fichier : pas d'erreur.

Le premier fichier result.txt ne m'a indiqué que ces deux commentaires :

"OK" , ou

"This table is already up to date".

Donc, cette conversion de la database ( 43 tables MySQL ), n'a duré
qu'un demi-minute, est s'est faite correctement.

Il n'y a aucune différence pour les voyelles accentuées, à
l'affichage en utf8, entre les anciens enregistrements théoriquement
convertis, et ceux récents ( hier par exemple ), qui sont bien
enregistrés en utf8.

L'affichage est normal, tel que vous pouvez le constater dans les
listes de courses anciennes des dix derniers jours, accessibles à partir
du lien :

www.pronostics-courses.fr/php/courses_anciennes/old_courses.php

Il est vrai que 'ai fait cette conversion, je crois, le lundi 29
Avril au soir, mais vous pouvez très bien voir comment afficher ces
listes de courses plus anciennes que çà.

Merci de me dire, si cette instruction "ALTER TABLE CONVERT", a bien
converti le contenu des tables MySQL aussi bien que leurs déclarations.

Bien amicalement.

Jean François Ortolo

Vous avez filtré cet utilisateur ! Consultez son message

Le 07/05/2013 11:47, Pierre Goiffon a écrit :

Bonjour,

Le 19/04/2013 10:08, Jean Francois Ortolo a écrit :
Ceci, même si le contenu de ma base de données reste en mode latin1.

Convertir la database existante en mode utf8 ce serait un sacré
boulot.

Attention, ne pas confondre la manière dont est stocké le contenu dans
la base et la manière dont on le récupère ! On peut très bien avoir un
stockage iso latin-1 et récupérer en utf-8 par exemple...

Le stockage, c'est du côté de la collation qu'il faut regarder. Ca
inclus le stockage, mais aussi la comparaison et le tri (est-ce que c
est équivalent à ç ? é avant e ?), la prise en compte ou non de la casse.

L'application qui se connecte elle utilisera les propriétés de la
connexion. On pourra donc récupérer le contenu en utf-8 par exemple.
Là, tout dépend du middleware que vous utilisez (odbc, jdbc, ...)

Ce qui me gêne, c'est surtout les strlen et substr() de mes
scripts... ;)

A ma connaissance les langages proposent d'abord des fonctions se basant
sur le nombre de caractère, décoléré de la représentation binaire. Et
les chaines sont traitées en interne avec un charset unicode ou dérivé.

Bonjour Monsieur

Pour la conversion automatique de ma base de données, j'ai utilisé un
script php "convert.php", dont voici les caractéristiques techniques :

- Connexion à la database en utf8, avec SET NAMES='utf8' ( ou sans le
signe égal je ne sais splus ;( ),

- Lectures des noms de tables ( qui sont d'abord toutes en latin1 ):
SHOW TABLES, et mise en variable indicée de ces noms de table,

- Compte tenu du fait qu'aucun des champs de ces tables n'ont de
liens externes ( je ne sais plus ce que c'est, genre FOREIGN qqchose, je
n'utilise jaamais cette fonctionnalité de MySQL ), pour chaque valeurs
$table de cette variable indicée :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8";

"COMMIT";

"ANALYZE TABLE " . $table;

Je prend le résultat et l'affiche sur la sortie par défaut 1 avec echo.

Donc, après avoir lancé ce script en cli ( serveur web Apache2 arrêté ):

php -q -f convert.php > 1>result.txt 2>result_err.txt

J'ai regardé le deuxième fichier : pas d'erreur.

Le premier fichier result.txt ne m'a indiqué que ces deux commentaires :

"OK" , ou

"This table is already up to date".

Donc, cette conversion de la database ( 43 tables MySQL ), n'a duré
qu'un demi-minute, est s'est faite correctement.

Il n'y a aucune différence pour les voyelles accentuées, à
l'affichage en utf8, entre les anciens enregistrements théoriquement
convertis, et ceux récents ( hier par exemple ), qui sont bien
enregistrés en utf8.

L'affichage est normal, tel que vous pouvez le constater dans les
listes de courses anciennes des dix derniers jours, accessibles à partir
du lien :

www.pronostics-courses.fr/php/courses_anciennes/old_courses.php

Il est vrai que 'ai fait cette conversion, je crois, le lundi 29
Avril au soir, mais vous pouvez très bien voir comment afficher ces
listes de courses plus anciennes que çà.

Merci de me dire, si cette instruction "ALTER TABLE CONVERT", a bien
converti le contenu des tables MySQL aussi bien que leurs déclarations.

Bien amicalement.

Jean François Ortolo

Pierre Goiffon

07/05/2013 à 14:30

Le 07/05/2013 12:16, Jean Francois Ortolo a écrit :

Pour la conversion automatique de ma base de données, j'ai utilisé un
script php "convert.php", dont voici les caractéristiques techniques :

- Connexion à la database en utf8, avec SET NAMES='utf8' ( ou sans le
signe égal je ne sais splus ;( ),

- Lectures des noms de tables ( qui sont d'abord toutes en latin1 ):
SHOW TABLES, et mise en variable indicée de ces noms de table,

- Compte tenu du fait qu'aucun des champs de ces tables n'ont de
liens externes ( je ne sais plus ce que c'est, genre FOREIGN qqchose, je
n'utilise jaamais cette fonctionnalité de MySQL ), pour chaque valeurs
$table de cette variable indicée :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8";

Vous ne précisez pas la base de données utilisée et la version, je
suppose que c'est MySQL ?

Il faut considérer qu'une collation est applicable, sur quasiment tous
les sgbd, à :
- la base de données
- une table
- une colonne

Il faut donc convertir chacun des éléments concernés...

La commande passée n'a convertit que les tables. Cf la doc :
http://dev.mysql.com/doc/refman/5.5/en/charset-table.html

Pour la base :
http://dev.mysql.com/doc/refman/5.5/en/charset-database.html
Et les colonnes :
http://dev.mysql.com/doc/refman/5.5/en/charset-conversion.html

Il est théoriquement possible de tout faire en SQL en allant piocher les
infos sur les noms de tables et colonnes dans les infos de schema (base
information_schema).
Je suppose que quelqu'un a déjà du développer ça, je n'ai pas trouvé en
cherchant très rapidement mais je suis assez confiant que ça soit
quelque part (et ne pas oublier de regarder les commentaires de la doc
officielle, souvent très riches !)

Pierre Goiffon

07/05/2013 à 14:37

Le 07/05/2013 14:30, Pierre Goiffon a écrit :

Il faut considérer qu'une collation est applicable, sur quasiment tous
les sgbd, à :
- la base de données
- une table
- une colonne

Il faut donc convertir chacun des éléments concernés...

Pour MySQL, il reste aussi la possibilité de faire un dump, le modifier
dans un éditeur et ré-importer :)

Jean Francois Ortolo

07/05/2013 à 15:51

Le 07/05/2013 14:37, Pierre Goiffon a écrit :

Le 07/05/2013 14:30, Pierre Goiffon a écrit :
Il faut considérer qu'une collation est applicable, sur quasiment tous
les sgbd, à :
- la base de données
- une table
- une colonne

Il faut donc convertir chacun des éléments concernés...

Pour MySQL, il reste aussi la possibilité de faire un dump, le modifier
dans un éditeur et ré-importer :)

Rebonjour Monsieur

J'avais oublié d'indiquer, que j'avais spécifié la collation dans le
ALTER TABLE.

La base de données est bien MySQL, le serveur est un VPS d'OVH sous
Linux Debian Squeeze.

L'ordre réel MySQL était ( faut que je revoie le script ;) ) :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8 COLLATE
utf8_general_ci;"

J'ai vérifié avant dans toutes les tables MySQL, qu'aucune colonne ne
comportait de déclaration particulière impactant soit son collate, soit
son charset.

Je me suis fié quant à l'utilisation de cette instruction MySQL, au
MySQL Manual de la version 5.5 de MySQL, tel qu'il figure sur le web.

Théoriquement, dans ces conditions ( absence totale de déclarations
dans le colonnes des tables MySQL ) il me semble qu'il n'est pas
nécessaire de spécifier les charset et collate pour chaque colonne, et
que dans ce cas, le charset et le collate des tables, s'applique aussi
par défaut à chacune des colonnes ( ce qui semble être logique ).

Merci de m'avoir indiqué de manière implicite, que cette instruction
ALTER TABLE, a bien eu pour effet, de modifier le contenu des tables.

Bien amicalement.

Jean François Ortolo

P.S. Pour dump, il y a la commande Linux iconv :

iconv -f ISO8859-15 -t UTF-8 database.sql -o database_utf8.sql

Pierre Goiffon

07/05/2013 à 16:15

Le 07/05/2013 15:51, Jean Francois Ortolo a écrit :

Il faut considérer qu'une collation est applicable, sur quasiment tous
les sgbd, à :
- la base de données
- une table
- une colonne

Il faut donc convertir chacun des éléments concernés...

L'ordre réel MySQL était ( faut que je revoie le script ;) ) :

"ALTER TABLE " . $table . " CONVERT TO CHARACTER SET utf8 COLLATE
utf8_general_ci;"

J'ai vérifié avant dans toutes les tables MySQL, qu'aucune colonne ne
comportait de déclaration particulière impactant soit son collate, soit
son charset.

(...)

Théoriquement, dans ces conditions ( absence totale de déclarations
dans le colonnes des tables MySQL ) il me semble qu'il n'est pas
nécessaire de spécifier les charset et collate pour chaque colonne

En effet !
Par contre pensez à modifier la collation de la base (cf mon message
précédent : <5188f3e0$0$2105$)

P.S. Pour dump, il y a la commande Linux iconv :

iconv -f ISO8859-15 -t UTF-8 database.sql -o database_utf8.sql

Ma proposition était de faire un dump, de remplacer dedans les
collations présentes dans les ordres SQL, et de rejouer le dump.

Charset en HTML 5

10 réponses

Veuillez sélectionner un problème