Mysql et Interclassement/Charset !?

[thierry8]

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]

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]

.

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]

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]

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]

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: Tout sélectionner

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: Tout sélectionner

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


et au niveau d'une colonne :

Code: Tout sélectionner

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]

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...

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]

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)

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]

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]

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: Tout sélectionner

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


Code: Tout sélectionner

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]

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]

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
Je suis pas un fan de la versionite à tout prix. Mais là quand même, il faudrait qu'il se bouge un peu

[thierry8]

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
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]

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]

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

Pourquoi dont ?