Discussion :

[bjacquart]

Bonjour,
j'ai un petit problème d'encodage :

j'ai une page html encodé en UTF-8
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

elle contient un formulaire qui renseigne une base MYSQL.
la base est encodée en utf8_unicode_ci, ma table encodée en utf8_unicode_ci et les champs en utf8_unicode_ci.

l'orsque j'enregistre des champs contenant des caractères spéciaux ex: &é"'(-è_çà)<qwdfghjklmù, tout va bien, sauf que si je regarde le contenu du champ dans phpMyAdmin je lis : &é"'(-è_çà )<qwdfghjklmù
Je trouve ca bizarre, d'autant que lorsque je ré-affiche ce champ dans une page html je retrouve bien le text original.

Quelqu'un peut-il m'aider, car j'ai peur de continuer dans une direction qui pourrait engendrer de gros problèmes de codages.

Merci d'avance à tous pour votre aide.

[Antoun]

a priori, c'est juste un problème d'affichage de ton phpMyAdmin. Tu peux tester par exemple que la OCTET_LENGTH() est bien supérieure à la CHAR_LENGTH().

[WildGroup]

a priori, c'est juste un problème d'affichage de ton phpMyAdmin. Tu peux tester par exemple que la OCTET_LENGTH() est bien supérieure à la CHAR_LENGTH().

Bonjour,

J'ai le même problème puis-je en savoir plus?

Merci

[bjacquart]

Bonjour Antoun et merci pour ta réponse.
1) Si c'est un problème d'affichage sais-tu comment le résoudre ?
2) J'ai ouvert le .MYD de cette table dans le répertoire data (tbl_actualites.MYD) avec le bloc note dans ce fichier je lis :

&&é"'(-è_çÃÂ*)<qwdfghjklmù

je ne sais plus quoi penser, c'est terrible ces encodages

que faire

merci

[Antoun]

CHAR_LENGTH donne le nombre de caractères, et OCTET_LENGTH le nombre d'octets. Sur un texte en utf8, les caractères accentués seront codés sur deux octets, on aura donc une CHAR_LENGTH inférieure à la OCTET_LENGTH.

Si par exemple j'ai une table nommée Textes, avec une colonne Blabla encodée en utf8, et que la ligne d'ID 6 contient le mot "école", on pourra tester la requête suivante :

Code :

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

1
2
3
SELECT OCTET_LENGTH(Blabla) as Nb_Oct, CHAR_LENGTH(Blabla) as Nb_Car
FROM Textes
WHERE ID = 6

Si on obtient 6 octets et 5 caractères, cela montre que les données sont correctement stockées en utf8, et que le problème ne se pose qu'à l'affichage. Si on obtient 6 et 6, cela veut dire que le texte stocké est vraiment "©cole" et qu'il faut corriger les données...

[bjacquart]

merci Antoun,

Le requete fonctionne voici mes résultats
contenu de mon champ : Texte résumé (Texte résumé)=> oct=18 et car = 14 ??

Par contre si je force manuellement (avec phpMyAdmin) mon champ sur "école"
déjà il affiche bien "école" et le résultat est oct =6 car=5

c'est un pb php ou ????

[Antoun]

merci Antoun,

Le requete fonctionne voici mes résultats
contenu de mon champ : Texte résumé (Texte résumé)=> oct=18 et car = 14 ??

ça pue... ça laisse penser à un double niveau de merdouille... Sur ta ligne "Texte résumé", que donne un ORD(SUBSTRING(ta_colonne FROM 8 FOR 1)) ?

Par contre si je force manuellement (avec phpMyAdmin) mon champ sur "école"
déjà il affiche bien "école" et le résultat est oct =6 car=5

c'est un pb php ou ????

ça veut dire que quand tu saisis dans phpMyAdmin, les données atterrissent correctement... mais ça ne veut pas dire grand-chose ni sur tes données, ni sur le réglage de ton phpMyAdmin.

[bjacquart]

Bonjour,

Voici ma requête, je ne sais pas si c'est très correct mias elle plante pas !!

Code :

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

1
2
3
4
5
EXPLAIN 
SELECT ORD(SUBSTRING(
  (SELECT `texteMinActualites` from tbl_actualites WHERE `IDActualites`=2
  ) FROM 8 FOR 1)
)

voici le résultat : 50051

quezako ??

merci

[Antoun]

Juste pour info, la requête suivante aurait été plus simple (pour le même résultat) :

Code :

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

1
2
3
SELECT ORD(SUBSTRING(texteMinActualites FROM 8 FOR 1))
FROM tbl_actualites 
WHERE IDActualites = 2

Quant au résultat, "50051", c'est un Ã, ce qui veut dire que dans la base il y a vraiment "Texte résumé", soit 14 caractères et 18 octets

Code :

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

SELECT CHAR(50051 USING utf8) ;

[bjacquart]

c'est effectivement un Ã, mais bon !!!
Je désespère car je bidouille mais sans de réelle solution.

je crois que je vais repasser en latin_sweedish... là j'avais pas de problème !!

Au fait, le moteur MYISAM est bien compatible avec UTF-8 car je travaille avec ce moteur

merci

[Antoun]

c'est effectivement un Ã, mais bon !!!
Je désespère car je bidouille mais sans de réelle solution.

je crois que je vais repasser en latin_sweedish... là j'avais pas de problème !!

Si tu passes la table telle quelle en latin1, ça va encore agraver les problèmes... si par contre tu as une source à partir de laquelle tu comptes réalimenter, ça peut être une bonne idée.

J'attends ta réponse pour te proposer des solution dans l'un ou l'autre cas.

Au fait, le moteur MYISAM est bien compatible avec UTF-8 car je travaille avec ce moteur

Sans problème.

[bjacquart]

encore merci Antoun,

je repasse en latin1 car j'ai pas le tps de continuer, je crois que j'ai un pb de conf de mes serveurs locaux (php - mysql ...)

pour la migration ça devrait aller, c'est le début du projet, je vide les tables je fait un dump et je remplace

Code :

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

collate UTF8_general_ci

par

Code :

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

collate latin1_general_ci

mais dès que j'ai quelques heures je reprend la bête

Merci pour ton aide

[Antoun]

Je te trouve très optimiste et je te conseille de bien regarder la tronche de ton dump avant de vider tes tables...

[bjacquart]

le résultat est le suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
 
--
-- Structure de la table `tbl_actualites`
--
 
CREATE TABLE IF NOT EXISTS `tbl_actualites` (
  `IDActualites` int(11) NOT NULL auto_increment COMMENT 'identifiant de la table',
  `titreActualites` varchar(100) collate latin1_general_ci NOT NULL COMMENT 'Titre',
  `s_titreActualites` varchar(200) collate latin1_general_ci NOT NULL COMMENT 'sous titre pour l''actualite',
  `texteMinActualites` text collate latin1_general_ci NOT NULL COMMENT 'Texte résumé',
  `texteMaxActualites` text collate latin1_general_ci NOT NULL COMMENT 'texte détaillé',
  `dateActualites` date NOT NULL COMMENT 'date',
  `photoActualites` varchar(100) collate latin1_general_ci NOT NULL COMMENT 'photo ',
  `altActualites` varchar(100) collate latin1_general_ci NOT NULL,
  `statutActualites` int(11) NOT NULL default '0' COMMENT '0=en crea ; 1=publie ; 2=archivé ; 3=supprimer ',
  PRIMARY KEY  (`IDActualites`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci COMMENT='Table des actualités' AUTO_INCREMENT=1 ;
 
--
-- Contenu de la table `tbl_actualites`
--

je le colle en sql dans une nouvelle base, est-ce qu'il peut y avoir des soucis ?

[Antoun]

Avec quelles données vas-tu remplir cette table ?

[bjacquart]

en claire c'est pas moi mais le client , par contre elle sera renseignée à partir d'un fichier php (un formulaire) avec une codification de type :

Code :

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

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">

voili voilou

[Antoun]

Donc en fait tu n'as pas de donnée déjà existante à récupérer ?

[bjacquart]

non non, c'est une création de projet.

[Antoun]

ah, tout va bien alors ! tu as raison, passe en latin1 et c'est tout !