Bonjour,

J'ai chez moi, en local, une base de données que je modifie, consulte, par scripts php...
J'ai copié cette base de données sur ovh, ainsi que tous mes scripts.

Lors d'un de ces scripts, je fais lire plusieurs tables et afficher certaines de leurs données.

Parmis ces tables, certaines sont cryptées : mon script les décode, et les affiche, pas de problème.

Par contre, j'ai une table, dont les données ne sont pas sensibles, donc elles sont enregistrées en clair dans la table; et lors de l'affichage dans ma page php, les caractères accentués ne sont pas affichés.

A signaler que tout est sauvegardé en utf8_bin.

Chez moi, en local, cela fonctionne parfaitement.

J'ai donc ouvert phpmyadmin en local chez moi et sur ovh, pour comparer.
Or, si les données semblent équivalentes, je trouve une petite différence dans la structure :

Dans la table en local et qui fonctionne, mes données sont déclarées comme type MIME : text/plain.

Or, chez ovh, cette fonction n'est pas présente.

Le problème vient-il de là ?

Pourquoi n'est-ce pas accessible ?

Comment résoudre ce problème ?

Je peux, à la limite, me retaper la saisie de cette table, vu qu'il n'y a pour l'instant pas beaucoup d'enregistrements, mais bon... pas que ça a faire, et pas très propre comme solution; sans compter que je ne suis pas certain que cela résolve le problème.

Des idées ?

Merci

EDIT : Il est à noter, mais je ne sais pas si c'est lié, que j'ai également un site Spip, que j'ai tranféré de free à ovh; et j'ai eu tellement de problèmes que j'ai été obligé de recréer complètement ma base de données chez ovh, et retaper tout le site (qui n'est pas très gros); car il y avait un problème de... caractères accentués !
A savoir que les symptômes n'étaient pas tout à fait les mêmes : lors de l'affichage d'une page, dès qu'il y avait un caractère accentué, l'affichage des données se terminaient comme s'il n'y avait plus de caractères derrière.
Personne n'a pu me renseigner là-dessus.
Je me suis dit que cela venait peut-être de versions mysql différentes entre free (version 4) et ovh (version 5).

Mais est-ce le même problème ?


Et surtout, comment le résoudre.

RE-EDIT : A noter que chez moi, mysql est en version 5.1.41-3 (ubuntu), et en version 5 chez ovh.

Je rajoute, car je viens d'essayer, que j'ai tenté de changer un enregistrement dans ma table qui déconne, pour voir; le résultat est le même.

Personne n'aurait une piste de recherche ?

Enfin, je rajoute encore, que les données qui clochent, s'affichent normalement si je mets l'affichage de la page de mon navigateur en 'iso..." traditionnel; ce qui du coup, pose un problème pour les autres données qui elles, sont bien en utf8

Ce que je ne comprends pas, c'est que sur ma table en local, elles sont en utf-8.
Je sauvegarde et remet cette table sur ovh, les données sont maintenant en iso.

Là, je nage !

Et le pire, c'est que du coup, je suis complètement bloqué.

Seules les données qui sont cryptées fonctionnent, (mais elle sont sauvagardées en blob et autres). Tous ce qui est du char ne fonctionne pas.

Une idée ?

salut,

a tout hasard as tu essayé un : set names utf8 ?

tous ce qui est collation est en utf-8 ?

@+

Qu'appelles-tu collation ? (je suis pas champions en base de données).

Par contre, je viens de détecter une nouvelle différence entre ma base originelle en local qui fonctionne, et celle copiée sur ovh qui ne fonctionne pas (certaines tables).

Lorsque dans phpmyadmin, je fais l'affichage de ma base de données, la liste des tables s'affiche; elles sont en utf8-bin, sauf une qui est en utf8-general-ci; mais bon, ça ne devrait pas être le problème; en plus c'est le cas aussi sur la version locale.

Par contre, dans la version ovh , sur la dernière ligne, qui récapitule, (nombre de tables, etc...) en interclassement sur la base ovh j'ai : latin1-swedish-ci !
Ce qui n'est pas le cas bien entendu sur ma base en local.

Qu'est-ce que ça fait là, je n'en sais rien !

Comment le corriger pas plus.

Je n'ai rien contre la Suède, mais là...

J'ai cherché (pas énormément, c'est vrai), quelques explications et phpmyadmin, et sur les interclassement, etc; et on tombe vite sur de l'anglais, ce qui est du domaine du fantastique (gore) pour moi.

Merci pour l'aide.

Bon, collation = interclassement. Je viens de trouver un tuto qui le dit.

Alors du coup, j'ai essayé des trucs :

ALTER DATABASE ma_base CHARSET utf8 COLLATE utf8_bin.

Puis, au niveau de ma table récalcitrante :
ALTER TABLE ma_table CONVERT TO CHARSET utf8 COLLATE utf_bin

Ben, c'est joli, j'ai mis de l'utf8 partout...




mais ça ne résoud pas le problème...

Si ça peut encore aider, car j'ai un peu de mal à assimiler ces notions, j'ai lancé, sous phpmyadmin :
SHOW VARIABLES LIKE 'char%'

et j'obtiens :

character-set-client utf8
character-ser-connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server latin1
character_set_system utf8

Bon, il y a bien character_set_server qui est à latin1, mais comme j'ai du mal à piger son utilité...
Le reste m'a l'air correct, non ?

C'est assez simple en fait :p

Tu as l'encodage x de ta table (la collation, en s'en fiche pour le moment), l'encodage y du transfert entre php(y)->mysql(x) et mysql(x)->mysql(y), et z l'encodage de ta page.

Le tout est de faire en sorte que tous soient en harmonie.

Tu règles x avec ton ALTER TABLE ...
Tu règles y avec "set names y"
Tu règles z avec un header() et/ou un meta-equiv (qui comme son nom l'indique, équivaut en quelque sorte à un header). D'après des tests que j'ai pu faire, et contrairement à ce que j'avais pu lire sur le net, meta-equiv et header() ne sont pas plus "fort" l'un ou l'autre : c'est tout simplement utf-8 qui prend le dessus. Mais par logique, ils doivent être les mêmes. Car tu ne t'appelles pas John et Samantha ...

Cas de figure :

Tu utilises utf-8 sous mysql, et utf-8 côté php, et utf-8 coté html : x, y et z sont en utf-8
Tu utilises utf-8 sous mysql, et latin1 côté php et html : x est en utf-8, et y et z sont en latin1
Tu utilises utf-8 sous mysql, latin1 coté php et utf8 coté html : x est en utf-8, y est en latin1 et z en utf-8, mais bien penser à faire les conversions avant envoi et après reception à la base de données, et au navigateur.

Enfin, en résumé, "set names" permet de préciser à MySQL avec quel encodage tu communiques avec lui (et non celui qu'il utilises, car ça, il le sait déjà), ce qui lui permet de faire, ou non, le transcodage de son côté lorsque tu lui envoies de données, et lorsqu'il t'en envoie.

Malgré toute la maitrise que l'on peut avoir dans l'encodage, il est quand même préférable d'utiliser le même. En plus, iso-8859-1 est un traitre car lorsqu'un utilisateur sous windows remplit des questionnaires sous iso-8859-1, il insère sans aucun problème des signes tels que l'euro, qui rappelons-le, n'existe pas en iso-8859-1. Il en est de même pour MAC, qui insère (là c'est plus une hypothèse mais d'une expérience subie) des caractères très proches de l'iso visuellement mais propre à MAC. Et le pire (Quoique), c'est que le signe euro enregistré sous iso-8859-1 (non enregistré sous le code ASCII étendu "euro" car iso-8859-1 n'en possède pas), s'affiche pépère dans la page HTML, même sous Linux, par exemple. Sous MAC, je ne sais pas. En gros, tu dis à ton navigateur de lire de l'iso-8859-1, mais lui, il lit de l'AINSI. Utf-8 a l'avantage de mettre tout le monde d'accord.

Purée ! La migraine !

Bon, mais :

- Etant donné que les pages php fonctionnent en local.
- Etant donné que ce sont ces mêmes pages qui ont été copiées sur le site disponible sur ovh.
- Etant donné que la base de données en local fonctionne parfaitement en local.
- Etant donné que la base sur ovh est une copie de la base en local.
- Etant donné que les pages que j'ouvre grâce aux scripts php signalées plus haut, produisent du utf8, sauf pour ce qui concerne des données d'une table de la base qui elles, toujours d'après firefox sont en iso 8859-1 on peut dire (il me semble) :

- Que le problème se situe dans la base, car les données ont été modifiées entre la base en local et la copie.
- Ou bien que les données sont les mêmes, mais que le problème se situe entre la lecture des données et le transfert (donc Y dans l'exemple, non ?).

Or, si je fabrique une autre table par phpmyadmin sur ovh; que je rentre les données toujours dans phpmyadmin sur ovh; que je donne à cette table le nom de celle qui déconne; et que je l'ouvre avec mon script php, j'obtiens :
Le même problème.

Ce qui tend à dire que le problème se situe bien au niveau du transfert.

Mais je peux me tromper; et quand bien même ce ne soit pas le cas, ça ne me donne pas la solution pour autant.


Bref, ça m'énerve.

Bon, j'ai cru avoir résolu le problème; je dis bien cru.

J'ai systématiquement envoyé comme première requète à chaque connexion à la base : SET NAMES utf8.

Résultat, mes données en utf8 s'affichent correctement.

Mais voilà...

Je continue ailleurs, car apparremment, le problème ne vient plus des bases de données (enfin, j'en sais rien).

Merci pour l'aide.