codification - interclassement

[patriq 0]

Hello, je me suis aperçu que je ne pouvais pas avoir les accents sur les voyelles et pas plus les carractéres speciaux comme le Ç ou le Ñ...j'ai regardé la BD..et vu que l'interclassement est latin1_bin ou latin_sweedish_ci et aussi dans la nouvelle version cp1257_general_ci mais mon phpMyAdmin indique utf8_unicode_ci...donc je l'ai changé pour latin1_bin..et aussi cp1257_general_ci.....rien à faire toujours pas d'accent et de Ç...donc j'ai mis tout les champs interclassement en utf8_unicode_ci et ça marche j'ai les accents et le Ç,Ñ ..

Je me demande bien pourquoi....??? :angry:

[Gilles Boussin 0]

Bonjour,

Dans PEEL rien ne spécifie l'usage de cp1257_general_ci.

Dans le SQL exécuté par PEEL, à certains endroits on spécifie latin_swedish (qui gère bien tous les accents), et majoritairement on ne spécifie rien, ce qui fait que ça prend le charset par défaut du serveur MySQL utilisé. De plus en plus, c'est l'utf8 qui est utilisé par défaut sur les nouvelles installations de MySQL, mais ça peut aussi être ce qu'on veut tant que ça gère les accents.

Si vous avez des données avec des caractères bizarres c'est qu'à un moment donné, sur le serveur sur lequel vous êtes ou un autre avant migration, un charset ne gérant pas correctement les accents a été utilisé.

Le mode de fonctionnement de MySQL est le suivant : si on change l'encodage d'un champ, ça va convertir le champ en même temps.

=> Si on prend l'exemple d'un champ qui reçoit des données accentuées alors même que le champt est dans un format ne gérant pas les accents : ce champ contient alors des caractères spéciaux à la place des accents, qui n'ont pas été reconnus. Et si on modifie par la suite le charset du champ, ça va garder ces caractères spéciaux, car ça les convertit !

Donc pour résoudre votre problème :

- soit vous récupérez d'anciennes versions des données avant problème d'accents

- soit vous convertissez ces données pour les corriger.

Pour corriger les données :

- convertir avec phpmyadmin les champs dans le bon charset

- utiliser convert pour altérer les données afin de reconstituer les accents : http://dev.mysql.com/doc/refman/5.0/en/charset-convert.html

Gilles

[patriq 0]

Bonjour,

Dans PEEL rien ne spécifie l'usage de cp1257_general_ci.

Dans le SQL exécuté par PEEL, à certains endroits on spécifie latin_swedish (qui gère bien tous les accents), et majoritairement on ne spécifie rien, ce qui fait que ça prend le charset par défaut du serveur MySQL utilisé. De plus en plus, c'est l'utf8 qui est utilisé par défaut sur les nouvelles installations de MySQL, mais ça peut aussi être ce qu'on veut tant que ça gère les accents.

Si vous avez des données avec des caractères bizarres c'est qu'à un moment donné, sur le serveur sur lequel vous êtes ou un autre avant migration, un charset ne gérant pas correctement les accents a été utilisé.

Le mode de fonctionnement de MySQL est le suivant : si on change l'encodage d'un champ, ça va convertir le champ en même temps.

=> Si on prend l'exemple d'un champ qui reçoit des données accentuées alors même que le champt est dans un format ne gérant pas les accents : ce champ contient alors des caractères spéciaux à la place des accents, qui n'ont pas été reconnus. Et si on modifie par la suite le charset du champ, ça va garder ces caractères spéciaux, car ça les convertit !

Donc pour résoudre votre problème :

- soit vous récupérez d'anciennes versions des données avant problème d'accents

- soit vous convertissez ces données pour les corriger.

Pour corriger les données :

- convertir avec phpmyadmin les champs dans le bon charset

- utiliser convert pour altérer les données afin de reconstituer les accents : http://dev.mysql.com/doc/refman/5.0/en/charset-convert.html

Gilles

Merci pour cette explication, donc j'ai changé dans les champs concernés la codification et tout fonctionne parfaitement je reçois les accents et les caractéres speciaux..