Problème de fou avec parsage de flux xml traded*** et encodage utf8 en php

[calligan]

36-15 mylife
Bon c'est l'intro est c'est chiant sautez directement aux problèmes si vous avez pas le temps de lires des conneries :lol:
Bonjour , je suis pas du genre à demander aux autres de l'aide en général , mais la je vien de passer la nuit à essayer de résoudre un problème et je me suis bien cassé les dents... :mrgreen:
J'imagine que c'est surement un problème à la con.

En faite j'essaye de parser un flux xml , qui au départ était codé en ISO-8559-1 , et j'arrivai pas à men sortir vu que le charset de la bdd mysql était en utf-8 ...( enfin je pensai que ça venai de la au début)...

Donc après 2 heure de recherche j'ai fini par dire bon , je passe le flux en utf8 au lieu de m'emmerder , sauf que j'ai un gros problème toujours.

J'avais utilisé le dom pour parser et j'ai décider pour le fun et aussi parce que j'ai entendu qu'il était mieux pour les gros fichier de parser avec le sax ... Au final ( je trouve qu'il est plus lent pour info...).

Début du problème
si je fait un echo de ma variable dans mon switch elle sort à peu pres bien mais avec un décalage qui est reglé une fois que lencodage du navigateur est sur utf8 exemple pour Résine = R (saut de ligne) ésine réglé si je met les param du nav sur utf8 car j'ai pas fait de header c'est juste pour tester .
Sauf que la ou ça se corse c'est quand je passe ma variable en global La lettre R disparai du mot et pratiquement tout mes mots avec un accent é se retrouve tronqué d'une partie du mot parfois une bonne partie de la phrase .
Je vois pas de solution à mon problème j'ai besoin des variables globales car je stock les info dans la bdd, j'ai tester utf8_encode decode ( a priori j'en ai pas besoin car pas de iso... mais bon tout est bon à tester ).
Dans la bdd les mots son également tronqué , j'ai vraiment réussi à traquer le problème au niveau du passage en variable global.

Je suis pas trop famillié avec les codages mais le flux est par endroit codé avec du html genre & et les accents eux ne sont pas codé en tout cas rien de visible , il sont tel qu'elle dans le flux et à part le type de codage en début du flux j'ai vois pas trop de différence avec l'iso que j'avais pris au début.
dans le php j'ai mis les choses suivante , car j'ai eu la surprise en faisant un mb_jesaislusquoi de voir que j'était en iso alors j'ai forcé en mettant ça
mb_internal_encoding("UTF-8");
et ça avant les autres query.
mysql_query("set names utf8;");
fin du problème
mendicité d'aide
J'ai vu que certaines personnes avais des problèmes similaires, mais celui la est assez particulier je doit dire , j'ai vu des fonctions bien sympa avec de l'unicode mais en proto et seulement sur php6 quoi qu'il en soit je suis même pas sur que ça m'aurai aidé, si quelqu'un à déjà parsé un flux de tradedo*** et peu me filer un coup de main je lui serai vraiment reconnaissant !

 

[Bacteries]

Tu as l'air d'avoir de gros soucis niveau encodage mais surtout niveau compréhension de ce que ça représente.

Donc d'abord ton fichier php lisant les données :
- Quel est l'encodage de ce fichier (je parle du fichier PHP)? Si tu utilise eclipse ou notepadd++ tu peux facilement le savoir. Car si tu fais des pages UTF-8 mais que tes fichiers PHP en en iso ça peut poser problème.
- Quel est l'encodage envoyé à ton navigateur (dans le header de ta page html)?
- Si tu as Apache : vérifie que ton apache ne force pas le type d'encodage de tes pages. (rare mais ça peut arriver).
- Vérifie que ta BDD et tes tables sont bien en UTF-8.

Le flux que tu veux lire de l'extérieur : il est en quoi? ISO, UTF-8?
Car si tu as tout les points d'avant OK, si c'est de l'ISO tu utilise utf8_encode() pour enregistrer les données.

Et un point : voir des caractères bizarres au lieu d'un "é" ça veut uniquement dire que tu lis un encodage avec un autre encodage. Si tu lis du texte brut UTF-8 en UTF-8 (= ton "lecteur" le lis comme de l'UTF-8) tu verra un é.

 

[calligan]

-Le fichier php est en utf8 sous ps-pad.
-pas de balise dans la page ou je sort le echo ( car c'est juste pour debugger) je change l'encodage du navigateur a utf8 ce qui m'inquiete c'est que sans sortir l'echo la variable est stocké tronqué dans la base de donné mysql j'utilise varchar(255) pour un titre ce qui devrai largemen suffire.
-Sur apache je vien de regarder je ne vois nul part utf8 ou meme iso, j'ai trouvé la fonction addDefautcharset que j'ai rajouté dans le fichier de config apache.
-bdd engine = innodb charset = utf8.

    mysql_query("CREATE TABLE produits (id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
                                                       titre VARCHAR(255),
                                                       lien VARCHAR(166),
                                                       img VARCHAR(166),
                                                       descript VARCHAR(255),
                                                       price DECIMAL(30,2) default '0.00',
                                                       currency VARCHAR(4),
                                                       catname VARCHAR(166),
                                                       created DATETIME NOT NULL) ENGINE=InnoDB CHARSET=utf8;")OR die(mysql_error());

-flux en utf8 enfin c'est ce qui est écris mais je commence a douter , que ça soit vraiment le cas...

Donc je me repette le seul problème c'est que les mots son tronqué exemple avec la phrase que je vien de dire :
ème c'est que les mots sont tronqué.

Plutôt bizarre comme erreur car je vien de faire un mb_detect_encoding sur mon passage de variable et voila ce qu'il en sort .

ASCII     <mot sans accents
ASCII
UTF-8    < Résine
ASCII
ASCII
ASCII

ET voila ce quil me fait :

Colle pour capsules - 2g (#12325)ASCII
RASCII
ésine liquide - 30ml (#40920)UTF-8
Colle express 14,2g (#40507)ASCII
Ramette papier discovery a3 70g blancAS

En faite il code le début du mot R en ascii et ensuite le reste en UTF-8 ! le problème doit concrètement venir de la

 

[calligan]

Finalement j'ai fini par reprendre le parse dom xml qui fonctionne bien et sans problème d'encodage dommage ...
Car j'en ai profiter pour bencher les deux type de parse.

pour le traitement d'un flux xml avec 22697 entrée :
sax xml_parse = 23minutes et 35 sec
xml dom parse = 34minutes et 30 sec

:cry: