Pour un développement que je suis en train de réaliser, j'ai besoin de générer du XML pour de l'AJAX notamment. Je me suis dit, pourquoi pas utiliser les possibilités de jelix au lieu de créer "un truc" à part.

Je m'y suis donc attelé et je suis tombé sur un problème. J'ai créer un controller dédié à la génération de réponse XML. Dans ce même controller, je récupère des données d'une base que je réinjecte dans la réponse XML. Mais je me suis aperçu que les caractères accentués comme 'à', 'é', 'è', etc... faisaient planter lamentablement l'exécution de mon appli lors de la génération du XML. Je suis penché sur la question et je me suis rendu compte que la fonction php simplexml_load_string() pose problème. C'est elle en fait qui rejette les caractères accentués. C'est peut être du au fait que la chaîne que je lui passe n'est pas au format UTF-8 mais j'en suis vraiment pas sûr.

J'ai cherché dans le code de jelix l'endroit au ça ne passe pas. C'est à la ligne 104 du fichier lib\jelix\core\response\jResponseXml.class.php que la fonction est appelée pour faire une vérification de la validité (au sens XML) de la chaîne de caractères si j'ai bien compris.

Voici le code :

 if (simplexml_load_string($xml_string)) {
 ...

Et voici comment je l'ai modifié pour contourné mon problème !

 if (simplexml_load_string(utf8_encode($xml_string))) {
 ...

Je ne sais pas si c'est une bonne solution, mais s'il y a d'autres méthodes pour contourner ce problème, je suis preneur !

lui fournir directement de l'utf-8 peut-être ?

Ha cette mauvaise habitude d'utiliser de l'ISO-8859-1 j'ai la même au boulot en ce moment sur une application a maintenir bon courage. Et heuresement que tu utilise pas du JSON parce que json_decode ne fonctionne pas en ISO-8859-1, ma solution temporaire (attention mon appli utilise pas jelix) ça été de créer des façades ou les données sont ré-encodées a chaque fois au niveau de l'accès au données.

désolé, mais je ne modifierai pas jResponseXML pour ajouter ce truc...

De toute façon, faire comme tu as fait, c'est très mal. À la prochaine mise à jour de jelix, ça te petera à nouveau à la figure. Il aurait mieux valu te créer ton propre objet réponse, héritant de jResponseXML, et rédefinir la méthode concernée (cf manuel sur les réponses personnalisées). ça aurait déjà été beaucoup plus propre.

M'enfin la meilleur solution : converti le contenu de ta base !! TOUT DE SUITE !

se trainer un boulet comme les charset iso-*, ce n'est franchement pas viable à moyen terme. tout les outils, les langages, les libs passent à utf-8. Faire de l'iso de nos jours, c'est du suicide au niveau interoperabilité. Je dirais même de l'incompétence pour celui qui démarre une nouvelle base/projet.

Surtout que faire une convertion vers utf-8 n'est pas ce qu'il y a de plus difficile (en particulier avec mysql).

Et la on te répond. "Mais sans l'ISO-8859-1 comment vas t'on faire pour avoir le symbole € ?" Véridique ! Bref tout ça pour dire que de nombreuses légendes courent sur les charset, et dans bien des cursus de formation t'en entend tout simplement pas parler, j'ai eu un stagiaire en BTS d'informatique orienté Anal/Prog et la seule chose qu'ils avaient entendu a propos des charset c'est d'utiliser ISO-8859-1 pour faire du web.

@axel

Mais sans l'ISO-8859-1 comment vas t'on faire pour avoir le symbole € ?

bah tu leur répond qu'on peut écrire tout les caractères du monde entier avec utf-8 , dont le symbole € :-)

@manu14

Le seul souci, c'est que la méthode est déclarée final. Donc je ne peux pas la redéfinir !

ah oui, embétant, je ne me rappelais plus :-).

Et si c'est une contrainte du projet

Je ne sais pas de quel type de contrainte il s'agit, mais je ne vois pas ce qui t'empêche de renvoyer de l'UTF-8. Tu peux configurer la connection avec la base de donnée pour qu'elle te renvoi toujours de l'UTF-8, surtout si c'est du mysql (essaye déjà force_encoding=on dans le profil jdb, en indiquant aussi le charset UTF-8 dans la config générale).