Discussion :

[eprevot]

Bonjour tout le monde

Dans ma base j'ai une donnée avec le signe euro "€".
La table est en utf8-general-ci, la colonne aussi.

Je récupère cette donnée dans un script PHP, et je l'utilise pour créer un message envoyé par email.
Le fichier PHP est encodé en utf-8, j'envoie l'email avec le charset=utf-8

Problème : dans l'email je ne lis pas "€" mais "?"

Si j'écris le signe "€" directement dans mon fichier PHP (sans le récupérer depuis ma BDD MySQL), alors l'email affiche bien le signe €.
Et si je fais utf8_encode() sur ma donnée récupérée depuis la BDD, alors l'email affiche bien le signe €.
Cela me fait penser que le problème vient soit de la BDD, soit de la liaison BDD/PHP ?

J'ai lu que quand il est affiché "?" c'est que la donnée est encodée en ISO-8859 alors qu'on essaie de l'afficher en utf-8. Mais je ne vois pas où est-ce qu'il pourrait y avoir de l'ISO, et je ne sais pas quoi/comment vérifier.
C'est bien possible que la base ait été créée avec tous les types en latin1-swedish-ci, puis les données insérées, puis tous les types modifiés en utf8-general-ci via phpMyAdmin. Je sais pas si ça peut créer des problèmes de conversion...

Merci de m'aider !

[ABCIWEB]

Avant de lire tes données depuis la table avec php, il faut dire que tu utilise l'utf-8 avec une requête du genre : query("SET NAMES 'utf8'");
L'as-tu fais ?

[eprevot]

J'utilise PDO pour parler à la BDD depuis PHP.
Je ne fais rien qui ressemble à SET NAMES...

Je ne sais pas si il y a besoin, sur mon phpMyAdmin je vois les variables suivantes :

character set client     = utf8
(Valeur globale)           latin1
character set connection = utf8
(Valeur globale)l          latin1
character set database   = latin1
character set filesystem = binary
character set results    = utf8
(Valeur globale)           latin1
character set server     = latin1
character set system     = utf8
collation connection     = utf8_general_ci
(Valeur globale)           latin1_swedish_ci
collation database       = latin1_swedish_ci
collation server         = latin1_swedish_ci

[papajoker]

Bonjour,
c'est a la connexion que l'on rentre ce parametre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$myPDOsql = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$myPDOsql->exec('SET NAMES utf8');

il peut parfois être passé dans le constructeur de PDO.

[ABCIWEB]

Pour préciser la réponse de papajoker le "parfois" veut dire avant PHP 5.3.6.
Donc si tu utilise PHP 5.3.6 ou supérieur tu peux faire une connexion dans ce genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
// l'option [PDO::ATTR_EMULATE_PREPARES] = false est très recommandée.
 
$pdo_options = null;
$pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
$pdo_options[PDO::ATTR_EMULATE_PREPARES] = false;
$pdo_options[PDO::ATTR_DEFAULT_FETCH_MODE] = PDO::FETCH_OBJ;
 
$connexion = new PDO('mysql:host=localhost;dbname=test;charset=utf8', 'root', '', $pdo_options);

Je donne cet exemple avec les options parce que alternativement tu peux aussi passer le charset dans les options (si tu trouves cela plus lisible ou pour les versions < PHP 5.3.6)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$pdo_options = null;
$pdo_options[PDO::ATTR_ERRMODE] = PDO::ERRMODE_EXCEPTION;
$pdo_options[PDO::ATTR_EMULATE_PREPARES] = false;
$pdo_options[PDO::ATTR_DEFAULT_FETCH_MODE] = PDO::FETCH_OBJ;
$pdo_options[PDO::MYSQL_ATTR_INIT_COMMAND] = "SET NAMES utf8";
 
$connexion = new PDO('mysql:host=localhost;dbname=test', 'root', '', $pdo_options);

...pour dire qu'il y a plusieurs façons d'indiquer le charset

[eprevot]

Merci à tous, c'était bien ça !
Passer le charset dans le constructeur de PDO...

Par contre cette écriture n'a pas fonctionné dans mon cas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new PDO("mysql:host=monsite.com;dbname=mabase;charset=utf8", $username, $password);

J'ai du écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

new PDO("mysql:host=monsite.com;dbname=mabase", $username, $password, array(PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8"))

Peut-être que "SET NAMES" modifie plus de variables que juste "charset=utf8" ?

Petite question : Est-ce normal qu'il faille faire ça si ma base est vraiment en utf8 ? C'est pas ma base qui est mal configurée ?

[eprevot]

Je fais quelques tests et je ne comprend pas l'impact de SET NAMES.

Je passe une colonne de ma table en latin1-general-ci.
Je laisse les variables de la base de données character_set_client, character_set_connection, character_set_result en utf8.
J'appelle PDO avec SET NAMES latin1.

Le fichier PHP qui récupère cette donnée est en utf8, selon mon éditeur de texte. Il crée un email écrit en dur avec aussi la donnée récupérée. L'email a le header Content-type: text/plain;charset=utf-8

Quand je reçois l'email, les accents de la chaîne de caractère récupérée depuis la base sont bien affichés MAIS les accents du message en dur dans mon fichier PHP sont mal affichés, comme quand du iso-8859 essaie d'afficher de l'utf8 (é devient A©).

Je m'attendais à ce que ce soit l'inverse !
La base donne des résultats en utf8 et PDO se connecte en latin, alors il devrait mal afficher la donnée. Alors que mon texte en dur dans le code PHP n'a pas changé, quand je fais SET NAMES utf8 il s'affiche bien, je ne vois pas pourquoi les options de PDO influent dessus, le texte est en dur dans mon code PHP !

[ABCIWEB]

Petite question : Est-ce normal qu'il faille faire ça si ma base est vraiment en utf8 ? C'est pas ma base qui est mal configurée ?

Oui c'est normal. Même si ta base est en utf-8 il faut dire à PDO quel charset tu utilises. Il faut lire un tuto sur l'utf8 si tu veux en savoir plus. Les termes "tuto utf8" te donneront de bons résultats dans google.

Pour ta seconde question, si tu fais des changements en cours de route tu peux obtenir des résultats déroutants. Cela vient du fait qu'à la fois le format d'enregistrement et le format de lecture des données rentrent en jeu et cela en interaction avec les entêtes ou les requêtes que tu envoie pour spécifier le charset. Bref je te recommande de lire un tuto pour en savoir plus.

Pour résumé, si tu ne veux pas avoir de problèmes il faut être cohérent du début à la fin des étapes d'enregistrement et de lecture des données et cela inclus tout, le fichier dans lequel tu écris ton script, les entêtes du serveur, l'enregistrement et la lecture des données etc. y compris certaines fonctions comme htmlentities dont on doit spécifier le charset (utiliser htmlspecialchars à la place est suffisant et plus pratique).

[eprevot]

J'ai lu en détails ce document : http://antoun.developpez.com/mysql5/jeux-collations/
Il est bien fait je trouve, ça m'a beaucoup éclairé, mais tout ça reste encore un peu compliqué à appliquer.

Quand tu dis "il faut être cohérent du début à la fin", ça veut dire que je ne peux pas avoir une base en latin1 et un site en utf8 ?

Dans ma base il n'y a pas de caractères spéciaux, donc autant qu'elle soit en latin1 pour avoir de meilleures perfs. Mais dans mon code PHP et mes pages HTML, j'ai des caractères spéciaux, donc je voudrais le garder en utf8.

[Invité]

Bonjour,

Dans ma base j'ai une donnée avec le signe euro "€"...

Dans ma base il n'y a pas de caractères spéciaux...

N'y aurait-il pas une incohérence ?

=> Passez à l'UTF-8 sans manquer une étape

[eprevot]

C'est-à-dire que depuis hier soir, j'ai eu le temps de lire de la doc sur l'utf8 et j'ai vu que mes SELECT risquent de prendre plus de temps si j'ai ma base en utf8 plutôt qu'en latin1.
Or le signe € est le seul caractère spécial que je voulais ajouter dans ma base, et je peux m'en passer si ça veut dire perdre en perf.

EDIT : Et bravo pour le document "Passez à l'utf8 sans manquer une étape", c'est très pratique !

[ABCIWEB]

NON !! on ne bidouille pas entre latin et utf8 sous prétexte que tu vas gagner du temps dans tes select.
Etant donné que utf8 peut afficher tous les caractères latin + beaucoup d'autres, tu mets tout en utf8 et point barre. Fais autrement uniquement si tu veux te prendre la tête ou si tu n'as pas le choix.

[eprevot]

Ben c'est quand même important d'avoir une base qui répond rapidement !
Le problème c'est que je sais pas dans quelle mesure l'utf8 ralentira les requêtes.
Si ça ralentit beaucoup, ça vaut le coup de se prendre un peu la tête.
Et puis une fois que tout est configuré, si c'est clair et non de la magie noire, c'est pas si prise de tête... si ?

[ABCIWEB]

Le problème c'est que je sais pas dans quelle mesure l'utf8 ralentira les requêtes.

Quelles sont tes sources ?

[papajoker]

Le problème c'est que je sais pas dans quelle mesure l'utf8 ralentira les requêtes.

Un lien vers la source please.

on va peut-être gagner 0,01 secondes sur une requete mal faite qui dure 1,5seconde
et pour le moteur ... un choix?

[ABCIWEB]

Et si c'est pour dire que le codage en utf-8 prendra plus d'octets et donc plus de place dans la bdd, il faut savoir qu'il n'y a que les caractères accentués et les caractères spéciaux qui seront codés sur plusieurs octets (2 par exemple pour les caractères accentués). Cela ne varie donc pas du simple au double mais beaucoup moins. L'utf8 est optimisé pour prendre le minimum de place possible.

C'est la première fois que je lis un sujet ou l'on se pose cette question de ne pas utiliser l'utf-8 pour des problèmes d'optimisation bdd... A mon avis cela ne doit pas être un vrai problème

Par contre tu risque d'en avoir de très gros en termes de pertes de temps si tu poursuit trop longtemps dans cette réflexion, et d'autant plus si tu la mets en application

Pour t'en convaincre, cherches par exemple "optimisation requêtes sql" dans un moteur de recherche et tu auras certainement des réponses qui parlent d'optimisation du type des champs, de la création d'index etc. mais pas de charset préférentiel. Le problème est ailleurs !

Après si tu as toujours des craintes concernant la montée en charge, dis-toi que facebook est codé en php et utf-8

Et si cela ne suffit pas et que tu as du temps à perdre tu peux aussi faire des bench pour te rassurer.

[eprevot]

Voila ce que j'ai lu qui m'a inquiété :
http://programmers.stackexchange.com...ing-over-utf-8
http://www.adayinthelifeof.nl/2010/1...elds-in-mysql/

Le 2eme lien parle de l'importance des index pour optimiser sa base, je ne maîtrise pas bien les index. Alors oui, le charset n'est pas le seul problème pour moi, mais c'est celui qui se pose aujourd'hui

Quand on lit la plupart des sujets/tutos sur l'utf8, ils ne parlent que des avantages d'utf8 ou alors ne se posent même pas la question, c'est à se demander pourquoi quelqu'un utiliserait autre chose que l'utf8...
Si c'est mieux, je veux bien mais je veux en être convaincu !

et pour le moteur ... un choix?

Qu'est-ce que tu veux dire ? La plupart de mes tables sont InnoDB si c'est la question.

[ABCIWEB]

Y'a pas de quoi t'inquiéter pour si peu. La technologie évolue et comme a chaque fois que l'on fait quelque chose en plus, cela prend un peu plus de ressources. Ce qu'il faut voir c'est le rapport avantages/inconvénients.

c'est à se demander pourquoi quelqu'un utiliserait autre chose que l'utf8...

Bah évidemment puisque c'est le nouveau standard
Faire l'inverse relèverait du masochisme pour les nouveaux projets.

Tu pourrais aussi te demander pourquoi tu es seul à te poser cette question.

Parce qu'en poussant le bouchon un peu plus loin, tu pourrais dire aussi qu'il ne faut pas utiliser pdo car il est un peu moins rapide que mysql. Et tu ne devras pas utiliser la POO parce que du procédural avec quelques fonctions c'est plus rapide etc. Continues dans ce sens et t'as pas fini de débuter...

Il est fondamental d'utiliser un standard unique pour l'encodage. Cela simplifie grandement les choses. Ne serait-ce que pour permettre de dire qu'en japonais "bonjour" s'écrit "こんにちは" et "مرحبا" en arabe...
...ou quand tu auras a utiliser une lib comme jquery qui ne supporte que l'utf-8...
... et à peu près tous les modules que tu voudras insérer sur ton site.

[ABCIWEB]

Bon j'espère que tu as résolu ta question sur l'utf-8 et que tu es passé à autre chose (en choisissant l'utf-8 évidemment).

Parmi les questions plus intéressantes je signale que j'ai mis le commentaire ci-dessous exprès pour les nouveaux venus dans pdo :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

// l'option [PDO::ATTR_EMULATE_PREPARES] = false est très recommandée

Je vois que tu ne l'a pas retenu pour faire ta connexion, j'espère que c'est en connaissance de cause : tu risques d'avoir des pb dans certaines circonstances par exemple si tu passes des tableaux dans execute car dans ce cas l'émulateur pdo "caste" les variables en chaines de caractères (plus exactement il met des ' autour des entiers). Or si la requête attend un entier, ce qui est le cas de la clause LIMIT, on se retrouve devant un bug "mystérieux" qu'on ne peut contourner qu'en bindant individuellement les variables et en indiquant un entier pour la valeur de la variable LIMIT. C'est un handicap évident pour créer du code générique (réutilisable) où l'on préfère très souvent passer un tableau dans execute.


En désactivant l'émulateur pdo, c'est le serveur MySQL qui fera le travail du prepare et de la mise en cache et renverra les bonnes valeurs pour le typage des variables. Cependant pour les versions MySQL < 5.1.17 la mise en cache du prepare n'était pas faite côté serveur si bien qu'on avait intérêt pour les requêtes préparées multiples, à garder l'émulateur de pdo avec les inconvénients précédemment cités sinon on pouvait perdre en performances

Oui c'est l'utilisation de "mysqlnd" et MySQL >= 5.1.17. qui changent la donne. "mysqlnd" est d'ailleurs maintenant activé par défaut avec php5.4.

Il est effectivement très conseillé de désactiver l'émulateur de requêtes préparée dans PDO (il n'est plus maintenu) pour faire intervenir la librairie "mysqlnd" (ou si non disponible, la librairie "libmysql" ) car MySQL sait très bien gérer les requêtes préparées, beaucoup plus efficacement et surtout avec mysqlnd. Ainsi, les requêtes sont réellement préparées avec les fonctionnalités du driver natif et pas simplement émulées avec PDO qui est trop généraliste pour pouvoir être optimisé d'où par exemple l'échappement des entiers par défaut qui conduit à l'erreur classique dans la clause LIMIT.

Et puis pas de panique car même désactivé, l'émulateur se remet en route s'il s'aperçoit que le sgdb ne supporte pas la syntaxe de la requête préparée. C'est pour cette raison que - même avec l'option PDO::ATTR_EMULATE_PREPARES, false - on peut continuer à utiliser des paramètres nommés malgré le fait que Mysql ne supporte que des paramètres anonymes pour les requêtes préparées. Dans ce cas l'émulateur PDO se met en route pour transformer les paramètres nommés en paramètres anonymes.

Conclusion : avec php 5.4 et et MySQL >= 5.1.17 on peut désactiver l'émulateur de requêtes préparées de PDO en y gagnant sur tous les plans

[eprevot]

Ce qu'il faut voir c'est le rapport avantages/inconvénients.

Justement, vu que je n'ai pas absolument besoin d'autres caractères que les latins, j'essayais de déterminer ça vaut le coup.

Bah évidemment puisque c'est le nouveau standard

Pourtant le charset par défaut de PHP est ISO-8859-1 (et aussi celui de HTTP).
Vu tous les tutos "passer de l'iso à l'utf8" qui circulent, je vois bien que c'est populaire, mais un standard ..?

...ou quand tu auras a utiliser une lib comme jquery qui ne supporte que l'utf-8...
... et à peu près tous les modules que tu voudras insérer sur ton site.

Eh ben en voilà une bonne raison d'utiliser utf8, même quand on ne compte publier que du français et de l'anglais !

Petit question qui n'a plus grand chose à voir : j'ai lu qu'utiliser utf8 en PHP pouvait introduire des erreurs quand on utilise des fonctions de traitement de chaine, par exemple strlen qui compte les octets et non les caractères.
Vous utilisez mbstring pour éviter ces erreurs ?