Discussion :

[bobyboby1]

Bonjour,


J'ai à ma disposition des tables avec des champs de type VARCHAR et TEXT.
Les tables possèdent comme collation (ou interclassement?) par défaut: utf8_unicode_ci
Mais je m'aperçois lorsque je consulte mes données des mots comme "Générale" qui devrait être "Générale"
Ainsi que d'autres caractères pour tous les lettres avec des accents.

J'ai essayé manuellement de les repérer dans mes données qui est assez énormes ( 10 000 de lignes de données environ dans une table)
Et de les remplacer avec cette requête pour chaque colonne de mes tables:

Par exemple, j'ai une table document contenant des champs de type VARCHAR pour le champ titre, et pour le champ auteur et de type TEXT pour le champ resume.


J'utilise cette requete pour une colonne, ici resume:

Code sql :

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

1
2
3
4
5
6
7
8
UPDATE document
SET resume = replace(replace(replace(replace(replace(replace(resume,'é', 'é'),'è', 'è'), 'ç', 'ç'), 'ô', 'ô'), 'ï', 'ï'), 'ë', 'ë')
WHERE (resume LIKE '%é%') OR
 (resume LIKE '%Ã%¨') OR 
 (resume LIKE '%ç%') OR 
 (resume LIKE '%Ã%') OR 
 (resume LIKE '%ï%') OR 
 (resume LIKE '%ë%');

Il y a certainement des caractères que j'ai oublié dans ma requête. Je compte appliquer cette requête à toutes les colonnes de mes tables possédant des types TEXT et VARCHAR.

Existe t-il un moyen pour remédier à ce problème d'une meilleur façon?
Merci d'avance

[SQLpro]

Il est stupide d'utiliser une collation de type UTF8 pour une base de données. Ceci ne peut que conduire à des problématique de conversion et de performances. UTF8 a été créé pour faire de la compression de données à la volée dans les flux HTPP et n'est réellement intéressant que pour la langue anglaise qui ne comporte aucun caractère diacritique (accents, cédille, ligature...).
Reprenez votre base avec une collation Latin et tout ira mieux.

Je suppose que vous êtes sur MySQmerde ?
Lisez ceci :
http://stackoverflow.com/questions/3...mysql-with-php


A +

[bobyboby1]

Merci de ta réponse.
Donc utf8_unicode_ci est à proscrire dans ma base de donnée. Je ne savais pas :/
J'ai pensé à un truc, il faudrait que je refasse une exportation de la base d'origine, j'ai dû modifier la collation lors de l'export peut être, je vais vérifier cela.

Sinon j'ai changer en latin1_general_ci, bon cela ne résout pas les "Générale" présents dans mes données.
Je vais voir tout cela.

Merci

[SQLpro]

Sinon j'ai changer en latin1_general_ci, bon cela ne résout pas les "Générale" présents dans mes données.
Je vais voir tout cela.

Merci

Une fois les octets stockées mal transformés ils vont rester stockés mal transformé !

Il faut refaire l'import.

A+

[bobyboby1]

D'acc merci

[Emmanuel R]

Bonjour,

J'ai une question complémentaire. Je suis face à un cas où je suis gêné par le peu de caractère utilisables par les collations Latin.
Je suis sur une base de données Oracle 11g2, dans laquelle j'intègre des fichiers plats. Ces fichiers ont des origines internationales.


Pour essayer de suivre les conseils d'SQLPro, j'utilise un encodage Latin pour lire mon fichier dans un premier temps.
En Latin-1 (ISO-8859-1), j'ai le caractère "Œ" qui ne s'intègre pas.
En Latin-9 (ISO-8859-15), c'est le caractère " ’ " qui ne s'intègre pas (différent de l'apostrophe simple " ' ")
Ce caractère a été remplacé entre Latin-1 et Latin-9.


Je suis tenté d'utiliser UTF-8, ça marche bien dans mon flux d'intégration de données, mais le message ci-dessus me fait penser que ce n'est pas une bonne pratique.
Mais comment faire autrement ?

[Arkhena]

Bonjour,

Le problème d'UTF-8, c'est que les chaînes de caractères comportant des caractères non anglais prendront plus de place. Ils seront par contre bien supportés.

Cordialement,

Arkhena