Problème d'encodage?

[ygalr22]

Bonjour à tous,

Voila, j'ai un problème que je n'arrive pas à régler depuis pas mal de temps maintenant, c'est pourquoi je viens solliciter votre aide.

J'essaye d'insérer les données d'un message privé dans une BDD Mysql via la requete suivante:

INSERT INTO `message` ( 
`Msg_Num` , `Msg_Titre` , `Msg_Texte` , `Msg_Date` , `Msg_Lu` , `Mb_PseudoExp` , `Mb_PseudoDest` , `Msg_Rep` , `Msg_Syst` ) 
VALUES (
 NULL , "Vos tours ont été déplacés", "<p>Message</p>", NOW(), "0", "", "Pseudo", "0", "1" );

A l'exécution de la requête, voici le message d'erreur que je reçois:

Incorrect string value: 'xE9txE9 dxE9...' for column 'Msg_Titre' at row 1

Je ne comprends pas d'où sort ce "xE9txE9 dxE9...". Surement un problème d'encodage quelque part, mais je ne voit pas où.
Le code de ma page est en ISO 8859-2
Le champ dans la BDD est un varchar(40) encodé(?) latin1_swedish_ci

Quelqu'un aurait il une idée?

Merci

 

[Bacteries]

Clairement un soucis d'encodage, xE9 c'est é.
Quel est l'encodage de ton fichier SQL (que tu as copié/collé dans ton message)?

 

[ygalr22]

Bonjour, et merci de ta réponse.

Comme je l'ai dit dans le message précédent, le fichier php qui contient la requête est encodé en ISO 8859-2.
Enfin c'est ce que m'indique mon éditeur de texte...

edit:

xE9 c'est é

d'accord, mais dans quel "format" d'encodage?

 

[jcaron]

La requête, elle est où? Dans un fichier PHP? Ailleurs?

Moi je dirais qu'il y a quelque chose quelque part qui a décidé qu'il fallait remplacer les caractères accentués par leur version \xNN, puis que le \ a sauté (parce qu'il n'est pas doublé), et le moteur a donc reçu xNN au bout du compte.

Où, qui, quand, comment, sans en savoir plus sur comment tu exécutes cette requête exactement, ça va être dur...

Jacques.

 

[ygalr22]

La requête, elle est où? Dans un fichier PHP? Ailleurs?

Moi je dirais qu'il y a quelque chose quelque part qui a décidé qu'il fallait remplacer les caractères accentués par leur version \xNN, puis que le \ a sauté (parce qu'il n'est pas doublé), et le moteur a donc reçu xNN au bout du compte.

Où, qui, quand, comment, sans en savoir plus sur comment tu exécutes cette requête exactement, ça va être dur...

Jacques.

Bonjour, je vois que tu est aussi couche tard que moi! :lol: (ou lève tôt 8O )

Quoi qu'il en soit, je ne vais pas coller tout mon code ici, ce serait franchement long et pas très digeste (sauf si cela est vraiment indispensable et que vous êtes motivés :wink: )

Par contre, pour donner plus de détails, le script où se situe la requête est en fait mon script de login au site.
Je n'utilise pas de fonction "bizarre" d'encodage quelconque.
Ce script vérifie juste la validité des paramètres de connexion et met en sessions les données du membre.
Il me semble avoir rencontré le même type de problème (j'ai oublié où) qui était du à l'utilisation des session de mon forum phpbb.
Voici la partie du code pour le loggin aux session phpbb :

/*Pour le Forum*/
    define('IN_PHPBB', true);
    $phpbb_root_path = './../../Forum/';
    $phpEx = substr(strrchr(__FILE__, '.'), 1);
    include($phpbb_root_path . 'common.' . $phpEx);
    //include($phpbb_root_path . 'includes/auth/auth_db.' . $phpEx);
    $user->session_begin();
    $auth->acl($user->data);
    $user->setup();
    
    $username = $TestPseudo;//request_var('username', '', true);
    $password = $_POST['LogPassword'];//request_var('password', '', true);
    
    
    //connexion
    $result = $auth->login($username, $password, true, 1, $BaseDroitAdminForum);
      
    if ($result['status'] == LOGIN_SUCCESS){
      $auth->acl($user->data);
    }
    /*==========*/

La requête qui pose problème est appelée juste après cette portion de code (après vérification de la connexion), mais à première vue, pas grand chose d'exceptionnel.

Si vous avez besoin de tous le code, je peut l'ajouter, faites le moi savoir.

Merci

 

[jcaron]

Et y repensant, pour qu'il y ait une erreur, il faut que les caractères ne soient pas "acceptables" dans ce contexte, donc ils sont bien stockés sous leur forme "native" (i.e. pas encodés sous forme \xE9...), et c'est lors de l'affichage du message d'erreur que les \ "sautent".

Pour que ça ne passe pas, ça veut dire a priori que ta base/ta table/ton champ (je ne sais pas où ça se joue dans mysql) est prévu pour accepter des caractères à un certain format, et là tu lui balances autre chose. Tu es sûr que ta connexion et/ou ta base ne sont pas configurées pour de l'UTF-8? Fais un "show create table message" pour voir...

Au fait, pourquoi utiliser ISO-8859-2 plutôt que ISO-8859-1? Et utiliser du 8859-2 alors que ta base est en 8859-1 ce n'est pas une bonne idée non plus.

Jacques.

 

[ygalr22]

Voici ma requête de création de la table (via "show create table message"):

CREATE TABLE `message` (
 `Msg_Num` int(11) NOT NULL auto_increment,
 `Msg_Titre` varchar(100) NOT NULL,
 `Msg_Texte` longtext NOT NULL,
 `Msg_Date` date NOT NULL,
 `Msg_Lu` tinyint(1) NOT NULL,
 `Mb_PseudoExp` varchar(15) NOT NULL,
 `Mb_PseudoDest` varchar(15) NOT NULL,
 `Msg_Rep` int(1) NOT NULL,
 `Msg_Syst` int(1) NOT NULL,
 PRIMARY KEY  (`Msg_Num`)
) ENGINE=InnoDB AUTO_INCREMENT=3803 DEFAULT CHARSET=latin1

Au fait, pourquoi utiliser ISO-8859-2 plutôt que ISO-8859-1? Et utiliser du 8859-2 alors que ta base est en 8859-1 ce n'est pas une bonne idée non plus.

C'est pas faux (après réflexion :wink, en fait je n'ai pas vraiment fait attention à l'encodage de mes pages, c'est mon éditeur de texte (pspad) qui encode en 8859-2 par défaut.

Edit: Arf! je viens de vérifier l'encodage de ma BDD : "Jeu de caractères pour MySQL: UTF-8 Unicode (utf8) "

c'est tout de même bizarre, avant ca je n'avais eu aucun problème et pourtant je ne fesait rien de "spécial" pour enregistrer en UTF8. J'avoue être un peut perdu dans cette histoire d'encodage... Help! :wink:

 

[ygalr22]

petit up...