mysql et php : connexion en panne
Bernd
Je m'adresse à vous même si je sens bien que c'est OT car les news sur
mysql et php ne courent pas les rues.
Je débute dans ce domaine et souhaite faire une table linterrogeable et
formatable ensuite avec php et html.
J'ai pris un exemple en php sur le web qui permet d'interroger la base.
Celle-ci existe et fonctionne bien avec phpmyadmin en local et sur le
serveur Free.
Je suis donc chez Free et quand je lance le script, il ne se passe rien
- écran vide sans même un message d'erreur. Et voilà 3 jours que
j'essaye par tous les moyens... donc, maintenant je m'adresse à vous en
espérant un déblocage.
Voilà le script php mêlé à un peu de html :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>TableEssai</title>
</head>
<body>
<h2>Hello - ma 1re base</h2>
<?php
// on se connecte à MySQL
$db = mysql_connect('sql.free.fr', 'monlogin', 'monpass');
// on sélectionne la base
mysql_select_db(`monlogin`,$db);
// on crée la requête SQL
$sql = `SELECT nom,prenom,statut,date FROM famille`;
// on envoie la requête
$req = mysql_query($sql) or die(`Erreur SQL
!<br>`.$sql.`<br>`.mysql_error());
// on fait une boucle qui va faire un tour pour chaque enregistrement
while($data = mysql_fetch_assoc($req))
{
// on affiche les informations de l`enregistrement en cours
echo `<b>`.$data[`nom`].` `.$data[`prenom`].`</b>
(`.$data[`statut`].`)`;
echo ` <i>date de naissance : `.$data[`date`].`</i><br>`;
}
// on ferme la connexion à mysql
mysql_close();
?>
</body>
</html>
Et voilà - j'obtiens sans cesse comme je disais, juste "Hello - ma 1re
base" - puis du vide... j'ai même fait toutes les combinaisons
possibles.
Par avance merci.
--
A+
Romer
ASM
> J'ai pris un exemple en php sur le web qui permet d'interroger la base.
> Celle-ci existe et fonctionne bien avec phpmyadmin en local et sur le
> serveur Free.
Est-ce que tu as fait un copié-collé de ton code ici ?
Si oui, pourquoi n'a t-on pas toujours des ' et que des ` y sont
employés à la place ?
Sinon t'as t'y essayé en html "normal" ?
> <?php
> // on se connecte à MySQL
> $db = mysql_connect('sql.free.fr', 'monlogin', 'monpass');
>
> // on sélectionne la base
> mysql_select_db(`monlogin`,$db);
et voilà! ça commence dès cette ligne ...
--
Stephane Moriaux et son (moins) vieux Mac déjà dépassé
Bernd
> Est-ce que tu as fait un copié-collé de ton code ici ?
> Si oui, pourquoi n'a t-on pas toujours des ' et que des ` y sont
> employés à la place ?
Comme je pensais que ça venait de là, j'ai transformé les ' initiaux en
`. Mais ni les uns ni les autres ne fonctionnent.
>
> Sinon t'as t'y essayé en html "normal" ?
Là je ne comprends pas bien...
> > <?php
> > // on se connecte à MySQL
> > $db = mysql_connect('sql.free.fr', 'monlogin', 'monpass');
> >
> > // on sélectionne la base
> > mysql_select_db(`monlogin`,$db);
>
> et voilà! ça commence dès cette ligne ...
Tu veux dire que je place cela en tout début et le html ensuite ?
Je crois que oui vu que j'ai tout essayé, me semble-t-il.
Mais je veux bien recommencer tant ce dysfonctionnement m'agace et qu'en
plus, il faudrait que ça marche.
Je parts au travail et ne peux continuer la discussion.
A ce soir et merci de vos réponses.
--
A+
Romer
Bernd
> > > <?php
> > > // on se connecte à MySQL
> > > $db = mysql_connect('sql.free.fr', 'monlogin', 'monpass');
> > >
> > > // on sélectionne la base
> > > mysql_select_db(`monlogin`,$db);
> >
> > et voilà! ça commence dès cette ligne ...
J'ai régularisé toutes les ' et ai fait le code que tu m'indiques.
Idem - écran blanc.
J'en viens à me demander si Free permet cela ? mais comme phphmyadmin
lit toutes les tables que j'ai faites, j'en doute.
De plus cela ne fonctionne pas en local non plus alors que phpmyadmin et
Eskuel fonctionnent bien.
Je suis dans le noir complet.
A+
Romer
Mihamina Rakotomandimby (R12y)
> Je m'adresse à vous même si je sens bien que c'est OT car les news sur
> mysql et php ne courent pas les rues.
fr.comp.lang.php (modéré)
fr.comp.applications.sgbd
ASM
>> ASM <stephanemor...@wanadoo.fr.invalid> wrote:
>
>>>> <?php
>>>> // on se connecte à MySQL
>>>> $db = mysql_connect('sql.free.fr', 'monlogin', 'monpass');
là tu devrais essayer :
$db = mysql_connect('localhost', 'monlogin', 'monpass');
en remplaçant monlogin et monpass par ce qui va bien
>>>> // on sélectionne la base
>>>> mysql_select_db(`monlogin`,$db);
Tu es sûr que ta base s'appelle tonlogin ?
Je crois que ceci fonctionne sur mon espace free :
$Host='localhost';
$User='romer'; // complérer-modifier
$Password='......'; // complérer-modifier
if (!($lien=mysql_connect($Host,$User,$Password)))
{ echo 'Problème de connexion au serveur MySQL';
echo mysql_error($lien); exit;}
$identbase='reservation'; // complérer-modifier
if (!mysql_select_db($identbase,$lien))
{ echo 'Problème de connexion à la base : '.$identbase;
echo mysql_error($lien); exit; }
et au moins si erreur(s) on devrait en être averti
> J'ai régularisé toutes les ' et ai fait le code que tu m'indiques.
je n'ai indiqué aucun code, juste dit qu'il fallait employer '
(ou " suivant le cas ou son humeur)
> Idem - écran blanc.
> J'en viens à me demander si Free permet cela ? mais comme phphmyadmin
> lit toutes les tables que j'ai faites, j'en doute.
Reste à savoir si tu as activée ta base chez Free
et ... si tu l'as nourrie ?
> De plus cela ne fonctionne pas en local non plus alors que phpmyadmin et
> Eskuel fonctionnent bien.
je ne vois pas comment ça pourrait fonctionner en local
avec le code d'appel à la base à la mode 'free' ... ? !
kurtz le pirate
ASM <stephanemor...@wanadoo.fr.invalid> wrote:
> Bernd a écrit :
> > J'ai pris un exemple en php sur le web qui permet d'interroger la base.
> > Celle-ci existe et fonctionne bien avec phpmyadmin en local et sur le
> > serveur Free.
>
> Est-ce que tu as fait un copié-collé de ton code ici ?
> Si oui, pourquoi n'a t-on pas toujours des ' et que des ` y sont
> employés à la place ?
moi, j'utilise des double-quotes et je n'ai jamais de problème.
le code basique ressemble à ça :
<?php
$db_host = "localhost";
$db_user = "mon_login";
$db_pwd = "mon_password";
$db_name = "ma_base";
mysql_connect($db_host, $db_user, $db_pwd) or die('-- Erreur de
connexion --');
mysql_select_db($db_name) or die('-- Base inexistante --');
?>
--
klp
Bernd
> Je crois que ceci fonctionne sur mon espace free :
>
> $Host='localhost';
> $User='romer'; // complérer-modifier
> $Password='......'; // complérer-modifier
> if (!($lien=mysql_connect($Host,$User,$Password)))
> { echo 'Problème de connexion au serveur MySQL';
> echo mysql_error($lien); exit;}
>
> $identbase='reservation'; // complérer-modifier
> if (!mysql_select_db($identbase,$lien))
> { echo 'Problème de connexion à la base : '.$identbase;
> echo mysql_error($lien); exit; }
>
>
> et au moins si erreur(s) on devrait en être averti
Je viens de faire ce que tu préconises : je le poste pour éviter la
moindre erreur.
<html>
<head>
<title>BaseEssai</title>
</head>
<body>
<h2>Hello - ma 1re base</h2>
<?php
$Host='sql.free.fr';
$User='monlogin'; // complérer-modifier
$Password='monpass'; // complérer-modifier
if (!($lien=mysql_connect($Host,$User,$Password)))
{ echo 'Problème de connexion au serveur MySQL';
echo mysql_error($lien); exit;}
$identbase='login'; // complérer-modifier
if (!mysql_select_db($identbase,$lien))
{ echo 'Problème de connexion à la base : '.$identbase;
echo mysql_error($lien); exit; }
?>
</body>
</html>
voilà maintenant le prompt obtenu - je teste en local sur avec MAMP (qui
fonctionne bien) et en distant sur le site de Free.
Parse error: syntax error, unexpected T_VARIABLE in
/Applications/MAMP/htdocs/famille1.php on line 1
--
A+
Romer
Bernd
> moi, j'utilise des double-quotes et je n'ai jamais de problème.
>
> le code basique ressemble à ça :
> <?php
> $db_host = "localhost";
> $db_user = "mon_login";
> $db_pwd = "mon_password";
> $db_name = "ma_base";
> mysql_connect($db_host, $db_user, $db_pwd) or die('-- Erreur de
> connexion --');
> mysql_select_db($db_name) or die('-- Base inexistante --');
> ?>
Même avec les double-quotes, le résultat est hélas le même.
C'est bien la 1re fois que je galère autant pour faire fonctionner 8
lignes de code !
--
A+
Romer
Bernd
Merci - une chance que mon FAI les diffuse.
--
A+
Romer
Bernd
> là tu devrais essayer :
>
> $db = mysql_connect('localhost', 'monlogin', 'monpass');
>
> en remplaçant monlogin et monpass par ce qui va bien
Bien entendu j'ai mis mon login et le vrai passw.
> >>>> // on sélectionne la base
> >>>> mysql_select_db(`monlogin`,$db);
>
> Tu es sûr que ta base s'appelle tonlogin ?
Oui chez Free on ne peut ouvrir qu'une seule base et son nom est
automatiquement le même que le login.
> Je crois que ceci fonctionne sur mon espace free :
>
> $Host='localhost';
> $User='romer'; // complérer-modifier
> $Password='......'; // complérer-modifier
> if (!($lien=mysql_connect($Host,$User,$Password)))
> { echo 'Problème de connexion au serveur MySQL';
> echo mysql_error($lien); exit;}
>
> $identbase='reservation'; // complérer-modifier
> if (!mysql_select_db($identbase,$lien))
> { echo 'Problème de connexion à la base : '.$identbase;
> echo mysql_error($lien); exit; }
Je vais essayer cela demain.
> et au moins si erreur(s) on devrait en être averti
En effet, je n'ai pas même un moindre messsage d'erreur !
> Reste à savoir si tu as activée ta base chez Free
> et ... si tu l'as nourrie ?
Elle est activée - j'ai vérifié - et comme les tables fonctionnent avec
phpmyadmin et Eskuel c'est bien qu'elles existent et qu'elles sont
opérationnelles.
> > De plus cela ne fonctionne pas en local non plus alors que phpmyadmin et
> > Eskuel fonctionnent bien.
>
> je ne vois pas comment ça pourrait fonctionner en local
> avec le code d'appel à la base à la mode 'free' ... ? !
Je me suis exprimé un peu vite - en local, je change bien sûr les
paramètres : localhost, autrelogin, autre mdp.
C'est un mystère... et pourtant je sens que la solution n'est pas loin
mais je ne la vois pas.
Je viens d'acheter un bouquin de +400p chez Eyrolles ("mysql et php") et
les exemples fournis ne marchent pas non plus.
--
A+
Romer
ASM
>
> Même avec les double-quotes, le résultat est hélas le même.
>
> C'est bien la 1re fois que je galère autant pour faire fonctionner 8
> lignes de code !
C'est à dire que si tu t'évertues à te brancher à sql.free.fr
alors que perso il me semble que c'est localhost
qu'il faut mettre ... ça va pas le faire ...
J'ai été infoutu de retrouver sur Free les indications pour se connecter
à sa base MySql ... :-(
D'où c'est-y qu'ils l'ont caché ?
Bernd
> > C'est bien la 1re fois que je galère autant pour faire fonctionner 8
> > lignes de code !
>
> C'est à dire que si tu t'évertues à te brancher à sql.free.fr
> alors que perso il me semble que c'est localhost
> qu'il faut mettre ... ça va pas le faire ...
Si, si - j'ai fait l'essai - le résultat est le même - je l'ai signalé.
> J'ai été infoutu de retrouver sur Free les indications pour se connecter
> à sa base MySql ... :-(
M'étonne pas de Free ;-)
--
A+
Romer
Olivier Miakinen
>
> Parse error: syntax error, unexpected T_VARIABLE in
> /Applications/MAMP/htdocs/famille1.php on line 1
En ligne 1 ? Tu n'aurais pas oublié par hasard de nous recopier ta
ligne numéro 1 qui commencerait (également par hasard) par « <?xml » ?
Tu n'aurais pas les short tags activés ? Tu n'aurais pas pu poser ta
question sur le groupe fr.comp.lang.php ?
Bernd
> > Parse error: syntax error, unexpected T_VARIABLE in
> > /Applications/MAMP/htdocs/famille1.php on line 1
>
> En ligne 1 ? Tu n'aurais pas oublié par hasard de nous recopier ta
> ligne numéro 1 qui commencerait (également par hasard) par « <?xml » ?
Non - elle ne commence pas par cela.
> Tu n'aurais pas les short tags activés ?
Je ne pense pas
>Tu n'aurais pas pu poser ta
> question sur le groupe fr.comp.lang.php ?
Connaissais-pas à l'époque. Mais le post est ancien et la question est
résolue.
Merci tout de même.
--
A+
Romer
Olivier Miakinen
>
> le post est ancien et la question est résolue.
Désolé, j'ai dû louper l'article où tu le disais.
Cordialement,
--
Olivier Miakinen
Bernd
> Désolé, j'ai dû louper l'article où tu le disais.
Pas grave - dans la foultitude de news et des messages, on peut
facilement en sauter.
Pour rebondir sur la question que j'ai laissée en suspend, un autre
dysfonctionnement grave survient : les accents. Sans accents ou avec des
glyphes étranges à leur place, un document est totalement imprésentable
même à un public des plus laxixtes sur la question.
J'ai fait attention de tout paramétrer en utf8 depuis la saisie jusqu'à
la présentation du navigateur, rien n'y fait. Ils sont omniprésents et
tous les efforts d'avoir fait une table et une interrogation par php
sont réduits à néant.
Pourquoi cela est -il si aléatoire ? les accents se trouvent à leur
place dans le texte en sql, phpmyadmin les respecte et dès que je passe
à l'exploitation via php, ils sont tous là comme pour narguer.
J'ai lu des tas de trucs assez imbitables sur la question... je ne vois
guère de solution.
En sql, j'ai cela :
INSERT INTO `QSJ` (`ID`, `No`, `Titre`) VALUES (3, 1163, 'Algèbre
élémentaire');
Dès que j'importe dans phpmyadmin, ça va encore, mais sur le web ils
reviennent tous. Décourageant.
--
A+
Romer
ASM
>
> et une interrogation par php
> sont réduits à néant.
de ce que je connais du php et de ce que j'y ai compris ...
le php ne cause pas l'utf-8 ...
(par défaut :iso-8859-1 crois-je)
> J'ai lu des tas de trucs assez imbitables sur la question... je ne vois
> guère de solution.
>
> En sql, j'ai cela :
> INSERT INTO `QSJ` (`ID`, `No`, `Titre`) VALUES (3, 1163, 'Algèbre
> élémentaire');
Toujours ces drôles de '
> Dès que j'importe dans phpmyadmin,
Je ne comprends pas ce que vient faire phpmyadmin dans l'histoire
il ne gère pas les fichiers php ni html n'est-ce pas ?
> ça va encore,
si tu as bien essspliqué à phpmyadmin que tu faisais tout en utf-8 ou en
iso-truc
il doit avoir compris et s'en dépatouiller.
(il doit avoir les routines php kivonbien et sait s'en servir)
> mais sur le web ils
> reviennent tous. Décourageant.
Il y a des fonctions php pour encoder/décoder en utf-8 à la volée.
essaie de t'en servir
http://minilien.com/?IOSYecATj5
http://minilien.com/?RpE0MdRIvM
Olivier Miakinen
>
> de ce que je connais du php et de ce que j'y ai compris ...
> le php ne cause pas l'utf-8 ...
> (par défaut :iso-8859-1 crois-je)
Ce n'est pas tout-à-fait ça.
Un caractère accentué écrit directement dans un fichier sera dans le
charset (jeu de caractères) utilisé pour sauver ce fichier. Donc, si le
fichier est sauvé en UTF-8, le caractère sera en UTF-8. Un caractère
chinois dans un fichier sauvé en Big5 sera en Big5.
Mais ce qui peut faire penser que php ne causerait pas l'UTF-8, c'est
que de nombreuses fonctions traitant des caractères supposent un jeu
mono-octet, et que parmi celles-ci, il y en a même qui supposent le jeu
ISO-8859-1.
>> En sql, j'ai cela :
>> INSERT INTO `QSJ` (`ID`, `No`, `Titre`) VALUES (3, 1163, 'Algèbre
>> élémentaire');
Tant que tu ne sauras pas dans quel charset sont représentés ce « è » et
ces deux « é » au moment où tu fais la commande INSERT, cela ne veut
rien dire. Et encore, j'ai supposé que les caractères tels que « I » ou
« ( » étaient représentés en ASCII, et que le charset est un surensemble
d'ASCII compatible avec lui au niveau codage.
J'ai aussi supposé que...
> Toujours ces drôles de '
... que ces accents graves étaient en fait des guillemets simples ASCII.
>> Dès que j'importe dans phpmyadmin,
>
> Je ne comprends pas ce que vient faire phpmyadmin dans l'histoire
> il ne gère pas les fichiers php ni html n'est-ce pas ?
phpmyadmin gère la base de données en passant par un code qui est censé
gérer plusieurs charsets. Encore faut-il que le bon soit configuré.
> si tu as bien essspliqué à phpmyadmin que tu faisais tout en utf-8 ou en
> iso-truc
> il doit avoir compris et s'en dépatouiller.
> (il doit avoir les routines php kivonbien et sait s'en servir)
Il faut surtout savoir quels sont tous les charsets qui entrent en jeu,
en particulier celui utilisé pour entrer les valeurs dans la base et
celui utilisé pour les relire, à la fois via phpmyadmin et via les
scripts de Bernd.
>> mais sur le web ils
>> reviennent tous. Décourageant.
Ah oui, il y a aussi le charset déclaré (ou non) dans les entêtes HTTP,
et le charset déclaré (ou non) par une balise META.
> Il y a des fonctions php pour encoder/décoder en utf-8 à la volée.
> essaie de t'en servir
Ne surtout pas bidouiller ce genre de truc avant d'avoir localisé le
problème. Si Bernd parvient à la conclusion qu'il reçoit des caractères
en UTF-8 et qu'il doit les transmettre en Latin1, ou le contraire, alors
oui ces fonctions peuvent être utilisées. Sinon, il rajoute encore un
charset supplémentaire, avec le risque d'avoir encore plus de bugs qu'avant.
Bernd
> Donc, si le
> fichier est sauvé en UTF-8, le caractère sera en UTF-8. Un caractère
> chinois dans un fichier sauvé en Big5 sera en Big5.
Je sauve tous mes fichiers en utf8 no-bom et une fois relus en (x)html
ça fonctionne bien.
> Mais ce qui peut faire penser que php ne causerait pas l'UTF-8, c'est
> que de nombreuses fonctions traitant des caractères supposent un jeu
> mono-octet, et que parmi celles-ci, il y en a même qui supposent le jeu
> ISO-8859-1.
Les allemands font comment alors avec leurs Ü, ß, ä et autres ?
Ils utilisent bien sql ? si j'avais une adresse de news allemandes sur
la question, j'irai poser la question mais dans leur souci d'aller
toujours au fond des choses, ils vont m'entraîner dans des notions qui
ne vont qu'épaissir encore plus le la question !
> Tant que tu ne sauras pas dans quel charset sont représentés ce « è » et
> ces deux « é » au moment où tu fais la commande INSERT, cela ne veut
> rien dire. Et encore, j'ai supposé que les caractères tels que « I » ou
> « ( » étaient représentés en ASCII, et que le charset est un surensemble
> d'ASCII compatible avec lui au niveau codage.
utf8 est utilisé du début à la fin de la chaine de production du texte.
> Ah oui, il y a aussi le charset déclaré (ou non) dans les entêtes HTTP,
> et le charset déclaré (ou non) par une balise META.
Pas de META mais cela en tête de chaque page :
<?php header("Content-Type: text/html; charset=utf-8");?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
et ça fonctionne avec des centaines de pages de sites suffixés php sauf
avec les pages qui traitent les scripts sql.
Cela par ex.
INSERT INTO `QSJ` VALUES (8, 2095, 'Analyse algébrique');
le é est traité en plus différemment par les différents browsers mais
jamais un é
--
A+
Romer
Bernd
> de ce que je connais du php et de ce que j'y ai compris ...
> le php ne cause pas l'utf-8 ...
> (par défaut :iso-8859-1 crois-je)
Evidemment vu comme cela ça change tout.
>
> > J'ai lu des tas de trucs assez imbitables sur la question... je ne vois
> > guère de solution.
> >
> > En sql, j'ai cela :
> > INSERT INTO `QSJ` (`ID`, `No`, `Titre`) VALUES (3, 1163, 'Algèbre
> > élémentaire');
>
> Toujours ces drôles de '
Ce sont ceux-ci les drôles : `ou ceux-là : ' ?
Si maintenant en plus, il faut entrer dans ces machins, je vais revenir
au boulier de mon enfance !
> Je ne comprends pas ce que vient faire phpmyadmin dans l'histoire
> il ne gère pas les fichiers php ni html n'est-ce pas ?
Il les lit puisque c'est une interface web capable de faire cela.
> Il y a des fonctions php pour encoder/décoder en utf-8 à la volée.
> essaie de t'en servir
>
> http://minilien.com/?IOSYecATj5
> http://minilien.com/?RpE0MdRIvM
Je vais essayer cette solution. J'en ai bien trouvé une mais elle est
raide : c'est d'écrire algèbre comme cela : alg&egravis;bre et là ça
marche. Mais dans un fichier de 3000 lignes ça fait hiéroglyphes de
-4000 av J.-C. !
--
A+
Romer
Olivier Miakinen
>
> Je sauve tous mes fichiers en utf8 no-bom et une fois relus en (x)html
> ça fonctionne bien.
Voilà déjà un bon point d'acquis. Il reste à savoir si les données ont
été stockées dans la base en supposant UTF-8, et idem pour la relecture.
Je ne sais même pas si MySQL lui-même est susceptible de faire une
conversion de charset, entre ce qu'on lui envoie et ce qu'il stocke
d'une part, entre ce qu'il a stocké et ce qu'il retourne d'autre part.
>> Mais ce qui peut faire penser que php ne causerait pas l'UTF-8, c'est
>> que de nombreuses fonctions traitant des caractères supposent un jeu
>> mono-octet, et que parmi celles-ci, il y en a même qui supposent le jeu
>> ISO-8859-1.
>
> Les allemands font comment alors avec leurs Ü, ß, ä et autres ?
Au choix, en ISO-8859-1 ou en UTF-8 (parmi d'autres possibilités). Note
que si Ü, ß et ä n'appartenaient pas à ISO-8859-1, alors tu n'aurais pas
pu les écrire dans ce groupe (surtout en étant chez Free).
Par ailleurs, tu ne sembles pas avoir compris ma remarque. Je disais
qu'il est *faux* de croire que PHP ne sait faire que de l'ISO-8859-1.
>> Tant que tu ne sauras pas dans quel charset sont représentés ce « è » et
>> ces deux « é » au moment où tu fais la commande INSERT, cela ne veut
>> rien dire. Et encore, j'ai supposé que les caractères tels que « I » ou
>> « ( » étaient représentés en ASCII, et que le charset est un surensemble
>> d'ASCII compatible avec lui au niveau codage.
>
> utf8 est utilisé du début à la fin de la chaine de production du texte.
La preuve que non, sinon ça marcherait. Il reste à trouver où ça coince.
> Pas de META mais cela en tête de chaque page :
>
> <?php header("Content-Type: text/html; charset=utf-8");?>
Dans mes bras ! ©
Ne change rien à ça, c'est parfait.
> Cela par ex.
>
> INSERT INTO `QSJ` VALUES (8, 2095, 'Analyse algébrique');
Tu as toujours des accents graves (`) autour de « QSJ » au lieu d'avoir
des simple quotes (') comme autour d'« Analyse algébrique ». C'est
assez bizarre, et surtout je ne comprends pas comment ta requête peut
fonctionner si tu envoies vraiment ça à SQL.
> le é est traité en plus différemment par les différents browsers mais
> jamais un é
Différemment par les différents navigateurs ??? Alors là je demande à
voir. Une page de test, vite !
Olivier Miakinen
>> >
>> > élémentaire');
>>
>> Toujours ces drôles de '
>
> Ce sont ceux-ci les drôles : `
Oui, ce sont des accents graves (code ascii 96).
> ou ceux-là : ' ?
Ceux-là sont corrects (code ascii 39).
> Si maintenant en plus, il faut entrer dans ces machins, je vais revenir
> au boulier de mon enfance !
Si tu veux, mais dans ce cas tu dois abandonner l'idée de faire des
pages web.
>
>> Je ne comprends pas ce que vient faire phpmyadmin dans l'histoire
>> il ne gère pas les fichiers php ni html n'est-ce pas ?
>
> Il les lit puisque c'est une interface web capable de faire cela.
>
>> Il y a des fonctions php pour encoder/décoder en utf-8 à la volée.
>> essaie de t'en servir
>>
>> http://minilien.com/?IOSYecATj5
>> http://minilien.com/?RpE0MdRIvM
Liens équivalents mais plus rapides et sans pub :
http://fr2.php.net/mysql-client-encoding
http://fr2.php.net/mb-convert-encoding
> Je vais essayer cette solution.
La première est une excellente chose (donne nous le résultat, ça peut
être très intéressant). La seconde... hum... si la réponse n'était pas
UTF-8, il vaudrait mieux arriver à corriger le problème plutôt que de
le contourner en rajoutant des bugs. Et si la réponse était UTF-8 je
ne vois pas quel charset tu choisirais.
> J'en ai bien trouvé une mais elle est
> raide : c'est d'écrire algèbre comme cela : alg&egravis;bre et là ça
> marche. Mais dans un fichier de 3000 lignes ça fait hiéroglyphes de
> -4000 av J.-C. !
Je suppose que tu voulais dire « algèbre ». Oui, à partir du
moment où tous les charsets sont compatibles avec ASCII ça marchera.
Mais il y a quand même mieux à faire. D'autant que le jour où tu voudras
faire du chinois tu seras bien embêté, encore plus que maintenant.
ASM
> Le 09/03/2007 00:35, ASM répondait à Bernd :
>
>> iso-truc
>> il doit avoir compris et s'en dépatouiller.
>> (il doit avoir les routines php kivonbien et sait s'en servir)
>
> Il faut surtout savoir quels sont tous les charsets qui entrent en jeu,
> en particulier celui utilisé pour entrer les valeurs dans la base et
> celui utilisé pour les relire,
C'est bien ce que je voulais dire.
"bien esspliquer à "
> à la fois via phpmyadmin et via les scripts de Bernd.
Les scripts php pondus par ailleurs, c'est bien sûr, une autre paire de
manches.
à mon idée phpmyadmin ne devrait servir qu'à configurer la base
(éventuellement une table ou 2) en faisant bien gaffe essentiellement à
la continuité du charset choisi pour gérer ses pages web.
(vérifier partout qu'on emploie bien le même).
Et par la suite il ne devrait servir qu'aux relectures et non pas au
nourrissage.
D'utiliser 2 façons d'entrer des données ne facilite pas le déboggage.
>> Il y a des fonctions php pour encoder/décoder en utf-8 à la volée.
>> essaie de t'en servir
>
> Ne surtout pas bidouiller ce genre de truc avant d'avoir localisé le
> problème. Si Bernd parvient à la conclusion qu'il reçoit des caractères
> en UTF-8 et qu'il doit les transmettre en Latin1, ou le contraire, alors
> oui ces fonctions peuvent être utilisées. Sinon, il rajoute encore un
> charset supplémentaire, avec le risque d'avoir encore plus de bugs qu'avant.
Certes, mais au moins et avec un peu de chance, on aura localisé le
maillon faible.
Mais ... vu le code que Bern nous copie-colle ... il ne doit pas il y
avoir que le(s) charset(s) ... son éditeur texte doit avoir des
difficultés à respecter le charset choisi si toutefois ce dernier sait
ce que c'est.
Sauf à ce son clavier n'envoie pas toujours le même code pour la même
touche ?
Sauf à ce que Bernd se serve indifféremment de l'accent grave et de
l'apostrophe pour écrire '.
Bernd
> Voilà déjà un bon point d'acquis. Il reste à savoir si les données ont
> été stockées dans la base en supposant UTF-8, et idem pour la relecture.
Je pense que oui car dans phpmyadmin que j'utilise pour les
imports-exports de la base mysql, tout ce qui peut être coché en utf8
l'est effectivement - la collation aussi.
> Par ailleurs, tu ne sembles pas avoir compris ma remarque. Je disais
> qu'il est *faux* de croire que PHP ne sait faire que de l'ISO-8859-1.
J'y crois aussi puisque je m'acharne à encoder tout cela en utf8 et à le
faire fonctionner.
> Tu as toujours des accents graves (`) autour de « QSJ » au lieu d'avoir
> des simple quotes (') comme autour d'« Analyse algébrique ». C'est
> assez bizarre, et surtout je ne comprends pas comment ta requête peut
> fonctionner si tu envoies vraiment ça à SQL.
Là c'est la bouteille à l'encre - j'ai essayé d'harmoniser cela en
remplaçant les `par des ' et l'importation de la table sql par
phpmyadmin refuse acharnément de se faire - blocage obstiné dès la 1re
ligne.
Blocage dès le CREATE si j'utilise les quotes droites !?
CREATE TABLE 'QSJ' (
`ID` int(255) NOT NULL auto_increment,
`No` smallint(9) NOT NULL default '0',
`Titre` text character set utf8 collate utf8_swedish_ci NOT NULL,
PRIMARY KEY (`ID`),
KEY `titres` (`Titre`(15)),
KEY `No` (`No`)
) ENGINE=MyISAM AUTO_INCREMENT=391 DEFAULT CHARSET=utf8
AUTO_INCREMENT=391 ;
En fait j'ai écrit la table directement sous cette forme en automatisant
l'écriture à l'aide d'expressions rationnelles.
VALUES (24, 2043, 'Berlin et son statut');
avec des quotes droites et j'ai repris le début de la ligne qui manque
en faisant un exemple avec phpmyadmin, en l'exportant - en examinant ce
qu'il avait produit, j'ai continué.
Il m'a donné cela à l'exportation d'une seule ligne :
INSERT INTO `QSJ` (`ID`, `No`, `Titre`) et j'ai recollé ensuite tous les
morceaux.
En fait ce fut plus rapide de faire ainsi plutôt que passer par la zone
de saisie impratique de phpmyadmin.
> > le é est traité en plus différemment par les différents browsers mais
> > jamais un é
>
> Différemment par les différents navigateurs ??? Alors là je demande à
> voir. Une page de test, vite !
Sur un navig. j'ai un carré - sur un autre un ? noir, sur un autre rien
et en plus des différences sur Mac et PC.
Je mets en ligne demain un exemple - en effet dans mon découragement,
j'ai tout retansformé en entités et évidemment ça marche mais qu'elle
bouillie pour chats pour lire cela dans le source !
Merci de te pencher sur la question - je reviens demain avec un exemple.
--
A+
Romer
Bernd
Bien sûr - je suis tellement allergique à cela que je me trompe
allègrement - heureusement que les recherches-remplacements vont très
vite et sont efficaces avec un bon éditeur.
--
A+
Romer
Bernd
> Sauf à ce que Bernd se serve indifféremment de l'accent grave et de
> l'apostrophe pour écrire '.
Clavier Mac étendu tout ce qu'il ya de plus sérieux :-)
Par commodité j'ai essayé ' et " mais dans la 1re partie, phpmyadmin ne
tolère que ` à l'import.
1re partie de la ligne : INSERT INTO `QSJ` (`ID`, `No`, `Titre`)
2e partie de la ligne : VALUES (60, 2386, 'Darwin et le darwinisme');
l'ensemble de la ligne étant :
INSERT INTO `QSJ` (`ID`, `No`, `Titre`) VALUES (60, 2386, 'Darwin et le
darwinisme');
Si j'essaye les quotes droites ou des " partout : erreur !
C'est là que je perds mon Latin 1 ou plutôt mon utf8 !
--
A+
Romer
Olivier Miakinen
>
>> Tu as toujours des accents graves (`) autour de « QSJ » au lieu d'avoir
>> des simple quotes (') comme autour d'« Analyse algébrique ». C'est
>> assez bizarre, et surtout je ne comprends pas comment ta requête peut
>> fonctionner si tu envoies vraiment ça à SQL.
>
> Là c'est la bouteille à l'encre - j'ai essayé d'harmoniser cela en
> remplaçant les `par des ' et l'importation de la table sql par
> phpmyadmin refuse acharnément de se faire - blocage obstiné dès la 1re
> ligne.
>
> Blocage dès le CREATE si j'utilise les quotes droites !?
>
> CREATE TABLE 'QSJ' (
> `ID` int(255) NOT NULL auto_increment,
> `No` smallint(9) NOT NULL default '0',
> `Titre` text character set utf8 collate utf8_swedish_ci NOT NULL,
> PRIMARY KEY (`ID`),
> KEY `titres` (`Titre`(15)),
> KEY `No` (`No`)
> ) ENGINE=MyISAM AUTO_INCREMENT=391 DEFAULT CHARSET=utf8
> AUTO_INCREMENT=391 ;
J'ai compris !
J'ai cherché « CREATE TABLE » sur Internet, et j'ai trouvé par exemple
ceci : <http://www.w3schools.com/sql/sql_create.asp>
<cit.>
CREATE TABLE Person
(
LastName varchar(30),
FirstName varchar,
Address varchar,
Age int(3)
)
</cit.>
En fait, ta table ne s'appelle pas « QSJ » mais « `QSJ` », et le premier
champ ne s'appelle pas « ID » mais « `ID` », les caractères ` faisant
partie intégrante du nom.
Tu aurais donc pu faire tout simplement :
CREATE TABLE QSJ (
ID int(255) NOT NULL auto_increment,
No smallint(9) NOT NULL default '0',
Titre text character set utf8 collate utf8_swedish_ci NOT NULL,
PRIMARY KEY (ID),
KEY titres (Titre(15)),
KEY No (No)
) ENGINE=MyISAM AUTO_INCREMENT=391 DEFAULT CHARSET=utf8
AUTO_INCREMENT=391 ;
>> > le é est traité en plus différemment par les différents browsers mais
>> > jamais un é
>>
>> Différemment par les différents navigateurs ??? Alors là je demande à
>> voir. Une page de test, vite !
>
> Sur un navig. j'ai un carré - sur un autre un ? noir, sur un autre rien
> et en plus des différences sur Mac et PC.
Ah, ok. C'est probablement un codage UTF-8 bien formé correspondant à un
caractère Unicode non défini. Vois par exemple le caractère pris comme
exemple dans l'avant-dernière ligne de ce tableau :
<http://www.miakinen.net/vrac/charsets/codes-couleurs>
Sur Mac tu dois voir le logo Apple, mais sur PC cela donne un carré dans
Internet Explorer et un point d'interrogation dans Mozilla et Firefox.
> Je mets en ligne demain un exemple
Je pense que c'est le mieux en effet. Essaye d'y mettre plusieurs
caractères différents facilement reconnaissables (à, ç, é, è par
exemple). Ce serait bien aussi s'il y avait des caractères qui ne
sont pas dans Latin1 (œ et €) mais si tu ne sais pas le faire, tant
pis.
Bernd
> Tu aurais donc pu faire tout simplement :
>
> CREATE TABLE QSJ (
> ID int(255) NOT NULL auto_increment,
> No smallint(9) NOT NULL default '0',
> Titre text character set utf8 collate utf8_swedish_ci NOT NULL,
> PRIMARY KEY (ID),
> KEY titres (Titre(15)),
> KEY No (No)
> ) ENGINE=MyISAM AUTO_INCREMENT=391 DEFAULT CHARSET=utf8
> AUTO_INCREMENT=391 ;
Mais je peux encore le faire - suffira ensuite d'importer dans
phpmyadmin - si tout se passe bien...
> Je pense que c'est le mieux en effet. Essaye d'y mettre plusieurs
> caractères différents facilement reconnaissables (à, ç, é, è par
> exemple). Ce serait bien aussi s'il y avait des caractères qui ne
> sont pas dans Latin1 (œ et €) mais si tu ne sais pas le faire, tant
> pis.
Comment ça, je ne sais pas faire cela ;-)
Tu vas voir - je peux tous te les sortir du moins les européens - les
autres (tamul, bengali et tutti quanti ) c'est autre chose.
Mais je vois mal quelles concluisons tu vas en tirer - voir des ?, des
carrés ou des signes orientaux à la place d'un ï ou ë, ça peux aider ça
?
A demain pour de nouvelles énigmes...
Merci de votre aide. Cela dit en passant et entre nous - vous ne pensez
pas que c'est un peu tordu tout ça ? et qu'il faut avoir un sacré temps
à y consacrer pour écrire un simple mot comme bébé ou pépé ?
--
A+
Romer
Olivier Miakinen
>
;-)
Pardon d'avoir douté, homme de peu de foi que je suis !
> Mais je vois mal quelles concluisons tu vas en tirer - voir des ?, des
> carrés ou des signes orientaux à la place d'un ï ou ë, ça peux aider ça
> ?
Non, mais je peux faire deux choses, chacune étant à priori suffisante.
1) Changer le charset d'affichage dans Mozilla en choisissant un jeu
8 bits (par exemple iso-8859-1 ou cp1252).
2) Sauver le résultat dans un fichier puis le lire avec un éditeur
binaire.
Dans un cas comme dans l'autre je devrais savoir ce qui est
effectivement transmis puisque chaque octet codant en UTF-8 un
bout de caractère Unicode donnera un unique caractère.
> A demain pour de nouvelles énigmes...
;-)
> Merci de votre aide. Cela dit en passant et entre nous - vous ne pensez
> pas que c'est un peu tordu tout ça ? et qu'il faut avoir un sacré temps
> à y consacrer pour écrire un simple mot comme bébé ou pépé ?
Justement, ça ne devrait pas être tordu. Je n'ai pas encore trop mis mon
nez dans les bases de données, mais si je peux écrire un petit tutoriel
pour éviter ces soucis à l'avenir, ça ne sera pas plus mal.
Bernd
> Non, mais je peux faire deux choses, chacune étant à priori suffisante.
> 1) Changer le charset d'affichage dans Mozilla en choisissant un jeu
> 8 bits (par exemple iso-8859-1 ou cp1252).
> 2) Sauver le résultat dans un fichier puis le lire avec un éditeur
> binaire.
> Dans un cas comme dans l'autre je devrais savoir ce qui est
> effectivement transmis puisque chaque octet codant en UTF-8 un
> bout de caractère Unicode donnera un unique caractère.
Merci de ton aide - je te laisse ce travail très spécialisé auquel je ne
comprends pas tout.
Je mets en ligne un exemple dans peu de temps.
--
A+
Romer
ASM
> Olivier Miakinen <om+...@miakinen.net> wrote:
>
>> Tu aurais donc pu faire tout simplement :
>>
>> CREATE TABLE QSJ (
>> ID int(255) NOT NULL auto_increment,
>> No smallint(9) NOT NULL default '0',
>> Titre text character set utf8 collate utf8_swedish_ci NOT NULL,
>> PRIMARY KEY (ID),
>> KEY titres (Titre(15)),
>> KEY No (No)
>> ) ENGINE=MyISAM AUTO_INCREMENT=391 DEFAULT CHARSET=utf8
>> AUTO_INCREMENT=391 ;
>
>
> Mais je peux encore le faire - suffira ensuite d'importer dans
> phpmyadmin -
? ? quoi importer dans phpmyadmin
si j'ai bien compris ce qu'était ce phpmyadmin
il n'aura qu'à lire ce qui a été fait par le php ci-dessus, non ?
On le connecte à la base et après yapuka, non?
(j'ai dû utiliser phpmyadmin 1 fois ou 2, qques subtilités ont pu
m'échapper ...)
> Merci de votre aide. Cela dit en passant et entre nous - vous ne pensez
> pas que c'est un peu tordu tout ça ? et qu'il faut avoir un sacré temps
> à y consacrer pour écrire un simple mot comme bébé ou pépé ?
Si, si !
c'est ça qui nous bote !
Faut dire qu'on a perdu tous nos stylos et crayons :-)
On peut supposer qu'une fois acquis le howto ça doit être plus facile.
M'enfin ... si on s'en souvient quand on en a re-besoin ...
Et si on ne sait plus faire on peut, par exemple, utiliser SQLEditor :
http://www.malcolmhardie.com/sqleditor/cocoa/
et si celui là ne plaît pô ...
<http://www.versiontracker.com/php/search.php?mode=basic&action=search&str=sql&srchArea=mac%7Cosx&x=0&y=0>
Sinon il reste l'url donnée par Olivier et
où il est proposé un outil en ligne pour créer ce(s) code(s).
Sous système 8 j'avais un petit ShareWare pour fabriquer tout un tas de
routines en *.sql (créer modififier des tables, les interroger trier,
étoussa)
J'l'avions perdu :-(
Bernd
Pour les personnes qui ont bien voulu se pencher sur un pb de codage et
de rendu des caractères accentués dans une table mysql piloté par php
avec boucle de lecture, voilà un exemple simple avec caractères
accentués à la pelle :
La table Wortschatz, elle, n'est pas appelé en php et les caractères
accentués passent bien.
http://jomain.free.fr/exemple/
Par avance merci.
--
A+
Romer
denisb
> Pour les personnes qui ont bien voulu se pencher sur un pb de codage et
> de rendu des caractères accentués dans une table mysql piloté par php
> avec boucle de lecture, voilà un exemple simple avec caractères
> accentués à la pelle :
rendu sur mon mozilla :
<http://circaete.net/codage.html>
:-))
--
@@@@@
E -00 comme on est very beaux dis !
' `) /
|\_ =="
ASM
>
> Pour les personnes qui ont bien voulu se pencher sur un pb de codage et
> de rendu des caractères accentués
>
oui, on voit bien que :
- ça marche mal
- que l'en-tête utf-8 est bien envoyée
mais aussi que :
line 26 column 5 - Warning: <a> escaping malformed URI reference
BAD <a href="http://www.mozilla.org/one space.html">space</a>
GOOD <a href="http://www.mozilla.org/one%20space.html">space</a>
GOOD <a href="http://www.mozilla.org/one+space.html">space</a>
(sans même parler des accents ... !)
Je suppose que les connaisseurs de php pourraient être intéressés par le
contenu de 'qsj.php'
zpz
> Pour les personnes qui ont bien voulu se pencher sur un pb de codage et
> de rendu des caractères accentués dans une table mysql piloté par php
> avec boucle de lecture, voilà un exemple simple avec caractères
> accentués à la pelle :
>
> La table Wortschatz, elle, n'est pas appelé en php et les caractères
> accentués passent bien.
>
> http://jomain.free.fr/exemple/
Effectivement, ça passe pas. Peut-être as-tu déjà rencontré ce site
dans tes recherches :
<http://electron-libre.fassnet.net/utf8.php>
--
zpz
Olivier Miakinen
>
> http://jomain.free.fr/exemple/
Là, c'est très clair : c'est une page en Windows-1252 annoncée comme de
l'UTF-8. Cela pourrait tout aussi bien être de l'ISO-8859-1 s'il n'y
avait pas les caractères œ et €.
Je ne me rappelle pas que tu aies dit ce que retourne la fonction
mysql_client_encoding() ?
ASM
> Le 10/03/2007 11:28, Bernd a écrit :
>> http://jomain.free.fr/exemple/
>
> Là, c'est très clair : c'est une page en Windows-1252
comment vois-tu ça ?
Olivier Miakinen
>>> http://jomain.free.fr/exemple/
>>
>> Là, c'est très clair : c'est une page en Windows-1252
>
> comment vois-tu ça ?
Denisb, qui a fait ce que j'avais dit, a eu la gentillesse de laisser
des copies d'écran : http://circaete.net/codage.html.
Seule la dernière table (iso8859-1) affiche correctement tous les
caractères, or les caractères œ et € n'appartiennent pas à iso8859-1,
mais ils appartiennent à Windows-1252, et Mozilla les affiche même si
on annonce ISO-8859-1 au lieu de CP1252.
C.Q.F.D.
ASM
> Le 10/03/2007 13:28, ASM a écrit :
>
>>>> http://jomain.free.fr/exemple/
>>> Là, c'est très clair : c'est une page en Windows-1252
>> comment vois-tu ça ?
>
> Denisb, qui a fait ce que j'avais dit, a eu la gentillesse de laisser
> des copies d'écran : http://circaete.net/codage.html.
Ha! bon sang ! mais c'est ... bien sûr !
> C.Q.F.D.
Bernd
> Là, c'est très clair : c'est une page en Windows-1252 annoncée comme de
> l'UTF-8. Cela pourrait tout aussi bien être de l'ISO-8859-1 s'il n'y
> avait pas les caractères œ et €.
>
> Je ne me rappelle pas que tu aies dit ce que retourne la fonction
> mysql_client_encoding() ?
Réponse : Latin 1 - c'est indiqué à la dernière ligne de la table.
--
A+
Romer
Bernd
> Bernd <ro...@arobase.com> wrote:
> > Pour les personnes qui ont bien voulu se pencher sur un pb de codage et
> > de rendu des caractères accentués dans une table mysql piloté par php
> > avec boucle de lecture, voilà un exemple simple avec caractères
> > accentués à la pelle :
> > http://jomain.free.fr/exemple/
>
> rendu sur mon mozilla :
> <http://circaete.net/codage.html>
Donc utf8 n'est pas reconnu - il doit y avoir un défaut dans la chaine
d'écriture depuis l'éditeur jusqu'au navigateur.
Pourtant il me semble bien avoir indiqué partout où c'était possible :
utf8
--
A+
Romer
Bernd
> Effectivement, ça passe pas. Peut-être as-tu déjà rencontré ce site
> dans tes recherches :
> <http://electron-libre.fassnet.net/utf8.php>
Non - mais je vais l'imprimer - il me paraît à 1re vue pas mal.
--
A+
Romer
ASM
>
> Donc utf8 n'est pas reconnu - il doit y avoir un défaut dans la chaine
> d'écriture depuis l'éditeur jusqu'au navigateur.
Non, à mon idée, il y a un défaut dans ton éditeur texte
Lequel emploies-tu ?
> Pourtant il me semble bien avoir indiqué partout où c'était possible :
> utf8
L'éditeur texte n'as pas dû capter ?
Avec quoi transfères-tu tes fichiers sur le serveur ?
Bernd
> > Je ne me rappelle pas que tu aies dit ce que retourne la fonction
> > mysql_client_encoding() ?
>
> Réponse : Latin 1 - c'est indiqué à la dernière ligne de la table par la
> fonction que tu préconise d'activer.
En activant effectivement iso latin sur le navigateur, ça marche. Mais
à aucun moment je n'ai indiqué d'utiliser cet encodage, ni dans
l'éditeur, ni dans phpmyadmin qui est censé importer et exporter en utf8
- du moins le prétend-il.
De plus dans la page html/php, je force le navigateur à lire le utf8 par
l'en-tête :
<?php header("Content-Type: text/html; charset=utf-8");?> !DOCTYPE html
<PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> html
<xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
Donc, là je ne vois plus bien quoi faire si ce n'est à changer l'en-tête
- mais je ne préfèrerais pas - j'ai toujours codé en utf8. --
A+
Romer
Bernd
> Non, à mon idée, il y a un défaut dans ton éditeur texte
> Lequel emploies-tu ?
BBedit et l'encodage par défaut est toujours unicode (utf-8 no BOM)
Et il n'a jamais défailli depuis que je l'utlise.
> Avec quoi transfères-tu tes fichiers sur le serveur ?
l'excellent Transmit.
Le tout sur mac - vous l'aviez compris.
--
A+
Romer
Bernd
>
> Effectivement, ça passe pas. Peut-être as-tu déjà rencontré ce site
> dans tes recherches :
> <http://electron-libre.fassnet.net/utf8.php>
Encore moi mais c'est la fin :-) du moins je l'espère !
La solution semble trouvée et se trouve à ce lien judicieux ci-dessus.
J'ai bien suivi les indications de ce tuto et apparemment ça marche.
Tous les caractères sont reconnus même si la fonction :
$charset = mysql_client_encoding($db);
echo "Le jeu de caractères actuel est : $charset\n";
persiste à dire que le jeu de caractères est Latin 1.
En fait il l'est au départ mais la fonction php : mysql_query ("SET
NAMES 'utf8'"); force le jeu utf8.
Un grand merci à vous tous qui avez vite et pertinamment répondu.
A+ pour de nouvelles aventures.
I enjoy yet: http://jomain.free.fr/exemple/
--
A+
Romer
ASM
> ASM <stephanemor...@wanadoo.fr.invalid> wrote:
>
>> Lequel emploies-tu ?
>
> BBedit et l'encodage par défaut est toujours unicode (utf-8 no BOM)
> Et il n'a jamais défailli depuis que je l'utlise.
Si c'est BBE, en effet il ne devrait pas il y avoir de pb de ce côté
>> Avec quoi transfères-tu tes fichiers sur le serveur ?
>
> l'excellent Transmit.
Connais pô.
M'en va vouër à vouër.
Faudrait pas qu'il fasse comme Fetch qui a tendance à "traduire" à
l'insu de son plein gré.
Ha! le v'la là qui se cache dans un replis du DD.
Hop!
Loggin ... connect ...
Ha! Mais ! menu : Affichage / Encodage de texte / Latin-1 !!!
Tu as bien vérifié et re-re-re-vérifié à chaque fois qu'il est et/ou
était réglé sur UTF-8 ?
> Le tout sur mac - vous l'aviez compris.
Voui.
Bernd
> Tu as bien vérifié et re-re-re-vérifié à chaque fois qu'il est et/ou
> était réglé sur UTF-8 ?
Que oui - entre US ASCII et Japanese. Il y est coincé et n'en bouge pas.
Le pb est résolu et comme je disais, c'est assez tordu tout de même pour
un néophyte.
Heureusement que le lien magique que tu as donné a révélé la solution.
Que c'est beau quand ça marche !
Encore merci à tous.
--
A+
Romer
ASM
>
> Le pb est résolu et comme je disais, c'est assez tordu tout de même pour
> un néophyte.
Là oui je trouve aussi.
> Heureusement que le lien magique que tu as donné a révélé la solution.
non c'est zpz qui semble avoir donné cette piste
Hop! dans les favoris :-)
Bernd
> non c'est zpz qui semble avoir donné cette piste
> Hop! dans les favoris :-)
Aïe - confusion inexcusable - merci donc spécialement à zpz.
--
A+
Romer
Olivier Miakinen
>
> [...] la fonction php : mysql_query ("SET NAMES 'utf8'"); force le jeu utf8.
Génial ! Note qu'ils en parlent aussi dans les notes d'utilisateurs sur
http://fr2.php.net/mysql-client-encoding parmi d'autres choses. J'allais
te proposer d'essayer tous ces conseils, sauf que c'est en anglais alors
j'avais un peu de mal à trouver ce qu'il fallait faire exactement.
En tout cas, je suis ravi que cela fonctionne enfin.
Bernd
> Génial ! Note qu'ils en parlent aussi dans les notes d'utilisateurs sur
> http://fr2.php.net/mysql-client-encoding parmi d'autres choses. J'allais
> te proposer d'essayer tous ces conseils, sauf que c'est en anglais alors
> j'avais un peu de mal à trouver ce qu'il fallait faire exactement.
Un prof de langue aurait bien réussi à s'y retrouver ;-)
> En tout cas, je suis ravi que cela fonctionne enfin.
Moi de même - encore un jour de galère et j'abandonnais et passais aux
entités mais cela aurait été très dommage.
Merci de votre aide à tous.
--
A+
Romer
Pierre Goiffon
> Il reste à savoir si les données ont
> été stockées dans la base en supposant UTF-8, et idem pour la relecture.
> Je ne sais même pas si MySQL lui-même est susceptible de faire une
> conversion de charset, entre ce qu'on lui envoie et ce qu'il stocke
> d'une part, entre ce qu'il a stocké et ce qu'il retourne d'autre part.
Heureusement que oui ! Il ne faut surtout pas confondre collation (qui
influe sur le stockage ET le classement) et propriétés de connexion à la
base (codage utilisé dans le contexte de communication entre
l'application et le moteur de la base)
Si l'on utilise des SGBD, c'est bien pour s'affranchir de toute
problématiques de stockage... Le SGBD s'en débrouille, à partir du
paramétrage de l'administrateur.