Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Charset en HTML 5
77 views
Skip to first unread message
GR
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
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
Apr 18, 2013, 4:24:51 PM4/18/13
to
Bonjour,
Le 18/04/2013 21:06, GR a �crit :
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
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
> Le charset pour HTML 5 est chang� pour l'Europe ?
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"
�t� un charset souhaitable.
> C'est un avertissement mais je n'aime pas �a !
>
> Pas envie d'�crire ainsi écrire...
>
> Des avis ?
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
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 ?
> Bonjour,
>
>
> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"
>
> C'est un avertissement mais je n'aime pas ça !
> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"
>
>
> Pas envie d'écrire ainsi écrire...
> 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
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
> 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
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()...
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
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 :
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 -+-
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.
>
> Des avis ?
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
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).
>
> 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
Apr 19, 2013, 4:08:25 AM4/19/13
to
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
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 :
> Bonjour,
>
>>
>> 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*
>> "Warning: Legacy encoding windows-1252 used. Documents should use UTF-8"
>
> été un charset souhaitable.
>
>> C'est un avertissement mais je n'aime pas ça !
>>
>> Pas envie d'écrire ainsi écrire...
>> C'est un avertissement mais je n'aime pas ça !
>>
>>
>> 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
> Si tu ne sais pas faire, voir ce groupe ou fciw.serveurs pour le serveur
> 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
>
> Cordialement,
>
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
Apr 19, 2013, 8:34:21 AM4/19/13
to
Le 19/04/13 10:08, Jean Francois Ortolo a écrit :
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 ...
> 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 ?)
>
>>
>> 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!
> scripts... ;)
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 ?
Message has been deleted
Jean Francois Ortolo
Apr 19, 2013, 11:50:45 AM4/19/13
to
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
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
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
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
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
>
> 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
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
é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.
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
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
> 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
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
> Il parait surtout que c'est plus encombrant ...
octets ..
en tout cas moins encombrant que des entit�s HTML
> Cordialement,
Tout autant
Otomatic
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
> 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
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 ?
> 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.
>
Home cinéma : http://www.grenault.net/homecine.htm
Sergio
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)
>> 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 ?
balançant le header adhoc en PHP.
GR
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
>
>> 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.
>
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
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 !
> 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 !
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
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 :
� / � 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 !
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
> <!DOCTYPE html>
> <html lang="fr">
> <head>
> <meta charset="utf-8" />
> ...
> </head>
� / � 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
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�.
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
May 7, 2013, 5:52:54 AM5/7/13
to
Le 20/04/2013 11:51, Sergio a �crit :
>
> (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 !
>>> 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
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
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
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
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
May 7, 2013, 8:30:25 AM5/7/13
to
Le 07/05/2013 12:16, Jean Francois Ortolo a �crit :
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 !)
> 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
> 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";
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
May 7, 2013, 8:37:25 AM5/7/13
to
Le 07/05/2013 14:30, Pierre Goiffon a �crit :
dans un �diteur et r�-importer :)
> 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
> les sgbd, � :
> - la base de donn�es
> - une table
> - une colonne
>
> Il faut donc convertir chacun des �l�ments concern�s...
dans un �diteur et r�-importer :)
Jean Francois Ortolo
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
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
iconv -f ISO8859-15 -t UTF-8 database.sql -o database_utf8.sql
Pierre Goiffon
May 7, 2013, 10:15:42 AM5/7/13
to
Le 07/05/2013 15:51, Jean Francois Ortolo a �crit :
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.
>>> 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...
>
>>> 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.
(...)
>
> "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 !
> 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
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
collations pr�sentes dans les ordres SQL, et de rejouer le dump.
SAM
May 7, 2013, 7:37:12 PM5/7/13
to
Le 07/05/13 11:55, Pierre Goiffon a �crit :
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
> 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
>>> 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.
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
May 7, 2013, 7:41:46 PM5/7/13
to
Le 07/05/13 11:52, Pierre Goiffon a �crit :
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 ? ))
> 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 !
>>>> 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 !
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 !
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).
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.
"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.
(si on confie le truc � un humain (stagiaire ? ))
Message has been deleted
Olivier Miakinen
May 10, 2013, 6:28:56 AM5/10/13
to
Le 08/05/2013 23:39, Eric Demeester rￜpondait ￜ Pierre Goiffon :
>> > 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 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
>
>> >> Je reste donc en windows-1252, non mais !
>> > C'est une _trￜs_ mauvaise idￜe, car ce jeu de caractￜres, spￜcifique ￜ
>> >> Je reste donc en windows-1252, non mais !
>> > 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 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
May 10, 2013, 10:54:40 AM5/10/13
to
Le 08/05/2013 01:41, SAM a �crit :
>> 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).
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 !
>> 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 :
>> ce dernier il faut connaitre son charset !
>
> ja na rien comprendre l� dis donc !
>
> n'est-ce point du b�te ascii � ce niveau ?
>> 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 !
Pierre Goiffon
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 ;
> 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 pour les espaces
>> ins�cables.
>
> En l'occurrence, l'espace ins�cable est un mauvais exemple
Merci de la correction :)
>> - 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�,
> Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
> 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 pour les espaces
>> ins�cables.
>
> En l'occurrence, l'espace ins�cable est un mauvais exemple
Merci de la correction :)
Pierre Goiffon
May 10, 2013, 11:03:52 AM5/10/13
to
Le 08/05/2013 01:37, SAM a �crit :
Avec quel navigateur l'as-tu constat� ?
>>> 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...
>>> 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.
Avec quel navigateur l'as-tu constat� ?
Olivier Miakinen
May 10, 2013, 11:20:14 AM5/10/13
to
Le 10/05/2013 17:02, Pierre Goiffon m'a rï¿œpondu :
>
> 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
compris ￜ cause de mon style ampoulￜ et de mon goￜt des doubles
nￜgations ￜ plus guￜre / mal gￜrￜ ￜ. ;-)
--
Olivier Miakinen
> >
> > Oui, et c'est ce qui fait que la remarque de Pierre est pertinente :
> > 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
> (Windows en poste et serveur, Linux en serveur).
compris ￜ cause de mon style ampoulￜ et de mon goￜt des doubles
nￜgations ￜ plus guￜre / mal gￜrￜ ￜ. ;-)
--
Olivier Miakinen
SAM
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
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� ?
Pierre Goiffon
May 13, 2013, 9:03:22 AM5/13/13
to
Le 11/05/2013 01:50, SAM a �crit :
A l'occasion, n'h�site pas � en parler ici si tu retombe sur un prb
identique !
>>> �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...
>>> 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.
A l'occasion, n'h�site pas � en parler ici si tu retombe sur un prb
identique !
Pierre Goiffon
May 13, 2013, 9:05:49 AM5/13/13
to
Le 10/05/2013 17:20, Olivier Miakinen a �crit :
> 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
>> �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
>> Latin-9, qui est arriv� tr�s, tr�s, tr�s (...) en retard. En 2001 de mon
>> 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
>> (Windows en poste et serveur, Linux en serveur).
>
> C'est bien ce que je voulais dire. Je suppose que tu n'avais pas
> 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