Mysql et Interclassement/Charset !?

thierry8 · 29 Mars 2006

Bonjour,

J'ai rencontré un problème lors du passage de ma base de données mysql de mon PC au serveur d'hébergement.
Je pense que nombreux d'entre vous ont également eu ce problème.

.. .. .. E X P L I C A T I O N
J'ai travaillé en local avec Mysql 4.1.9 via PHPMyAdmin 2.6.1 ( EasyPHP 1.8 )
Je ne sais pas si c'est grâce à PHPMyAdmin ou Mysql, mais en local sur ma base de données je peux choisir l'interclassement. Pour cela j'ai fais plusieurs tests, avec différents interclassement. J'ai finallement opté pour utf-8_general_ci qui me prenait certains caractères spéciaux tel quel lors de l'enregistrement de données en passant par PHP.
Par exemple, l'insertion du caractère "€" permettait en utf-8_general_ci d'avoir exactement ce signe dans la base de donnée. Or avec d'autre interclassement, ce signe était remplacé par d'autre caractère, ce qui pose problème pour des comparaisons. En revanche à l'affichage, tout est bon, mais je m'étonne de voir que le caractère n'est pas repris à l'identique dans mysql lorsque l'interclassement est différent.

.. .. .. P R O B L E M E
Sur l'hébergement, il n'est pas possible de choisir l'interclassement.
D'ailleurs lorsque j'ai exporté ma base de données local pour l'importer sur le serveur, j'ai du enlever du fichier sql généré ceci: DEFAULT CHARSET=utf8, à toutes les créations de table.
Sur le serveur, la version de Mysql est la 4.0.24 et PHPMyAdmin 2.6.3.

.. .. .. Q U E S T I O N S
Quel est l'interclassement par défaut ?
Comment est-il possible de le savoir ?
Est-ce un standard ?
Quel encodage me conseillez-vous au niveau base de données ?

Outre les questions, si vous avez une explications à me donner, n'hésitez pas.
Je remercie toutes les personnes ayant pris la peine de lire jusqu'au bout.

mr_go · 29 Mars 2006

Si ton site est uniquement en français, ne t'embete pas avec l'utf et préfère l'iso qui est généralement moins contraignant pour nous, pauvres français utilisant des "é", des "à" et tout autre symbole exotique...

Si ton site doit être traduit dans une langue non latine, effectivement il vaut mieux opter pour l'utf.

Utf-8 est un standard effectivement.

Par contre pour ta question d'interclassement je sèche.

thierry8 · 29 Mars 2006

.

Merci mr_go.

Lorsque tu dis préférer l'iso, d'accord mais concrètement, lequel ?
Ensuite, je préfère prendre en compte, la possibilité d'un site multi-langues.

_ _ _ _
Sur les hébergeurs quel est l'encodage des bases de données ?

Car, il n'y a pas les mêmes options, qu'en local.

Beaucoup de VU...
personne n'a été confronté à ce genre de problème ?

mr_go · 29 Mars 2006

Un hébergeur japonais préfèrera l'UTF je pense

Il me semble que sur mon mutu OVH ca doit être iso-8859-1.

En terme d'option, je pense que ca doit être un problème de droit.

thierry8 · 29 Mars 2006

mr_go a dit:
Il me semble que sur mon mutu OVH ca doit être iso-8859-1.

Mais y a pas d'iso-8859-1 ???
Il y a latin, uft, etc...

E D I T :
J'en profite également, dans PHPMyAdmin, sur le serveur j'ai ce message en rouge dans Opération:
Certaines fonctionnalités ayant trait aux tables reliées sont désactivées.
Est-ce justement à cause de droits limités, ou une erreur dans la construction de la table ?
(jen doute, car je n'ai pas de tel message en local)

R E D I T :
La réponse au précédent edit : -http://www.npds.org/viewtopic.php?topic=5705&forum=5

spidetra · 29 Mars 2006

Je ne connait pas le pb exact lié à ton hébergeur et à phpMyAdmin.
Tu as deux notions qui sont complémentaires en mySQL :
- Le Charset
- La Collation ( inter-classement ).

Le charset ; correspond au jeu de caractères que tu choisit. Chaque jeu de caractères est spécifique à une ou plusieurs langue.
Ex : latin1, latin2, utf8
Les langues d'europe de l'Ouest vont être essentiellement dans le charset latin1 ( iso-8859-1 )
Les langues d'europe centrale seront plutôt avec le charset latin2 (iso-8859-2 )
Le charset utf-8 est quasiment capable de coder toutes les langues ( il reste quelques dialectes qui ne peuvent pas être codé en utf-8 )

La Collation ( inter-classement ) : correspond à l'ordre de tri à l'intérieur de ton charset. Le tri en allemagne, en norvège ou en france peut être différent.
Tu auras des interclassement du type : latin1_general_ci, latin1_german_ci, etcc
ci = case insensitive
cs= case sensitive

Depuis mySQL 4.1 il est possible :
- de spécifier le charset et la collation pour chaque table
- de spécifier le charset et la collation pour chaque colonne de chaque table.

tu devrais pouvoir créer ta base de données avec une syntaxe du type :

Donc, a priori, quel que soit la config de ton hébergeur tu peux faire ce que tu veux.

Code:

CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci

tu peux choisir le charset et le collate dés la création. Ce qui t'évite de mettre ses instructions au niveau de chaque table

Tes créations de table se font avec des instructions du style :

Code:

CREATE TABLE tbl_name (column_list)
    [[DEFAULT] CHARACTER SET charset_name] [COLLATE collation_name]]

et au niveau d'une colonne :

Code:

CREATE TABLE Table1
(
    column1 VARCHAR(5) CHARACTER SET latin1 COLLATE latin1_german1_ci
);

Normalement, ton hébergeur, ne devrait pas interdire ces instructions.
Si c'est le cas, son support pourra peut-être t'aider.

thierry8 · 29 Mars 2006

spidetra a dit:
La Collation ( inter-classement ) : correspond à l'ordre de tri à l'intérieur de ton charset. Le tri en allemagne, en norvège ou en france peut être différent.

C'est à dire ? :?
Cela correspond également à "l'encodage" donc ? (au même titre que le charset)

Avec ces explications, j'ai effectivement pu constater un problème de mon coté, en local.
En effet, mon erreur a été de mettre un interclassement latin1_swedish_ci en ayant PHPMyAdmin en langue : French-utf8
(on ne peut avoir que de l'utf8 avec PHPMyAdmin 2.6.1)
C'est pour cela, que j'avais dérivé vers le utf8_general_ci, pour voir directement depuis PHPMyAdmin les caractères spéciaux correctement. En fait, l'erreur était simplement au niveau affichage... :roll:

spidetra a dit:
Depuis mySQL 4.1 il est possible :
- de spécifier le charset et la collation pour chaque table
- de spécifier le charset et la collation pour chaque colonne de chaque table.

OK, ceci expliquerait cela...
En local, j'ai Mysql 4.1.9 et sur le serveur Mysql 4.0.24.
Ce serait donc la raison pour laquelle je ne peux modifier l'interclassement.
(qui explique également qu'il faillait supprimer le DEFAULT CHARSET=utf8)

Mais dans ce cas, sur le serveur, étant donné qu'il s'agit d'une version Mysql qui ne suportte pas l'interclassement, comment fonctionne t-elle ? Y a t-il un encodage par "défaut" ?

Merci beaucoup à vous deux, cela ma permit d'avancer d'un grand pas.

spidetra · 29 Mars 2006

thierry8 a dit:
spidetra a dit:

La Collation ( inter-classement ) : correspond à l'ordre de tri à l'intérieur de ton charset. Le tri en allemagne, en norvège ou en france peut être différent.

Cliquez pour agrandir...

C'est à dire ? :?
Cela correspond également à "l'encodage" donc ? (au même titre que le charset)

Non. Cela correspond aux règles de tri dans ton charset.
Le manuel mySQL sera plus clair que moi :
http://dev.mysql.com/doc/refman/5.0/fr/ ... neral.html

thierry8 · 29 Mars 2006

Merci spidetra, très interessant le lien !

Il ne faut jamais oublier la source.

Je comprends à présent.

_ _ _ _ _ _
En revanche ma question par rapport à cela, justement, reste encore valable.
Les version précédentes de Mysql ( < que 4.1 ) n'ont donc pas de collation...
J'ai du mal à cerner comment fonctionne Mysql sans cela, car il me semble que c'est "indispensable".

E D I T : Question subsidiare
Admettons que je choisisse l'encodage utf-8 au niveau de mes pages.
Je prend donc également la collation utf-8 pour ma base de données.
Lors de l'insertion de données depuis un formulaire, faut-il traiter les données avant de les enregistrer dans la base de données ?
(je fais allusion en parallèle à la fonction htmlentities qui permet de traiter les données avant de les afficher dans tel ou tel format)

spidetra · 29 Mars 2006

thierry8 a dit:
En revanche ma question par rapport à cela, justement, reste encore valable.
Les version précédentes de Mysql ( < que 4.1 ) n'ont donc pas de collation...
J'ai du mal à cerner comment fonctionne Mysql sans cela, car il me semble que c'est "indispensable".

Aucune idée, j'ai jamais bossé avec une version de mySQL < 4.1.
Avant j'était ou en PostgreSQL ou en MS-SQLServer.
Je (re)-viens à mySQL avec la version 5.0.

Est-ce que tu as accés à la commande show variable ?
Et faire des requêtes du type :

Code:

show variables like '%collation%' ;
show variables like '%character%' ;
show variables  ;

Code:

Variable_name	Value
...
character_set_client	utf8
character_set_connection	utf8
character_set_database	utf8
character_set_results	utf8
character_set_server	utf8
character_set_system	utf8
...
collation_connection	utf8_general_ci
collation_database	utf8_general_ci
collation_server	utf8_general_ci
...

thierry8 · 29 Mars 2006

Oui, mais cela ne donne rien...
Ca me parait normal du fait que cette version ne supporte pas la collation.

En revanche en local ( version Mysql > 4.1 ), j'ai effectivement cela:

Variable_name . . . . . . Value
collation_connection . . latin1_swedish_ci
collation_database . . . latin1_swedish_ci
collation_server . . . . . latin1_swedish_ci

Etonnant le fonctionnement précédent de Mysql.

spidetra · 29 Mars 2006

thierry8 a dit:
Oui, mais cela ne donne rien...
Ca me parait normal du fait que cette version ne supporte pas la collation.

Il a quel verion de mySQL ton hébergeur 8O
Je suis pas un fan de la versionite à tout prix. Mais là quand même, il faudrait qu'il se bouge un peu

thierry8 · 29 Mars 2006

spidetra a dit:
thierry8 a dit:

Oui, mais cela ne donne rien...
Ca me parait normal du fait que cette version ne supporte pas la collation.

Cliquez pour agrandir...

Il a quel verion de mySQL ton hébergeur 8O
Je suis pas un fan de la versionite à tout prix. Mais là quand même, il faudrait qu'il se bouge un peu

Ben comme indiqué plus haut : Mysql 4.0.24
(je suis sous Plesk en dédié, j'ai de la chance d'être sous Debian, parce que sous un autre OS, seul la version 3.x est supportée)

spidetra · 29 Mars 2006

thierry8 a dit:
Ben comme indiqué plus haut : Mysql 4.0.24
(je suis sous Plesk en dédié)

ça m'apprendra à lire plus attentivement les posts.
Si j'avais vu 4.0.24 sur le serveur, j'aurai jamais répondu !

thierry8 · 29 Mars 2006

spidetra a dit:
ça m'apprendra à lire plus attentivement les posts.
Si j'avais vu 4.0.24 sur le serveur, j'aurai jamais répondu !

8O Pourquoi dont ?

spidetra · 29 Mars 2006

thierry8 a dit:
spidetra a dit:

ça m'apprendra à lire plus attentivement les posts.
Si j'avais vu 4.0.24 sur le serveur, j'aurai jamais répondu !

Cliquez pour agrandir...

8O Pourquoi dont ?

Parceque toutes ces explications ne servent pas à résoudre ton problème.

thierry8 · 29 Mars 2006

Non, en effet, mais elles en ont résolu d'autre...
( c.f. : premier post )

Mais as-tu une explication plosive à cela ? :?
Mysql, gère cela..."autrement...".

thierry8 a dit:
E D I T : Question subsidiare
Admettons que je choisisse l'encodage utf-8 au niveau de mes pages.
Je prend donc également la collation utf-8 pour ma base de données.
Lors de l'insertion de données depuis un formulaire, faut-il traiter les données avant de les enregistrer dans la base de données ?
(je fais allusion en parallèle à la fonction htmlentities qui permet de traiter les données avant de les afficher dans tel ou tel format)

J'abuse de toi, mais peux tu me dire si j'ai juste, ou si je fais carément fausse route stp. Merci.

spidetra · 29 Mars 2006

après je sais pas. C'est des traitements en PHP, et je ne fait plus de php.

thierry8 · 29 Mars 2006

OK

Je te remercie pour ton aide.