UTF-8 sur un Pluxml tout neuf
Bonjour,
Je reviens sur la question de l'encodage des caractères. J'ai inséré dans mon template des feeds récupérés via Simplepie. Pour avoir un affichage correct de ceux-ci, il me faut de l'UTF-8. Je me trouve donc actuellement à devoir choisir entre un bon affichage de Pluxml ou un bon affichage des flux. :-/
J'ai vu sur un message plus ancien qu'il était possible de faire une conversion des fichiers. Je n'ai encore écrit aucun article. Tout est d'origine à part le template modifié. Y a-t-il une méthode simple pour faire la conversion ?
Merci de votre aide.
Je reviens sur la question de l'encodage des caractères. J'ai inséré dans mon template des feeds récupérés via Simplepie. Pour avoir un affichage correct de ceux-ci, il me faut de l'UTF-8. Je me trouve donc actuellement à devoir choisir entre un bon affichage de Pluxml ou un bon affichage des flux. :-/
J'ai vu sur un message plus ancien qu'il était possible de faire une conversion des fichiers. Je n'ai encore écrit aucun article. Tout est d'origine à part le template modifié. Y a-t-il une méthode simple pour faire la conversion ?
Merci de votre aide.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
D'après ce site :
http://blog.neovov.com/index.php?2007/03/06/143-convertir-un-site-en-utf-8
Il faut convertir tout un tas de choses. Je suppose que dans mon cas, avec Pluxml, certaines étapes sont inutiles.
Que reste-t-il à faire ? Juste modifier les headers et les metas de tous les fichiers en les enregistrant en format utf-8 ?
J'ai retrouvé cette discussion sur le forum :
http://forum.pluxml.org/viewtopic.php?id=435
mais elle concerne les versions instables.
Merci de votre aide.
- Modifier le prolongue Xml donné à chaque fichier Xml (iso->utf)
- Corriger l'encodage utilisé par le déparseur php
- Indiquer l'utf dans le template
- et voir si le contenu des articles nécessiteront d'être encodés de façon particulière.
Bon courage
Merci pour ta réponse bien complète.
Pour les articles, il n'y en a encore qu'un seul, celui fourni avec l'installation. Ce sera la partie la plus rapide.
Merci encore, je tente ça demain, je viendrai raconter après.
En remplaçant toutes les expressions "iso-..." par "UTF-8" dans tous les fichiers (template défaut2 compris), Pluxml fonctionne impeccablement.
MAIS, effectivement, quand on enregistre un article, il s'affiche correctement dans la partie publique et bizarrement dans la partie admin. Donc, si on veut modifier un article, il faut d'abord corriger les accents auparavant. Sauf si on écrit les caractères accentués et spéciaux avec leur équivalent HTML (&####; ), ils s'affichent alors correctement à la publication et restent en HTML dans la partie admin, donc tout reste nickel.
Je vais pousser un peu le bouchon pour vérifier avant d'affirmer une totale réussite, mais ça se présente bien.
Oui, j'ai corrigé tous les entêtes, y compris dans l'admin, mais sans succès.
Pour moi, c'est suffisant pour que je puisse commencer à utiliser Pluxml mais je continue à chercher l'astuce qui évitera ce problème.
Toutes mes félicitations pour ce petit CMS super génial. Il faut absolument le conserver lightissime pour qu'il puisse répondre à un maximum d'attentes.
Les seules suggestions que je fais sont :
1) une intégration enfantine des plugins (comme dans Dotclear ou WordPress, par exemple)
2) un formulaire de contact d'origine. Je crois que c'est absolument indispensable de l'avoir quelque soit l'utilisation qu'on prévoit.
Encore bravo et merci du soutien !
Je rapporte le même problème dans l'admin (avec le texte des articles édités, pas lors de l'écriture, et avec les titres de catégories).
De plus, si on utilise le greffon de recherche (installation pluxml avec SearchModule), aucun problème pour la recherche en elle-même, mais l'invite à faire une nouvelle recherche (avec un second champ qui reprend le contenu de la recherche qu'on vient d'effectuer) s'affiche mal dès qu'on a cherché des caractères exotiques. Serait-ce dû à la façon dont sont retournées les chaînes de caractères ? PHP demande-t-il quelque chose de spécial lorsqu'il travaille avec de l'Unicode ?
Autre chose, dans le répertoire de conf, où les fichiers sont créés lors de l'installation, le fichier password.xml est généré en ISO-8859-1 alors que les deux autres sont bien en UTF-8... Ça reste une énigme pour moi.
En espérant faire avancer le schmilblick :-)
Donc je pense que tant que ces fonctions ne sont pas installer dans les fonctions qui permettent l'écriture d'un article ou de la modif d'un article sa ne marchera pas (d'ailleurs, vous avez testé l'ajout d'un commentaire voir si il était en utf-8 ?).
Pardon pour mon ignorance de PHP, mais ces fonctions convertissent une chaîne entre l'UTF-8 et l'ISO-8859-1... Ça veut dire qu'une chaîne est forcément en ISO-8859-1 à la base ? Si tout est en UTF-8 à l'origine il est toujours besoin de passer par ces fonctions ?
j'essai actuellement de mettre pluxml en utf-8 mais il subsiste quelque problème donc j'vais essayer de régler tout sa, voici l'adresse du site de test pour qui vous voyez les avancements : http://heroesfan.free.fr/flopa-18/ (oui le site tourne sous la flopa 18).
Pour info j'ai remplacer tout les iso-8859-1 par utf-8 et modifier la fonction write du fichier lib.util.php par fwrite($f, utf8_decode(utf8_encode(trim($xml)))); # On écrit
J'ai aussi modifier la fonction htmlentities() par htmlspecialchars() dans les area du ficher articles.php situé dans le dossier admin.
Les problèmes arrivent lors de l'ajout d'un commentaire, il n'accepte ni d'autre langue, ni les accents
Quand je veux voir le commentaire sur ton site de test (pour l'article japonais), fightsoul, j'ai une erreur 500...