Je suis effectivement tombé sur cette possibilité récemment! Ca fonctionne dans doctrine, mais je n’avais pas pu tester pour propel.

C’est chose fait donc! Encore un billet à mettre à jour.

Merci en tout cas!

J’ai eu aujourd’hui moi aussi le même problème, autant dire que les japonnais qui devaient remplir le site qu’on développe s’arrachaient les cheveux!

Et j’ai trouvé la solution:
dans le schema.yml il faut rajouter au début:
options:
type: INNODB
collate: utf8_unicode_ci
charset: utf8

et le tour est joué :)

C’est tout de même bizarre que malgré les configurations (database.yml, propel.ini …) ça ne se fasse pas par défaut!

@naholyr Grand merci pour ces explications, j’avoue que personnellement c’est le genre de truc qui m’intéresse beaucoup mois, du coup je suis tjrs content que des devs plus sages se risque à des explications claires ;)

Tu permets que j’étaye mon billet avec les informations supplémentaires que tu as apportées?

Il est important de noter en revanche que le collate du client de connexion (l’option « encoding » dans le databases.yml) est très très important lui aussi, car quelle que soit sa valeur on n’aura pas de problème apparent, sauf le jour où on change de système parce que le collate du client par défaut est défini au niveau du système, et il vaut donc mieux ne pas compter dessus (beaucoup de Windows le laisseront en latin1, beaucoup de Linux le passeront en utf8).

Si on a tout en utf8 (base, tables, page, chaines dans le code), mais que le client est en latin1, voici ce qui se produit lors d’un insert :
1. construction de la requête : chaine en utf8 (« été » = 5 octets)
2. le client reçoit la donnée, et l’envoie dans les tables : il est en latin1 et le champ cible est en utf8, donc il convertit.
3. Dans le champ de la table, on a « Ã©té » en utf8 (soit 9 octets).
Et voici ce qui se produit lorsqu’on récupère la donnée :
1. le client lit le champ de la table « Ã©té » (utf8, 9 octets).
2. il est en latin1, et le champ était en utf8, donc il convertit en « été » (utf8, 5 octets).
3. on reçoit la bonne chaine en utf8.

Du coup tout s’est passé de manière transparente, tout semble fonctionner correctement sauf que :
– le jour où le système change d’encodage c’est la merde (à la rigueur on respécifiera « latin1″ à ce moment là, mais avant de comprendre pourquoi en mettant « utf8″ ça ne corrige rien on va tourner un moment ;))
– le jour où on fait un restore de la base en ligne de commande, ça va foirer (parce que l’encoding par défaut du client se base sur l’encoding du shell courant, en général utf8).
– on a dans la base des chaines trop grosses puisqu’encodées une fois de trop en utf8.

Voilà, je profitais de cet article pour parler de ce problème souvent latent et insoupçonné, mais pourtant présent ;) Perso j’ai du corriger tous mes sites (pas que ceux en Symfony) car ils avaient tous ce problème vu que je ne spécifiais jamais l’encoding client.

Ah du coup, il faut aussi parler des solutions :
– Dans Symfony, spécifier « encoding: utf8″ dans les options du databases.yml.
– Dans les autres cas, la première requête après la connexion doit être « SET NAMES UTF8″.
Une fois ceci fait, on doit observer que toutes les chaines du site ont sauté. Si ce n’est pas le cas c’est que l’encoding client par défaut était déjà utf8 : tant mieux :)
Sinon, il faut faire un export de la base avec un client en encoding « latin1″ (on récupèrera alors les chaines en utf8 correct), puis faire une restauration avec un client en encoding « utf8″ :
$ mysqldump -u user -p –encoding=latin1 ma_base > dump.sql
$ mysql -u user -p –encoding=utf8 ma_base < dump.sql

En fait par défaut MySQL est en latin1 et du coup, nous avons une base en Latin1 avec des données en UTF8 dedans. Bref un beau bazard car dès que l’on a besoin d’accéder aux données autrement que par symfony, on a des problèmes.

J’ai finis par faire un batch qui converti les champs en latin en utf8 [1].

Je le donne au cas où:

http://fr.pastebin.ca/1431312