Bonjour à tous !

J'ai une base de donnée mysql (mysql 4.1.9, language : utf8, interclassement : utf8_general_ci, php 4.3.9) sur mon hébergeur (eurower) dont certaines données contiennent des caractères spéciaux.
Lorsque j'exporte les tables, les accents sont transformés en "ë" ou "é" dans le fichier sql. Lorsque je veux transférer ces données sur free (mysql 4.0.22, même language et même interclassement que sur eurower, php 4.3.10) les caractères apparaissent avec les signes bizarres dans les pages des scripts utilisant la base de donnée...

Est-ce que quelqu'un à une explication et une solution ?

Merci d'avance !

J'ai le même problème. Ce n'est pas ton hebergeur mais ton OS.

En effet, le problème semble venir de windows 98. Quelqu'un sait comment le résoudre ?

Qu'est-ce que des accents font dans le script ?

Pour les noms des bases / tables il ne faut pas en mettre

Pour le contenu il faut tout convertir avant d'inserer

à => & # 2 2 4 ;
é => & # 2 3 3 ;
è => & # 2 3 2 ;

etc...

J'ai résolu le probleme en ne zippant pas le fichier généré, mais en faisant un copier/coller de l'affichage.

En ne zippant pas le fichier puis en convertissant UTF8 > ASCII avec UltraEdit, ça marche, les caractères redeviennent corrects.

Pour les noms des bases / tables il ne faut pas en mettre
Pour le contenu il faut tout convertir avant d'inserer
à => & # 2 2 4 ;
é => & # 2 3 3 ;
è => & # 2 3 2 ;

Tout à fait exact !
Mais tu peux aussi utiliser les codages HTML suivants :
à => à
é => é
è => è
etc.

Je rencontre le meme problème.
En local je suis sous windows 2000 avec easyphp1.8 (donc mysql 4.1.9), avec toutes mes tables en utf_general_ci.

Chez mon hébergeur 4.0.24 sans gestion de l'interclassement avec pour seule configuration possible le choix du langage (fr-utf-8).

Quand j'exporte des tables du local vers l'hébergeur, les caractères spéciaux merdent. les "é" sont remplacés par des "é". Par contre, tout apparait bien dans phpmyadmin (qui doit tout encoder/décoder au meme format), mais si je saisi un "é" dans une table via phpmyadmin il apparait aussi en "é" lors de mes requetes.

Si je converti, avec ultraedit, le fichier .sql d'UTF8 vers ASCII, la le caractère "é" (sur une saisie déja présente avant l'exportation) apparait normalement dans le fichier .sql, il apparait normalement lors de mes requetes, mais par contre ils apparaissent sous forme de "?" sous phpmyadmin. Et la, si je saisi un "é" sous phpmyadmin, il ressort en "é" lors de mes requetes. Ca laisse à penser que les données présentes lors de l'importation sont bien passées en ASCII, mais que la table est déclarée en UTF, ou un truc dans le genre (c'est pas clair...). Ce qui fait que phpmyadmin, qui doit récupérer ces infos, affichent le "é" en "?" car il le prend pour de l'UTF (par exemple) au lieu de l'ASCII, et si on lui dit a lui d'entrer un "é", il le saisi en UTF, donc avec un "é" lors des requetes.

Bref tout ca pour dire que c'est un peu lour de faire 2 requetes de création de table strictement identiques coté hébergeur et que ces tables n'utilisent pas le meme format en fonction du format du fichier (je suppose), sans qu'on puisse intervenir directement dessus.

je ne me suis pas encore beaucoup documenté sur le sujet (google m'a pas trouvé grand chose de plus que ce topic à premiere vue), mais je sens que ca va me gonfler cette histoire pas nette...

Je vais essayer exportant juste les tables, sans les données, pour voir si il s'obstine toujours à me sortir des "é" si je rentre à la main des "é" pour tester. Si ca passe j regarderais si il y a moyen d'exporter les tables vides pour qu'elles soient crées au format par défaut de l'hébergeur, pour ensuite y exporter les données d'une facon ou d'une autre

Haaaa les encodages, comme c'est fascinant.

Personnellement, je ne te conseille pas d'utiliser UTF-8 si tu ne comptes pas utiliser d'autres langages que le français, l'anglais ou autres ne nécessitant pas l'utilisant d'UTF-8.

En effet, le support d'UTF-8 par PHP n'est pas natif et nécessite la compilation de l'extension mbstring. Cette extension sera nécessaire si tu désires réellement implanter UTF-8 dans tout tes scripts. Cette extension est nécessaire puisque les fonctions natives de PHP ne supporte pas les caractères multi-octets. (la fonction strlen() par exemple qui retournera une valeur erronée sur une chaine UTF-8)

De plus, si tu désires gérer UTF-8, il te faudra afficher tes pages en UTF-8 et donc indiquer un encodage d'UTF-8 dans le head de ta page HTML ou alors configurer Apache afin d'indiquer au client qu'il envoie des pages UTF-8.

Pour ce qui est des "é", c'est un problème courant pour les non-initiés à l'utilisation de ce type d'encodage. Le caractère "é" sera encodé sur 2 octets et lorsque le client n'est pas configuré pour afficher la page en UTF-8, alors il prendra les 2 octets nécessaires à l'affichage du "é" séparément, affichant ainsi "é". Une mauvaise configuration du client ou des entêtes créera toujours ce genre de "problèmes".

Donc si vous désirez utiliser ces encodages, il faudra adapter votre manière de coder et peut-être également l'éditeur que vous utilisez puisque les fichiers enregistrés devront également être encodé en UTF-8. Les conversions à la "barbare" dans des éditeurs pour ensuite réinsérer votre chaine de caractère dans un formulaire afin de faire "fiter" le tout n'est pas une bonne approche. Il suffit de régler votre client convenablement.

Bref, la gestion de l'encodage UTF-8 devient vite emmerdant lorsque l'on a pas les bons outils et les connaissances nécessaires à son utilisation. Personnellement, je vous conseille fortement de conserver l'encodage iso-8859-1 (latin1/latin1_swedish_ci pour MySQL) afin d'éviter tous problèmes et complications.

Ça me fait toujours marrer voir des gens discuter d'un sujet "nouveau" sans savoir exactement de quoi il parle : chacun tentant d'expliquer à sa manière les expériences qu'ils ont eu avec le problème. Je ne dis pas cela de manière méchante, je dis simplement qu'il est parfois mieux d'aller se renseigner afin de pouvoir en savoir plus sur le sujet.

albat > L'utilisation des entitées n'est pas recommandé puisque l'encodage permet justement d'éviter ce genre de tours de passe-passe. Et de plus, je ne crois pas que tu sois intéressé à entrer tout en entitées dans un formulaire phpMyAdmin.

Oui entre temps je me suis renseigné un peu plus (c'etait 2h du mat hier soir j'avais plus trop le temps de chercher, et voulais laisser un message en suspend pour avoir des réponses 24h apres).
Effectivement, les contraintes de l'utilisation de l'UTF-8 étant ce qu'elles sont, je vais rester en ISO-8859-1, ne serait ce que pour le support de PHP et le fait que mysql ne supporte réellement cet encodage qu'a partir de la 4.1.9 (que mon hébergeur ne semble pas pressé de mettre en place). Je vais donc passer un moment à reconvertir mes bases en ISO et modifier à la main les éventuels "déchets".
Il risque d'y avoir des caractères japonais par ci par la mais j'utiliserais directement les expressions unicode pour ceux la, ce sera plus simple.
De même il ne devrait pas y avoir de symbole €, et si il y en a, j'utiliserais l'entité à priori, car l'ISO-8859-15 semble moins bien supporté


La ou tu m'a apris quelque chose, c'est sur le fait que l'encodage ISO-8859-1 sous mysql est bien le latin1_swedish_ci. J'avais bien remarqué que c'etait l'encodage par défaut, et pensais que c'etait un problème de config par défaut du phpmyadmin livré avec easyphp 1.8. J'allais utiliser plutot latin1_general_ci pour "repasser" mes tables en ISO (a quoi correspond finalement le latin1_general_ci ?).

Au passage, toujours avec le phpmyadmin livré avec easyphp 1.8, au niveau du langage, il n'y a le choix qu'entre divers encodages UTF-8, aucun ISO. Et le jeu de caractères pour mysql est défini (et non changeable) à UTF-8 aussi, ce qui fait que si je saisi un "é" depuis phpmyadmin, meme sur une table ISO, il est saisi sous forme de "é" UTF-8, du coup en exportant la table sur le mysql 4.0.22 de mon hébergeur, ca crée apparemment bien des tables iso mais ca interprete le "é" (saisi en UTF par phpmyadmin) en iso et sort donc l'affiche incorrectement.
J'essaye de configurer le charset par défault de phpmyadmin et la config qui permet d'activer les charset non unicode, mais sans succès pour l'instant (pas encore fait le tour). J'ai activé l'extension iconv, activé le "charset recoding" de phpmyadmin.
J'ai l'impression que ce foutu phpmyadmin 2.6.1 est fait pour inciter à utiliser UTF-8 et non l'ISO, avec tous les problèmes de compatibilité avec les versions précédentes que ca comporte... bref faut que je tourne encore un peu en rond...


Sinon moi aussi ca me fait régulierement marrer ceux qui discutent sans savoir et souvent sans chercher, mais, meme si je me suis probablement mal exprimé (j'en avais un peu marre, dodo time et marre de perdre du temps au lieu de coder), je savais ce à quoi correspondaient les divers encodages et ne comptais pas juste poser mes questions et attendre qu'on cherche à ma place. Je manquais surtout d'infos concernant, en pratique, le support et la compatibilité de ces encodages. Apres 1 ou 2h de lecture ca va mieux sur ce point

Bon j'ai un début d'alternative pour se dépatouiller avec easyphp 1.8, phpmyadmin 2.6.1 mysql 4.1.9.
Lors de l'importation d'un fichier sql on peut indiquer à phpmyadmin le format de ce fichier, ce qui permet deja qu'il importe correctement en local.
Ensuite en activant le paramêtre "AllowAnywhereRecoding", et en chargeant l'extension apache iconv, on active la possibilité de définir le format auquel on veut exporter les données. Ce qui permet de définir plus clairement et sans editeur externe ce qu'on fait. Ca permet de pouvoir exporter vers le mysql 4.0.xx de l'hébergeur les données du 4.1.9 local en ISO quelque soit le format local retenu.

Ce qui m'intrigue par contre, c'est que quelque soit le format local des tables, UTF ou ISO, ca s'affiche correctement dans a peu prêt toutes les conditions, en saisissant depuis phpmyadmin sur une table ISO, sur une UTF, en affichant ca sur le site depuis des tables UTF ou ISO. Ca me parait d'ailleur bizare, doit me manquer une info à ce sujet.

Enfin bon je devrais pouvoir continuer à bosser en local en mettant tout en ISO bien que phpmyadmin s'obstine a rester, lui, en UTF (vu que malgres ca j'ai pas de pb d'affichage, aussi bien sous phpmyadmin que sur mes pages web). Et je pourrais aussi sans trop de pb exporter ca proprement en ISO chez l'hébergeur.
D'ici à ce que l'hébergeur passe sous mysql 4.1.9 j'aurais surement une meilleure maitrise de cette gestion "pas vraiment intuiive" de l'encodage sous phpmyadmin 2.6.1

Attention, il ne faut pas confondre le langage de l'interface phpMyAdmin avec l'encodage supporté par MySQL. utf8-fr est en fait le langage et l'encodage utilisé pour l'interface de phpMyAdmin. Normalement, il ne devrait pas avoir de problème d'encodage lors de l'utilisation de phpMyAdmin puisque les convertions se font automatiquement.

Bonjour,

Je voudrais continuer un peu sur le sujet, mon problème est proche mais pas identique :

Je ne suis qu'en local. J'ai laissé l'encodage de mysql ce que c'était latin1 swedish.

J'accède sans difficultés à la base par l'intermise de phpmyadmin (aussi bien pour ajouter des données que pour les extraire). MAIS : quand j'utiliser ma propre interface écrit en php, ça ne marche pas, j'ai un message d'erreur indiquant que j'ai une erreur dans la requete.

L'erreur provient de l'utilisation des caractères spéciaux français (éèûç etc), et non de mon code (qui marche très bien sur linux).

phpmyadmin utiliser l'instruction CONVERT pour convertir du uft-8 en latin1... Je vois mal pourquoi ? Faut-il que j'ajoute dans mes scripts php que j'utilise latin1 (ou dans les pages html - j'utilise des templates donc c'est séparé).

Merci de vos évenuelles réponse,

[email protected]

Je remonte ce sujet car j'ai le même problème.

Copie directe des données sql d'un interface Easyphp 1.7 à 1.8, et problème avec les accents à la lecture au niveau du code (nickel en html). Donc n'y a-t-il pas une variable à changer dans la configuration du php ou de mysql pour spécifier l'encodage utilisé ?

Ca me semble énorme que la manière de dialoguer entre le php et mysql change d'encodage sans retour en arrière d'une version à l'autre...

Personnellement j'ai enfin réussis à exporter ma base de donnée avec mes accents en activant l'extension php_iconv.dll du php.ini et en modifiant le fichier config.inc.php du phpmyadmin en mettant la valeur $cfg['AllowAnywhereRecoding'] à TRUE.

Ensuite lors de l'exportation il suffit de choisir Jeu de caractères du fichier: iso-8859-1

Voilà c'est tout bon de mon côté