MySQL Duplication de clé avec caractères accentués - Page 1

plip,

J'ai un petit problème avec MySQL : suite au problème maintenant résolu posté ici, je me retrouve avec une base de données qui code correctement les caractères accentués ("é" n'est plus représenté en base par un "é" ou autre).

Le soucis, c'est que des enregistrements qui avant ne posaient pas de problème se mettent à le faire. Mettons que la table suivante est utilisée :

CREATE TABLE `ma_table` (
  `test` varchar(250) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL default '',
  PRIMARY KEY  (`test`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE utf8_general_ci;

Je veux y insérer les valeurs "role" et "rôle", qui avant ne posaient aucun problème, puisque le "ô" de "rôle" était mal codé et ressemblait à tout sauf à un "ô", donc les deux chaines étaient considérées comme différentes. Mais maintenant, MySQL considère ces deux chaines comme équivalentes; j'ai testé les valeurs pour "COLLATE" qui me semblaient les plus logiques, mais aucune (sauf utf8_bin bien sûr, mais je veux éviter de l'utiliser pour des chaînes) ne semble considérer que "o" et "ô" n'ont pas le même rang, et donc j'obtiens chaque fois une erreur de duplication de clé.

Ce problème a-t-il une solution, ou bien est-ce que les lettres accentuées sont toujours considérées comme "de même rang" que leur équivalent non accentué en UTF8 ? (ça me semble curieux, mais bon...)

Bizarre, mais ça ne me surprend pas plus que ça (MySQL gérant des tables dans plusieurs charsets, il doit devoir utiliser des tricks pour s'en sortir dans certains cas).
Si tu avais travaillé dans la fonction publique, voici la méthode que tu aurais dû utiliser () :
On supprime de la structure de la table toute notion de clé (quitte à créer un auto incrément pour l'occasion), on insère toutes les valeurs dans l'urgence parce qu'il faut bien, puis on regarde ce qu'on peut faire (en définitive, on hardcodera un truc dans les scripts pour retomber sur ses pattes, quitte à écrire une fonction get_old_key($new_key).
Une autre méthode aurait été de faire une clé sur deux champs, avec "test" qui peut prendre "rôle" ou "role" et le champ superkey qui s'incrémente quand tu as deux clés différentes sur un test de chaînes mais équivalentes pour MySQL (mais ça implique de faire passer toutes tes opérations SQL par un script créé pour l'occasion).
Cela dit, je doute que ces méthodes te satisfassent

http://bugs.mysql.com/bug.php?id=24985

d'où une question : quelle version de mysql ?

./2 > travaillant pour des gens qui en savent quand même assez pour se rendre compte de ce genre de trucs, je préfère éviter

./3 > hmm 5.0.45... si c'est un bug ça m'arrange carrément pas, pour le coup ^^ (et coller un "faux" charset latin1 sur la colonne... mwé, si y'a vraiment pas d'autre solution... mais va falloir y faire gaffe quand MySQL va essayer de faire ses conversions auto, c'est chiant :/)

[edit] heu le bug que tu cites n'a pas l'air d'avoir de rapport avec le mien ?

Bon, après vérification il semblerait que ce comportement curieux soit malgré tout voulu : http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

For example, the following equalities hold in both utf8_general_ci and utf8_unicode_ci (for the effect this has in comparisons or when doing searches, see Section 9.5.6, “Examples of the Effect of Collation”):
Ä = A
Ö = O Ü = U

Par contre c'est pratique, ils ne disent pas quel collate choisir quand on ne veut *pas* que ces lettres soient considérées comme égales (ce qui me semble pourtant être le cas le plus utile ?), et je ne suis même pas sûr que ça existe... :/

Je pense que utf8_bin est ton seul choix.

Ce qui est dommage avec utf8_bin, c'est que par exemple 'A' et 'a' deviennent des caractères différents :/

Au pire je vais effectivement devoir utiliser ce dictionnaire, mais ça me semble quand même étrange qu'il n'y ait pas moyen d'avoir 'A' = 'a' et 'a' != 'à' (enfin perso ça m'apparaît évident que dans le premier cas c'est la même lettre, mais pas dans le second, donc j'aurais pensé qu'un tel dictionnaire aurait été disponible)

Si tu as la souplesse de configuration du serveur, une méthode serait d'aller créer ta propre collation dans share\charsets, on est jamais mieux servi que par soi-même.

malheureusement je ne l'ai pas, sinon ça aurait été effectivement une bonne solution :/

perso, pour ne pas avoir ce style de pb, toutes mes bases / tables / champs sont en latin1_general_ci => je n'ai jamais eu de pb de doublont de cléfs à cause des accents, ni de probleme d'encodage, ni d'export / import

oui, c'est effectivement d'autant plus bizzare que les autres charsets n'ont pas ce problème... malheureusement je ne peux pas passer la base en latin1 (trop de conséquences derrière)

dommage mais c'est sur que si derriere toute l'appli est prévu pour du utf8... ben bon courage

ben on peut tjrs jouer avec les paramètres de conversion automatique de MySQL dans ce cas, mais ici le problème est plus complexe ^^

je verrai avec la personne concernée ce qui sera le mieux entre interdire les "faux doublons" dans l'application cliente, ou passer en utf8_bin (perso je choisirais la 1ere solution)

Zephyr (./1) :
Ce problème a-t-il une solution, ou bien est-ce que les lettres accentuées sont toujours considérées comme "de même rang" que leur équivalent non accentué en UTF8 ? (ça me semble curieux, mais bon...)

Ben en fait c'est nécessaire pour faire un tri correct dans l'ordre alphabétique si tu utilises l'algorithme naïf (si par exemple "à" était considéré comme se trouvant strictement après "a" tu te retrouverais avec "là" après "lac"). Idéalement il faudrait trier en ignorant les accents puis faire une deuxième passe pour discriminer sur les accents, mais ça complique pas mal...

C'est pas faux; raison de plus pour ne pas utiliser utf8_bin, donc ^^

Et si tu passes en utf8_bin et forces tes propres règles de validation autrement? (Dans l'application? Dans des CONSTRAINT?)

dans l'application ça risque d'être un peu compliqué (ça fait vraiment beaucoup de code à modifier), et je ne peux pas utiliser d'extensions SQL trop spécifiques, puisque c'est censé marcher via une bibliothèque d'abstraction :/

Bah les bibliothèques d'abstraction ça montre vite ses limites de toutes façons.