Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Bonjour à tous,
J'ai créé une base via phpMyAdmin comme suit :
- base de données en utf8_general_ci
- interclassement de toutes les tables en utf8_general_ci
- interclassement des champs de table en utf8_general_ci
Dans mon layout, j'ai intégré :
- appendHttpEquiv('Content-Type', 'text/html;charset=utf-8')
Lorsque je fais une insertion de ééééé via ZF, je vois dans phpMyAdmin ceci ééééé !
J'ai tenté une connexion via Mysql Query Browser, pensant que peut-être l'encodage des pages via pma est incorrect, mais le résultat est le même...
Avez-vous une idée sur la raison de tout cela ?
Une solution pour faire marcher tout ca de concert (ZF + MYSQL) ??
Merci par avance et bonnes fêtes !
Hors ligne
c'st tout con, par défaut mysql retourne les résultats en latin. Pour ce faire, lors de l'initialisation de ta base de donnée, si tu passe par les fichiers de config tu fais ceci:
resources.db.adapter = PDO_MYSQL resources.db.params.charset = UTF8 ;c'est le truc qui nous intéresse ici resources.db.params.host = localhost resources.db.params.username = root resources.db.params.password = resources.db.params.dbname = mabase resources.db.isDefaultTableAdapter = true
Hors ligne
Merci pour cette réponse.
Je ne passe pas par un fichier de config, mais un modele DB (solution surement discutable ?).
J'ai donc fait la chose suivante :
public static function connect() { $connParams = array ( "host" => "localhost", "port" => "3306", "username" => "root", // Oui, ca n'est pas très sécurisé, mais c'est un test local ! "password" => "", "dbname" => "xxx", "charset" => "utf8" ); $db = new Zend_Db_Adapter_Pdo_Mysql ( $connParams ); return $db; }
Il me semble, même si la méthode est différente, que j'utilise déjà le charset UTF-8.
Je suis tenté de conclure que le problème ne vient pas de la.
Qu'en pensez-vous ?
Dernière modification par lesdoudous (30-12-2009 08:47:30)
Hors ligne
@version $Id: Mysql.php 16942 2009-07-22 04:03:09Z ralph $ if (!empty($this->_config['charset'])) { $initCommand = "SET NAMES '" . $this->_config['charset'] . "'"; $this->_config['driver_options'][1002] = $initCommand; // 1002 = PDO::MYSQL_ATTR_INIT_COMMAND }
Dernière modification par 3uclide (30-12-2009 10:46:51)
Hors ligne
Merci Mr.MoOx !
Peux tu éclairer ma lanterne sur la raison qui fait qu'on doive à la fois spécifier le charset ET la connexion en UTF-8 ?
Hors ligne
J'utilise pourtant une version récente...
const VERSION = '1.9.5';
PS : 3uclide, j'ai vu ton message après avoir posté le mien :s
Hors ligne
il me semble que pour le moment par défaut c'est en latin et non en utf8 (devrait être définitivement en utf8 avec php6)
cela vient de mysql et non de php, enfin à voir
Hors ligne
Et si tu fais un uft8_encode/uft8_decode sur tes données ça donne quoi?
Hors ligne
Le problème est résolu en effectuant la chose suivante :
public static function connect() { $connParams = array ( "host" => "localhost", "port" => "3306", "username" => "root", "password" => "", "dbname" => "mrj-web", "charset" => "utf8" ); $db = new Zend_Db_Adapter_Pdo_Mysql ( $connParams ); $db->query("SET NAMES UTF8"); return $db; }
Avant, ca, j'utilisais des utf_decode uniquement... il manquait peut être un encode avant l'insertion en base
Dans la mesure ou j'ai ajouté le SET NAMES UTF8, je n'ai plus besoin d'ajouter de fonction d'encodage / décodage !
Ce que je ne m'explique pas, c est que la portion de code que tu proposes, 3uclide, si elle est présente dans ZF 1.9.5, ne s'exécute pas (pour une raison que j'ignore...).
Hors ligne
normalement si tu dis ici que t'es en utf8, paramettrant tes pages web en utf8 (côté vue et meta) tout sera en utf8.
Ensuite le set names utf8 est aussi obligatoire car mysql réencode tout en latin avant de t'envoyer les données. Un utf8_decode est inutile ici.
Hors ligne
T'utilise quel moteur pour ta base MySQL?
cf: http://php.net/manual/fr/ref.pdo-mysql.php
Hors ligne
Si par moteur tu entends type alors c'est du Myisam pour les tables (bizarrement le type de la base est innoDB...).
Si tu parles de l'extention, je ne spécifie rienn (ni PDO, ni mysql, ni mysqli !).
Si tu parles d'autre chose... Et bien je donne ma langue au chat (qui sera à mon avis bien embêté de savoir quoi en faire).
Hors ligne
myisam est le moteur par défaut pour une table qui n'a pas de lien avec une autre able. Aucune journalisation n'est vraiment effectuée pr mysql et il n'y a pas de réel validation des données (si ta requête plante en plein millieu, il te valide la moitié)
innoDB lui offre une journalisation et permet de faire des liens avec d'autres tables. Un peu plus lent que le moteur myisam mais plus sûr car lui permet une réelle validation des données. (vu en cours d'oracle/mysql)
Ces parties n'ont rien à voir avec l'encodage.
Ensuite, ni pdo, ni mysql, mysqli ne gèrent l'encodage qui sort. C'est le serveur mysql qui le traite et, pour une raison que j'ignore, il ne ressort par défaut que des résulats encodés en Latin (même pour une table en utf8)
Les seuls moyens sont le "SET NAMES UTF8" et/ou la ligne d'encodage au niveau du fichier .ini (qui doit permettre d'effectuer cette requête en arrière plan)
J'espère ne pas avoir dit de bourdes sur ce point.
Hors ligne
Avertissement
Prenez garde : certains types de tables MySQL (moteur d'enregistrement) ne supportent pas les transactions. Lorsque vous écrivez du code de base de données transactionnel en utilisant un type de table qui ne supporte pas les transactions, MySQL prétendra qu'une transaction était initiée correctement. De plus, toutes requêtes DLL publiées enverra implicitement toutes les transactions en attente.
myisam fait partie de ceux qui ne supportent pas les transactions. C'est pourquoi le paramètre passé dans ton fichier ini ne fonctionne pas (charset).
Hors ligne
3uclide, si j'ai bien compris :
cela signifie que le fichier .ini est utilisé pour instancier la connexion, mais que l'info n'est pas utilisée lorsque la requête est transmise à MySQL ?
Hors ligne