Multilingue, encodage & co [Résolu]

[Flashball]

Salut,

Je développe une appli multilingue en utilisant l'encodage UTF-8.

Cela marche plutôt bien mais me pose un problème pour les tries alphabétiques, surtout que j'utilise une couche d'abstraction objet pour manipuler les données.

par exemple, un classement alphabétique donne actuellement:

Code :

1
2
3
étrange
bizarre
curieux

au lieu de:

Code :

1
2
3
bizarre
curieux
étrange

Est-ce une bonne solution de convertir les caractères encodés en UTF-8 en ISO-8859-1 avant de les insérer en BDD afin de pouvoir conserver le trie? Si oui, comment convertir massivement un existant? Existe-t-il une solution plus simple?

Merci pour vos conseils!

[SQLpro]

Sur le plan général l'encodage n'a pas d'importance. C'est la collation qui en a...

A lire : http://sqlpro.developpez.com/cours/s...e=partie1#L4.2

A +

[Antoun]

Et pour une application à MySQL :

http://antoun.developpez.com/mysql5/jeux-collations/

[Flashball]

Merci pour ces précisions!

J'ai lu la doc Mysql et je pense que le mieux pour mon appli est de prendre "utf8-unicode-ci" comme collation (au lieu du "latin-1-swedish").

Problème: la base existe et elle est remplie de données.

J'ai vu qu'on pouvait convertir les tables et/ou colonnes. J'ai des soucis de deux ordres:

1. après avoir modifier une colonne 'titre' avec la commande "ALTER TABLE `product_i18n` CHANGE `TITLE` `TITLE` VARCHAR( 120 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL", je n'ai constaté aucune différence, tant au niveau du stockage, que du rendu ou du trie (même problème que sur le post initial). Je m'attendais à ce que les données stockées se transforment et que mon libellé "étrange" soit modifié en "étrange"?
2. une conversion de toute la table 'product_i18n' avec la commande "ALTER TABLE product_i18n CONVERT TO CHARSET utf8 COLLATE utf8_unicode_ci" me renvoit une erreur SQL "#1025 - Error on rename of '.\nomdemabase\#sql-2b0_62' to '.\nomdemabase\product_i18n' (errno: 150) "

Est-ce la bonne stratégie?
Comment passer toute ma base et ses données en "UTF8-unicode-ci"?

[Antoun]

Non, ce n'est pas la bonne stratégie. Changer l'encodage d'une colonne provoque une conversion, donc s'il y a des erreurs, les erreurs sont reproduites dans le nouvel encodage.

Pour éviter cela, il faut passer par le type BLOB, qui est l'exception à cette règle de conversion automatique. Je te suggère donc la procédure suivante :

1. faire une copie de ta table
2. sur la copie, passer une colonne qui pose problème en BLOB
3. toujours sur la copie, passer le BLOB en VARCHAR CHARSET utf8
4. voir si ça règle le problème d'affichage des caractères accentués, et poster le résultat ici

[Flashball]

Cette idée n'a rien donné, j'ai toujours les mauvais caractères pour les accents dans ma colonne...

Autre stratégie:

1. Extraire les données
2. Transformer les colonnes concernées
3. Modifier "à la main" les données extraites (rechercher/remplacer)
4. Les réinjecter

Un peu lourd, mais y'a-t-il une alternative?

[Antoun]

si ça n'a pas marché, c'est que probablement tes données sont bonnes, et que c'est l'affichage qui déconne. Donc évite de transformer à la main, ça ne devrait rien changer.

Je te donne des tests pour vérifier ça dans la soirée.

[Antoun]

Donc, tu choisis une colonne passée en utf8, pour laquelle tu des problèmes d'affichage. Par exemple, mettons que la colonne Truc de la table Machin contienne le mot étrange, qui apparaît comme étrange.

Code :

1
2
3
SELECT CHAR_LENGTH(Truc) AS NbCaracteres,
   LENGTH(Truc) AS NbOctets
FROM Machin

En Unicode, le é est codé sur deux octets, ce qui fait donc 6 caractères mais 7 octets pour étrange ; si par contre le texte stocké est vraiment étrange, cela te donnera 7 caractères et 7 octets.

[Flashball]

Merci pour cette requête de test

Voici qq résultats:

Code :

1
2
3
4
5
6
7
8
9
10
11
"café / café"
nbcaracteres: 5
nboctets: 7
 
"bière / bière"
nbcaracteres: 6
nboctets: 8
 
"émaillé alimentaire / émaillée alimentaire"
nbcaracteres: 22
nboctets: 26

Les "caractères spéciaux" "Ã", "©", etc. sont codés sur 2 octets, ce qui expliquent ces différences par rapport aux prévisions non?

Je vais refaire un test en local en reconstruisant la bdd dès le départ en utf-8 parce que je commence à m'embrouiller un peu...

[Flashball]

J'ai recréé mon schéma en local basé sur ut8 + ut8_unicode_ci et j'ai testé l'enregistrement via l'application de qq données avec accents: le problème ne change en rien.

Les pages de l'appli sont encodées en charset UTF8, le problème vient apparemment des formulaires de saisie de données: les données récupérées avec des accents sont déjà "transformées" avec les caractères spéciaux stockés en bdd...

Juste une question: sous phpMyAdmin, si je consulte les données de la base, dois-je voir apparaître les accents normalement ou sont-ils codés?

[Antoun]

Au vu de ton test... essaie ce coup-là :

- tu prends ta colonne utf8 et tu la repasses en latin1 (café va rester café, mais sur 5 octets)
- tu la passes en BLOB
- tu la passes en utf8 (café doit être réinterprété en café)

[Flashball]

ok, merci pour toutes ces idées mais...

ca ne changera pas mon problème, il faut que j'arrive à bien enregistrer les données dans la base: on dirait que le problème vient de mon charset UTF-8 dans mes pages HTML/PHP, car les accents des champs de saisie sont récupérés codés ("é" devient "é") et donc mal stockés en bdd.

une fois que j'aurais réglé çà, il faudra que je mette à jour l'ensemble des données déjà existantes, mais je referai d'autres tests avant de mettre le feu à la base de prod...

[Antoun]

OK...

Note qu'il n'est pas du tout nécessaire que ta page PHP soit en utf8. L'important est juste que tout soit déclaré correctement.

Je te suggère les tests suivants :

côté PHP, tu passes cette requête :

Code :

SELECT _ut8'é', _latin1'é' ;

Le é qui s'affiche correctement est celui de l'encodage réel de la page PHP.

Ensuite tu passes cette requête-là, toujours à partir de PHP :

Code :

SHOW VARIABLES LIKE '%char%' ;

si par exemple le premier test révèle que l'encodage réel de ta page PHP est en latin1, et que le second dit que le caracter_set_client est déclaré comme utf8, il faudra que tu re-déclares ton encodage, en passant cette requête juste après ton mysql_connect :

Code :

SET NAMES latin1 ;

[Flashball]

Ces tests m'ont permis d'avancer sur la voie de la solution... car effectivement, PHP était en 'latin'!

J'ai désormais mes accents en BDD!

Pour info, voilà la config Symfony1.0/Propel du fichier databases.yml:

Code :

1
2
3
4
5
6
  propel:
    class:          sfPropelDatabase
    param:
      encoding:     utf8
      charset:      utf8 
      dsn:          mysql://user:password@localhost/mabase

Reste qu'il me reste qq points encore à éclaircir:

1. en PHP, comment se fait-il que le texte récupéré d'un formulaire transforme mes accents en caractères bizarres (en tout cas d'après les log!) puis l'enregistre correctement en bdd?
2. quelle stratégie adopter pour modifier la base en prod - il y a plein de colonnes concernées dans plein de tables?!!

Et encore merci beaucoup pour ton aide!

[Antoun]

Envoyé par Flashball

Ces tests m'ont permis d'avancer sur la voie de la solution... car effectivement, PHP était en 'latin'!

En latin1, mais déclaré en utf8 ?

Envoyé par Flashball

Reste qu'il me reste qq points encore à éclaircir:

1. en PHP, comment se fait-il que le texte récupéré d'un formulaire transforme mes accents en caractères bizarres (en tout cas d'après les log!) puis l'enregistre correctement en bdd?
   
   

1. bizarre comment ? du genre café devient cafE9 ou caf%E9 ?
   

   Envoyé par Flashball

   quelle stratégie adopter pour modifier la base en prod - il y a plein de colonnes concernées dans plein de tables?!!

et en plus, si tu mélanges des valeurs mauvaises avec des valeurs corrigées, ça va dur de réparer un truc sans en péter un autre

Tout réimporter ?

[Flashball]

En latin1, mais déclaré en utf8 ?

en résumé, j'ai uniquement réussi à exécuter ta requête 1 (sous symfony s'entend), qui me renvoyait utf8 = '' et latin = "é" jusqu'à ce que je change la configuration de Propel (la couche d'abstraction bdd), ce qui a donné utf8 = 'é' et latin = 'é'

bizarre comment ? du genre café devient cafE9 ou caf%E9 ?

café devient café!

d'après la fonction "iconv_get_encoding()", PHP semble configuré en ISO-8859-1, alors que j'ai pourtant spécifié utf-8 dans un fichier de config Symfony - enfin bref, il s'agit d'un problème PHP/Symfony en l'occurence.

Pour la prod, je sais pas trop comment je vais faire, mais ce qui est sûr, c'est qu'il y aura des trucs que je ne pourrai pas corriger, comme le texte qui était "strippé" par exemple pour obtenir des URLs "friendly".

Mon client a eu la bonne idée de rentrer tous ses articles à toute vitesse à peine le truc lancé, et ce problème n'avait pas été détecté en recette...

J'essaierai demain, il doit en être à la moitié de son catalogue pour le moment...

[Flashball]

Finalement j'ai fait tout çà dès ce soir...

J'ai changé "à la main" les caractères en me servant de tables de conversion que j'ai trouvé ici: un peu lourd, mais çà a marché!

[Antoun]

Bravo pour t'en être sorti !
Et merci pour le lien, je pense que je vais intégrer ça dans une prochaine FAQ.