Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Charset en HTML 5

33 views
Skip to first unread message

GR

unread,
Apr 18, 2013, 3:06:28 PM4/18/13
to
Bonjour,

Le charset pour HTML 5 est chang� pour l'Europe ?

"Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"

C'est un avertissement mais je n'aime pas �a !

Pas envie d'�crire ainsi écrire...

Des avis ?

Site : http://www.grenault.net
Cours photo : http://www.grenault.net/tech.htm
Home cin�ma : http://www.grenault.net/homecine.htm

Olivier Miakinen

unread,
Apr 18, 2013, 4:24:51 PM4/18/13
to
Bonjour,

Le 18/04/2013 21:06, GR a �crit :
>
> Le charset pour HTML 5 est chang� pour l'Europe ?

Au tout d�but de HTML, je crois que le charset par d�faut �tait
ISO-8859-1. Mais il a toujours �t� plus propre de d�clarer celui
qu'on utilise et ne pas se baser sur une valeur par d�faut.

> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"

Et de toute mani�re l'encodage propri�taire Windows-1252 n'a *jamais*
�t� un charset souhaitable.

> C'est un avertissement mais je n'aime pas �a !
>
> Pas envie d'�crire ainsi écrire...
>
> Des avis ?

Ben oui. Tu �cris � �crire � dans ton �diteur favori, et tu lui demandes
gentiment de sauver le r�sultat en UTF-8. Si en outre tu demandes tout
aussi gentiment � ton serveur web favori de d�clarer le charset UTF-8
dans les ent�tes HTTP, tout ira bien.

Si tu ne sais pas faire, voir ce groupe ou fciw.serveurs pour le serveur
web, fr.comp.applications.editeurs-de-texte pour l'�diteur de texte. Et
s'il s'av�re que ce dernier ne sait pas sauver en UTF-8 sans BOM, alors
jette-le aux orties et prends-en un autre.

Cordialement,
--
Olivier Miakinen

Jean Francois Ortolo

unread,
Apr 18, 2013, 5:16:29 PM4/18/13
to
Le 18/04/2013 21:06, GR a écrit :
> Bonjour,
>
> Le charset pour HTML 5 est changé pour l'Europe ?
>
> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"
>
> C'est un avertissement mais je n'aime pas ça !
>
> Pas envie d'écrire ainsi écrire...
>
> Des avis ?
>
> Site : http://www.grenault.net
> Cours photo : http://www.grenault.net/tech.htm
> Home cinéma : http://www.grenault.net/homecine.htm




Bonsoir Monsieur

Déjà que çà fait un moment qu'on attend PHP 6...

Les standards, les préférences, le code propriétaire, toussa...

La liberté d'entreprendre, le champ de la complexité à la Edgar Morin...

A quand les machines à programmer, voire concevoir des types de
conception Informatique de type condensatoire, avec optimisation des
ressources, de la vitesse d'exécution et des performances des programmes ?

Quelques petites babioles de standards difficiles ? à adopter.

Moi, j'ai fait un site en iso8859-1 théoriquement adapté de manière
semi-automatique à la norme PHP 6 par mes soins, avec un script en
Bourne Shell, et un script Awk ( Il y a quelques années ). Mais... C'est
en iso8859-1, alors j'espère que le moment venu, il y aura encore un
petit moyen de hack, pour que ces scripts en iso, fonctionnent sous PHP 6.

Par exemple, dans les .htaccess

Mais... S'il n'y a a pas moyen de faire autrement, j'aurai des
problèmes pour passer en UTF-8, cause mes strlen() et autres substr()...

Et puis... Faudrait encore que UTF-8 tienne la route, quand on saura
le langage des extra-terrestres, que nous ne manquerons pas de
rencontrer sur Mars. ;)

Bof... A chaque époque ses vicissitudes... ;)

Bien amicalement.

Jean François Ortolo





SAM

unread,
Apr 18, 2013, 9:03:58 PM4/18/13
to
Le 18/04/13 23:16, Jean Francois Ortolo a écrit :

> en iso8859-1, alors j'espère que le moment venu, il y aura encore un
> petit moyen de hack, pour que ces scripts en iso, fonctionnent sous PHP 6.
>
> Par exemple, dans les .htaccess

Ceux-là doivent certainement être en ascii, non ?

ce qui ne pose pas de blème si on a choisi de "coder" en européen de
l'ouest ou en fenestrel


> Mais... S'il n'y a a pas moyen de faire autrement, j'aurai des
> problèmes pour passer en UTF-8, cause mes strlen() et autres substr()...

Merci de ne pas postillonner !!!


Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
(tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
utf-8 et le sauvegardes ainsi, non ?)



Cordialement,
--
Stéphane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

Gérald Niel

unread,
Apr 19, 2013, 1:40:36 AM4/19/13
to
Le Jeudi 18 avril 2013 � 19:06 UTC, GR �crivait sur
fr.comp.infosystemes.www.auteurs :
> Pas envie d'�crire ainsi écrire...
>
> Des avis ?

Olivier ayant d�j� en partie r�pondu je ne vais pas le paraphraser.
Juste une pr�cision sur les entit�s HTML (sauf pour & et je crois
 ) ne sont utile que si le charset du document n'est pas d�clar�
ou ne correspond pas � l'encodage dans le quel le document a �t�
sauvegard�.
Il y a belle lurette que je ne me pr�occupe plus de �a�!

@+
--
On ne le dira jamais assez, l'anarchisme, c'est l'ordre sans le
gouvernement ; c'est la paix sans la violence. C'est le contraire
pr�cis�ment de tout ce qu'on lui reproche, soit par ignorance, soit
par mauvaise foi. -+- Hem Day -+-

Olivier Miakinen

unread,
Apr 19, 2013, 2:17:55 AM4/19/13
to
Le 19/04/2013 07:40, Gᅵrald Niel rᅵpondait ᅵ GR :
>
> Juste une prï¿œcision sur les entitï¿œs HTML (sauf pour & et je crois
>  ) ne sont utiles que [...]

J'ajouterai < (avec > si on aime la symï¿œtrie mais celui-ci n'est
pas indispensable), et ï¿œventuellement " ou ' dans une valeur
d'attribut dï¿œjï¿œ dï¿œlimitï¿œe respectivement par " ou '. En revanche  
n'est utile que pour que le dï¿œveloppeur sache au premier coup d'ï¿œil
distinguer qu'il a mis une espace insï¿œcable au lieu d'une espace simple
(ou alors c'est parce qu'il utilise l'ï¿œditeur de Firefox ou SeaMonkey
qui remplace l'espace insï¿œcable par une simple).

Jean Francois Ortolo

unread,
Apr 19, 2013, 4:08:25 AM4/19/13
to
Bonjour Monsieur

J'ai mis toutes mes lettres accentuées ( ascii étendu ) de mes textes
affichés, en mode lettre html, à part les noms des courses, que
théoriquement je peux convertir automatiquement à la volée avec
utf8encode ( ou bien iconv() ).

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.

Mais ce sera peut-être nécessaire à terme, si l'évolution actuelle se
poursuit.

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

Tout mon site est fait avec de scripts php, sauf quatre pages html.

Je croyais que strlen() et substr() étaient soit obsolètes en PHP 6,
soit inadaptés pour traiter de l'utf8, peut-être que je me trompe ?

Et puis, si ces instructions disparaissent, faudra que je trouve une
solution de rechange.

Tout çà me fait penser qu'il va falloir que je fasse déjà un audit
complet de mon site, pour voir si je ne fais pas l'ignoble, la
calamiteuse confusion entre une chaîne de caractères et une array, en
faisant pour les deux : $str[$i]

Interdit en PHP 6... ;)

Merci beaucoup pour vos encouragements à passer en utf8, c'est
l'avenir, mais pour combien de temps ?

GR

unread,
Apr 19, 2013, 4:25:10 AM4/19/13
to
Le 18/04/2013 22:24, Olivier Miakinen a écrit :
> Bonjour,
>
> Le 18/04/2013 21:06, GR a écrit :
>>
>> Le charset pour HTML 5 est changé pour l'Europe ?
>
> Au tout début de HTML, je crois que le charset par défaut était
> ISO-8859-1. Mais il a toujours été plus propre de déclarer celui
> qu'on utilise et ne pas se baser sur une valeur par défaut.
>
>> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"
>
> Et de toute manière l'encodage propriétaire Windows-1252 n'a *jamais*
> été un charset souhaitable.
>
>> C'est un avertissement mais je n'aime pas ça !
>>
>> Pas envie d'écrire ainsi écrire...
>>
>> Des avis ?
>
> Ben oui. Tu écris « écrire » dans ton éditeur favori, et tu lui demandes
> gentiment de sauver le résultat en UTF-8. Si en outre tu demandes tout
> aussi gentiment à ton serveur web favori de déclarer le charset UTF-8
> dans les entêtes HTTP, tout ira bien.
>
> Si tu ne sais pas faire, voir ce groupe ou fciw.serveurs pour le serveur
> web, fr.comp.applications.editeurs-de-texte pour l'éditeur de texte. Et
> s'il s'avère que ce dernier ne sait pas sauver en UTF-8 sans BOM, alors
> jette-le aux orties et prends-en un autre.
>
> Cordialement,
>

On s'est donc fait avoir, nous, les pauvres européens, on ne nous
accorde même pas un charset spécifique. C'est honteux ! Battons nous,
n'acceptons pas le dictat anglo-saxon !

De toute façon le HTML 5 n'est pas finalisé. Je reste donc en
windows-1252, non mais !

--
Home cinéma : http://www.grenault.net/homecine.htm

SAM

unread,
Apr 19, 2013, 8:34:21 AM4/19/13
to
Le 19/04/13 10:08, Jean Francois Ortolo a écrit :
> Le 19/04/2013 03:03, SAM a écrit :
>>
>> Ceci étant ... je ne vois pas le pourquoi du comment des blèmes
>> (tu prends et ouvres ton fichier en iso-truc tu lui dis que tu passes en
>> utf-8 et le sauvegardes ainsi, non ?)
>
> Ce qui me gêne, c'est surtout les strlen et substr() de mes
> scripts... ;)

Ha!? Oui!
Je n'avais pas fait gaffe que PHP est toujours aussi tortueux :-(
Que, possiblement, on ne peut lui expliquer une bonne fois qu'on est en
utf-8 de partout et qu'ainsi il pédale dans la semoule entre les octets
et les "caractères".

hop! :
$length = strlen(utf8_decode($s));
Yapuka faire un recherche/échange général sur tous les fichiers du site ;-)

re-hop! :
$new_string = mb_substr($string, $start, $end, 'UTF-8');
Là ça va être un poil + compliqué ...

> Merci beaucoup pour vos encouragements à passer en utf8, c'est
> l'avenir, mais pour combien de temps ?

Il parait surtout que c'est plus encombrant ...
Message has been deleted

Jean Francois Ortolo

unread,
Apr 19, 2013, 11:50:45 AM4/19/13
to
Bonjour Monsieur

J'ai fait mieux que çà.

J'ai programmé aujourd'hui, les fonctions suivantes :

_strrpos() , _strpos() , _strlen(), _strtolower, _strtoupper() ,
_substr(), _strstr(), etc...

En utilisant la même notation que les fonctions habituelles iso, mais
avec le _ au début.

Ces fonctions, sont des interfaces avec les fonctions correspondantes
de type : mb_*(), en fonction du charset, que j'ai mis dans une
constante : ENCODING, incluse dans un script : display_errors.php ,
ainsi que le scrtpt contenant ces fonctions : fonctions_utf8.php.

Il ne me reste plus, qu'à programmer la fonction _strtr(), compte
tenu du fait que la fonction mb_strtr() n'existe pas en PHP.

J'ai testé mes fonctions déjà faites, avec ENODING mis à : "ISO-8859-15".

Tout baigne dans l'huile.

le bug, ce sont les voyelles accentuées dans les scripts de mon site. ;)

Sur mon ordinateur, j'ai déjà ajouté le souligné ( _ ) au début de
toute ces fonctions.

Je vais probablement savoir si mon site marche en local, ce week-end.

Après, il faudra que je prenne des mesures pour résoudre le problème
des voyelles accentuées.

Ceci, pour pouvoir basculer d'un seul coup, de ISO-8859-15, à UTF-8.

Mais... IL y a toujours le problème de la database, également à
migrer. ;(

Je ne pourrai pas faire l'économie de scripts ad hoc, de
lecture/écriture/conversion de mes tables MySQL.

Olivier Miakinen

unread,
Apr 19, 2013, 12:07:15 PM4/19/13
to
Bonjour,

Le 19/04/2013 10:08, Jean Francois Ortolo a ï¿œcrit :
>
> J'ai mis toutes mes lettres accentuï¿œes ( ascii ï¿œtendu )

Je ne peux pas m'empᅵcher de rᅵagir ᅵ chaque fois que je lis ᅵ ascii
ᅵtendu ᅵ, tant cette expression est inutile et peu informative.

En effet, parmi les extensions d'ascii on trouve aussi bien MacRoman
(qui dᅵfinit un caractᅵre pomme croquᅵe ᅵ la position 240) que CP437
(avec tout un tas de caractï¿œres pour dessiner des cadres, et qui a
mᅵme des smileys aux positions 1 et 2), ISO-2022 (oᅵ les caractᅵres
ï¿œtendus sont du japonais), et UTF-8 (qui dï¿œfinit tout ï¿œa, sauf la
pomme croquï¿œe qui est dans la zone privï¿œe).

> de mes textes
> affichᅵs, en mode lettre html, ᅵ part les noms des courses, que
> thᅵoriquement je peux convertir automatiquement ᅵ la volᅵe avec
> utf8encode ( ou bien iconv() ).

Si tu peux les convertir avec utf8encode, c'est que tous ces caractï¿œres
appartiennent ᅵ ISO-8859-1.

> [...]
>
> Ce qui me gï¿œne, c'est surtout les strlen et substr() de mes scripts... ;)

http://fr2.php.net/mb_strlen
http://fr2.php.net/mb_substr


Cordialement,
--
Olivier Miakinen

GR

unread,
Apr 19, 2013, 12:47:45 PM4/19/13
to
Le 19/04/2013 17:23, Eric Demeester a ï¿œcrit :

>
> Et une bonne pratique est de systï¿œmatiquement indiquer le jeu de
> caractᅵres utilisᅵ dans les en-tᅵtes des pages HTML.
>

Le charset, c'est ï¿œa ?
Home cinï¿œma : http://www.grenault.net/homecine.htm

Otomatic

unread,
Apr 19, 2013, 1:04:21 PM4/19/13
to
Jean Francois Ortolo <ortolo.jeanfr...@free.fr.invalid>
écrivait :

> Mais... IL y a toujours le problème de la database, également à
> migrer. ;(
>
> Je ne pourrai pas faire l'économie de scripts ad hoc, de
> lecture/écriture/conversion de mes tables MySQL.

Bonjour,

Requête SQL sur chacune des tables :

ALTER TABLE `ma_table` CONVERT TO CHARSET utf8 COLLATE utf8_general_ci

ne transforme en codage utf-8 QUE ce qui est nécessaire.

Avec un très simple script PHP, pour 212 tables et un total de
32 785 215 enregistrements, c'est l'affaire de deux minutes.

Néanmoins, effectuer une sauvegarde de la base avant.

Nota : pour certaines tables, il peut être nécessaire d'avoir COLLATE
utf8_bin à la place de utf8_general_ci
--
Les gens que l'on considère comme des fous de travail sont, peut-être,
tout simplement entrain de s'amuser. Einstein
Message has been deleted

GR

unread,
Apr 20, 2013, 3:03:49 AM4/20/13
to
Le 19/04/2013 23:25, Eric Demeester a �crit :
> GR (Fri, 19 Apr 2013 18:47:45 +0200 -
> fr.comp.infosystemes.www.auteurs) :
>
>> Le 19/04/2013 17:23, Eric Demeester a �crit :
>>> Et une bonne pratique est de syst�matiquement indiquer le jeu de
>>> caract�res utilis� dans les en-t�tes des pages HTML.
>> Le charset, c'est �a ?
>
> Pile-poil. En HTML5 :
>
> <!DOCTYPE html>
> <html lang="fr">
> <head>
> <meta charset="utf-8" />
> ...
> </head>
>

Oui, je le pr�cise toujours m�me si ce n'est pas utf-8... Donc il ne
peut pas y avoir d'erreur d'interpr�tation.
Home cin�ma : http://www.grenault.net/homecine.htm

BertrandB

unread,
Apr 20, 2013, 3:26:48 AM4/20/13
to
Le 19/04/2013 14:34, SAM a �crit :

> Il parait surtout que c'est plus encombrant ...
pas tant que �a puisque seuls les caract�res sp�ciaux sont sur plusieurs
octets ..
en tout cas moins encombrant que des entit�s HTML

> Cordialement,
Tout autant

Otomatic

unread,
Apr 20, 2013, 3:40:53 AM4/20/13
to
GR <con...@guy-renault.com> écrivait :

> Oui, je le précise toujours même si ce n'est pas utf-8... Donc il ne
> peut pas y avoir d'erreur d'interprétation.
Mais si, il peut y avoir erreur d'interprétation.

Déclarer le charset utilisé dans une balise <meta... n'est pas
suffisant.
Il faut aussi être maître des entêtes envoyées par le serveur, celles-ci
étant prioritaires sur les balises html <meta...

Si le serveur envoie :
Content-Type: text/html; charset=iso-8859-1

vous aurez beau mettre une balise html
<meta charset="utf-8" />
c'est la déclaration du serveur qui prévaudra.
--
Ce n'est pas parce qu'ils sont nombreux à avoir tort
qu'ils ont forcément raison. Coluche

GR

unread,
Apr 20, 2013, 5:43:13 AM4/20/13
to
Le 20/04/2013 09:40, Otomatic a écrit :
> GR <con...@guy-renault.com> écrivait :
>
>> Oui, je le précise toujours même si ce n'est pas utf-8... Donc il ne
>> peut pas y avoir d'erreur d'interprétation.
> Mais si, il peut y avoir erreur d'interprétation.
>
> Déclarer le charset utilisé dans une balise <meta... n'est pas
> suffisant.
> Il faut aussi être maître des entêtes envoyées par le serveur, celles-ci
> étant prioritaires sur les balises html <meta...
>
> Si le serveur envoie :
> Content-Type: text/html; charset=iso-8859-1
>
> vous aurez beau mettre une balise html
> <meta charset="utf-8" />
> c'est la déclaration du serveur qui prévaudra.
>

Oui mais comment intervenir sur le serveur ?
Home cinéma : http://www.grenault.net/homecine.htm

Sergio

unread,
Apr 20, 2013, 5:51:01 AM4/20/13
to
Le Sat, 20 Apr 2013 11:43:13 +0200, GR 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)

> Oui mais comment intervenir sur le serveur ?

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

GR

unread,
Apr 20, 2013, 5:57:38 AM4/20/13
to
Le 20/04/2013 09:40, Otomatic a écrit :
> GR <con...@guy-renault.com> écrivait :
>
>> Oui, je le précise toujours même si ce n'est pas utf-8... Donc il ne
>> peut pas y avoir d'erreur d'interprétation.
> Mais si, il peut y avoir erreur d'interprétation.
>
> Déclarer le charset utilisé dans une balise <meta... n'est pas
> suffisant.
> Il faut aussi être maître des entêtes envoyées par le serveur, celles-ci
> étant prioritaires sur les balises html <meta...
>
> Si le serveur envoie :
> Content-Type: text/html; charset=iso-8859-1
>
> vous aurez beau mettre une balise html
> <meta charset="utf-8" />
> c'est la déclaration du serveur qui prévaudra.
>

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 !

La plupart de mes pages (très nombreuses) sont en HTML 4.01 Transitional
ou Strict ou en HTML 5 (pages récentes), toutes sans aucune erreur
détectée. Maintenant, s'il faut tout reprendre...
Home cinéma : http://www.grenault.net/homecine.htm

Otomatic

unread,
Apr 20, 2013, 1:22:23 PM4/20/13
to
GR <con...@guy-renault.com> é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

unread,
May 4, 2013, 5:17:46 PM5/4/13
to
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

unread,
May 7, 2013, 5:47:43 AM5/7/13
to
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

unread,
May 7, 2013, 5:52:54 AM5/7/13
to
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

unread,
May 7, 2013, 5:55:34 AM5/7/13
to
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

unread,
May 7, 2013, 6:16:11 AM5/7/13
to
Le 07/05/2013 11:47, Pierre Goiffon a �crit :
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

unread,
May 7, 2013, 8:30:25 AM5/7/13
to
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

unread,
May 7, 2013, 8:37:25 AM5/7/13
to
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

unread,
May 7, 2013, 9:51:44 AM5/7/13
to
Le 07/05/2013 14:37, Pierre Goiffon a �crit :
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

unread,
May 7, 2013, 10:15:42 AM5/7/13
to
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$426a...@news.free.fr>)

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

SAM

unread,
May 7, 2013, 7:37:12 PM5/7/13
to
Le 07/05/13 11:55, Pierre Goiffon a �crit :
> 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.

�a tend � se rar�fier mais ... je dois avouer que je rencontre encore
des pages pleines de [?]
tant l'emploi du latin-windows n'est pas "naturel" � mon environnement.


Cordialement,
--
St�phane Moriaux avec/with iMac-intel 27" & Mac OS X 10.6.8

SAM

unread,
May 7, 2013, 7:41:46 PM5/7/13
to
Le 07/05/13 11:52, Pierre Goiffon a �crit :
> 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 !

ja na rien comprendre l� dis donc !

n'est-ce point du b�te ascii � ce niveau ?
(ou, au plus fort du compliqu�, de l'iso-latin-1 dont on emploie ici
rien d'autre que sa partie commune avec l'ascii)

une fois lu ce meta il sera loisible ensuite de passer au d�codage
suivant la bonne table de cacact�res y sp�cifi�e, non ?


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

n'importe quoi !
paske le serveur ne pourrait pas se "tromper" ?

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

M'enfin !
on met le meta charset en d�but et puis hop!

En tous cas en local �a fonctionne parfaitement (forc�ment alors sans
en-t�te de serveur).

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

Ouaip !
"text/html" !!!

... et ...
dermerdenzizich !

>>> Oui mais comment intervenir sur le serveur ?
>>
>> Soit dans le .htaccess avec la directive "CharsetDefault", soit en
>> balan�ant le header adhoc en PHP.

Ha! Tu vois bien que le serveur peut alors envoyer une info erron�e !
(si on confie le truc � un humain (stagiaire ? ))
Message has been deleted

Olivier Miakinen

unread,
May 10, 2013, 6:28:56 AM5/10/13
to
Le 08/05/2013 23:39, Eric Demeester rᅵpondait ᅵ Pierre Goiffon :
>
>> >> 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.

L'exemple concret que j'avais pour ma part ï¿œtait Netscape 4 sur AIX,
mais cela date d'un paquet d'annï¿œes. D'ailleurs il n'y a pas que
Windows-1252 qu'il ne supportait pas, je crois qu'il ne s'en sortait
pas beaucoup mieux avec ISO-8859-15 ou UTF-8. Sans parler des CSS !

> Des exemples concrets, j'en ai eu ᅵ la pelle, de moins en moins ᅵ
> prï¿œsent, pour ï¿œtre honnï¿œte.
>
> Mes explications, qui valent ce qu'elles valent, ᅵ savoir pas
> grand-chose, sont que :
>
> - le cp-1252 de Windows ï¿œtant trï¿œs proche d'ISO-8859-1(5), globalement,
> ï¿œa passe, sauf pour une petite poignï¿œe de caractï¿œres spï¿œcifiques ;

Oui.

> - cet encodage pourri ᅵtant massivement utilisᅵ pour cause de
> suprï¿œmatie ï¿œcrasante de Ms-Windows comme OS, le reste du monde, plutï¿œt
> que de se battre contre un moulin ᅵ vent, a intᅵgrᅵ ses
> particularitï¿œs ;

Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
en pratique, le Windows-1252 ne risque plus guᅵre d'ᅵtre mal gᅵrᅵ,
pourvu qu'il soit correctement dᅵclarᅵ. Pire que ᅵa, cela fonctionne
aussi assez souvent quand il est incorrectement dᅵclarᅵ comme de
l'ISO-8859-1, voire pas dᅵclarᅵ du tout. :-(

En revanche, ta remarque ᅵ propos de la suprᅵmatie ᅵcrasante d'un
OS propriï¿œtaire est pertinente aussi, et c'est que qui me fait pour
ma part rejeter le Windows-1252 comme un encodage pourri. Ce n'est
donc pas pour des raisons pratiques que je le dï¿œconseille, mais pour
des raisons philosophiques. Et qu'on ne vienne pas me dire que ce
sont de mauvaises raisons !

> - on ï¿œradique le problï¿œme en remplaï¿œant les caractï¿œres potentiellement
> nuisibles par ceux normalisï¿œs, genre &nbsp; pour les espaces
> insï¿œcables.

En l'occurrence, l'espace insï¿œcable est un mauvais exemple : elle fait
partie de ISO-8859-1, ISO-8859-15 et UTF-8 aussi bien que de Win-1252,
et ᅵ la mᅵme position. Mais il se trouve que l'ᅵditeur de texte intᅵgrᅵ
dans les logiciels tels que Firefox la remplace par une espace simple,
ce qui peut ï¿œtre une raison de l'ï¿œviter... seulement ce n'est en rien
la faute de Microsoft.

>> Est-ce que vous auriez plus de dï¿œtails Eric ?
>
> Au delᅵ ce ce que j'ᅵvoquais ci-dessus, non.

Pas mieux.

Cordialement,
--
Olivier Miakinen

Pierre Goiffon

unread,
May 10, 2013, 10:54:40 AM5/10/13
to
Le 08/05/2013 01:41, SAM a �crit :
>> Pour lire la balise meta, il faut savoir lire le flux html, et pour lire
>> ce dernier il faut connaitre son charset !
>
> ja na rien comprendre l� dis donc !
>
> n'est-ce point du b�te ascii � ce niveau ?

C'est ce que je disais plus bas :

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

> on met le meta charset en d�but et puis hop!

Ca enl�verai un peu de complexit�, mais �a reste costaud � g�rer !
En gros, s'appuyer uniquement sur le content-type text/html pour lire le
flux, �a serait comme de r�cup�rer un flux de type simplement image au
lieu de image/jpg ou image/png : avec un contenu texte sans charset, il
faut deviner comment lire ce que l'on re�oit.

> Ha! Tu vois bien que le serveur peut alors envoyer une info erron�e !

Je n'ai jamais dit l'inverse !

Pierre Goiffon

unread,
May 10, 2013, 11:02:38 AM5/10/13
to
Le 10/05/2013 12:28, Olivier Miakinen a �crit :
>> - cet encodage pourri �tant massivement utilis� pour cause de
>> supr�matie �crasante de Ms-Windows comme OS, le reste du monde, plut�t
>> que de se battre contre un moulin � vent, a int�gr� ses
>> particularit�s ;
>
> Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
> en pratique, le Windows-1252 ne risque plus gu�re d'�tre mal g�r�,
> pourvu qu'il soit correctement d�clar�.

Ca me semble extr�mement discutable, �a serait oublier l'histoire de ISO
Latin-9, qui est arriv� tr�s, tr�s, tr�s (...) en retard. En 2001 de mon
exp�rience ISO Latin-9 n'�tait support�/impl�ment� quasiment nulle part
alors que Windows-1252 dans quasiment tous les outils que j'utilisais
(Windows en poste et serveur, Linux en serveur).

> Pire que �a, cela fonctionne
> aussi assez souvent quand il est incorrectement d�clar� comme de
> l'ISO-8859-1, voire pas d�clar� du tout. :-(

En effet, beaucoup de navigateurs ont int�gr� ce fallback d�s qu'ils
d�tectent un caract�re des plages 80..9F

>> - on �radique le probl�me en rempla�ant les caract�res potentiellement
>> nuisibles par ceux normalis�s, genre &nbsp; pour les espaces
>> ins�cables.
>
> En l'occurrence, l'espace ins�cable est un mauvais exemple

Merci de la correction :)

Pierre Goiffon

unread,
May 10, 2013, 11:03:52 AM5/10/13
to
Le 08/05/2013 01:37, SAM a �crit :
>>> 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.
>
> �a tend � se rar�fier mais ... je dois avouer que je rencontre encore
> des pages pleines de [?]
> tant l'emploi du latin-windows n'est pas "naturel" � mon environnement.

Je suis preneur d'une URL o� tu reproduirai le prb...
Avec quel navigateur l'as-tu constat� ?

Olivier Miakinen

unread,
May 10, 2013, 11:20:14 AM5/10/13
to
Le 10/05/2013 17:02, Pierre Goiffon m'a rï¿œpondu :
> >
> > Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
> > en pratique, le Windows-1252 ne risque plus guᅵre d'ᅵtre mal gᅵrᅵ,
> > pourvu qu'il soit correctement dᅵclarᅵ.
>
> Ca me semble extrï¿œmement discutable,

Ah ?

> ï¿œa serait oublier l'histoire de ISO
> Latin-9, qui est arrivᅵ trᅵs, trᅵs, trᅵs (...) en retard. En 2001 de mon
> expᅵrience ISO Latin-9 n'ᅵtait supportᅵ/implᅵmentᅵ quasiment nulle part
> alors que Windows-1252 dans quasiment tous les outils que j'utilisais
> (Windows en poste et serveur, Linux en serveur).

C'est bien ce que je voulais dire. Je suppose que tu n'avais pas
compris ᅵ cause de mon style ampoulᅵ et de mon goᅵt des doubles
nᅵgations ᅵ plus guᅵre / mal gᅵrᅵ ᅵ. ;-)

--
Olivier Miakinen

SAM

unread,
May 10, 2013, 7:50:10 PM5/10/13
to
Le 10/05/13 17:03, Pierre Goiffon a �crit :
en g�n�ral ce sont plut�t de vieux articles ou posts de forum web

Je ne les ais pas archiv�s
et n'ai pas cherch� � savoir en quel encodage �a avait �t� �crit ou servi.

> Avec quel navigateur l'as-tu constat� ?

Usuellement j'utilise Firefox

Pierre Goiffon

unread,
May 13, 2013, 9:03:22 AM5/13/13
to
Le 11/05/2013 01:50, SAM a �crit :
>>> �a tend � se rar�fier mais ... je dois avouer que je rencontre encore
>>> des pages pleines de [?]
>>> tant l'emploi du latin-windows n'est pas "naturel" � mon environnement.
>>
>> Je suis preneur d'une URL o� tu reproduirai le prb...
>
> en g�n�ral ce sont plut�t de vieux articles ou posts de forum web
>
> Je ne les ais pas archiv�s
> et n'ai pas cherch� � savoir en quel encodage �a avait �t� �crit ou servi.

Ok...
A l'occasion, n'h�site pas � en parler ici si tu retombe sur un prb
identique !

Pierre Goiffon

unread,
May 13, 2013, 9:05:49 AM5/13/13
to
Le 10/05/2013 17:20, Olivier Miakinen a �crit :
>> �a serait oublier l'histoire de ISO
>> Latin-9, qui est arriv� tr�s, tr�s, tr�s (...) en retard. En 2001 de mon
>> exp�rience ISO Latin-9 n'�tait support�/impl�ment� quasiment nulle part
>> alors que Windows-1252 dans quasiment tous les outils que j'utilisais
>> (Windows en poste et serveur, Linux en serveur).
>
> C'est bien ce que je voulais dire. Je suppose que tu n'avais pas
> compris � cause de mon style ampoul� et de mon go�t des doubles
> n�gations � plus gu�re / mal g�r� �. ;-)

Ha d�sol�
J'ai relu ton message mais toujours pas compris la m�me chose :D
Bon enfin pas grave

0 new messages