Vous avez probablement commencé à utiliser SPIP dans le jeu de caractères iso-8859-1
, qui correspond à l’intallation standard. Mais ce jeu est limité aux caractères occidentaux, et voilà que votre site doit devenir multilingue ; il est temps de passer à utf-8
. Pour en savoir plus, vous pouvez lire Voyage dans la tour de Babel du net.
Remarque : à ceux qui s’inquiéteraient des risques d’un tel changement : d’après mon expérience sur des sites comment www.spip.net ou www.monde-diplomatique.fr, personne ne s’est plaint. Cela signifie donc que les navigateurs qui ne sauraient pas lire l’utf-8
ne sont plus du tout en circulation. (Bien entendu, ce n’est peut-être pas le cas dans des applications très spécifiques.)
- Commencez par vérifier vos squelettes. Ceux-ci ne doivent en effet contenir aucun caractère accentué sous forme « brute » : il faut donc éliminer tous ces « é » des squelettes, et les remplacer par leur entité html, é
... il faut ensuite vérifier qu’ils contiennent bien, dans la partie <head>...</head>
, la ligne suivante :
<meta http-equiv="Content-Type" content="text/html; charset=#CHARSET">
- Procédez à une sauvegarde de la base de données. Selon la méthode habituelle, au format dump.xml
ou dump.xml.gz
.
- Convertissez la sauvegarde au format utf-8
.
Pour cela, installez le script ci-dessous dans le répertoire ecrire/
, puis ouvrez la page avec votre navigateur, et suivez les instructions (une nouvelle authentification ftp est nécessaire).
Vous pouvez suivre l’opération de conversion (qui peut durer plusieurs minutes sur un gros site !) en regardant le fichier ecrire/data/spip.log
: il doit se terminer par une mention « conversion effectuée ».
Si la conversion a fonctionné normalement (sans timeout), vous pouvez réimporter la base ecrire/data/dump-utf8.xml
. (N’ayez crainte : si le résultat ne vous convient pas, il sera toujours temps de réinstaller la sauvegarde dump.xml
.)
N. B. : si votre base de départ n’était pas en iso-8859-1
, les résultats seront imprévisibles, et sûrement pas très bons :)
- Configurez le site. Rendez-vous dans la configuration du site, partie « Gestion des langues », et indiquez à SPIP que le charset de la base est désormais utf-8
. (Cette option n’est disponible que si vous êtes en interface complète).
- Videz le cache. Il est impératif de vider le cache, sinon certains navigateurs n’arriveront pas à afficher des pages se présentant comme de l’utf-8
(d’après les nouveaux réglages de SPIP) mais contenant des caractères iso-8859-1
(encore présents dans les « vieux » fichiers cache).
Discussions par date d’activité
17 discussions
Juste pour signaler que même si cet article est périmé, il est bon d’aller voir juste à coté ici : http://contrib.spip.net/Convertir-un-site-SPIP-3-en-utf-8-avec-le-plugin
Répondre à ce message
Merci beaucoup pour cet article...
En local, je ne comprenais pas comment faire ? J’étais obligé de choisir manuellement l’encodage des caractére > Unicode !
En fait il faut tous simplement ajouter la ligne suivante dans son header :
Et le navigateur choisit automatiquement UTF-8 !
C’est parfait, merci pour cet article !
Par contre en local (easyphp), j’ai l’erreur suivante :
Warning : Compilation failed : this version of PCRE is not compiled with PCRE_UTF8 support at offset 0 in c :\easyphp\www\v3\ecrire\inc\charsets.php on line 108
Si quelqu’un à eu le même soucis, je suis preneur ! (Sur d’autres sites j’avais eu ce soucis et une fois le site mis en ligne, cela se corrige !). Mais j’aimerais bien à ne plus avoir cette erreur !
Merci d’avance ;)
J’ai corrigé mon erreur...
Il fallait juste passer sous la dernière version de easy php ! Sa faisais un moment que j’avais le soucis, mais en se plongeant bien sans le problème, on arrive à toujours trouver une réponse ! ;)
Répondre à ce message
J’ai essayé cette solution qui n’a pas fonctionnée. Pourquoi ? aucune idée (pourtant j’ai essayé plusieurs fois avec plusieurs méthodes en local avec easy php, sur free, etc.).
Désespéré, même si je n’ai ’que’ 300 articles à revoir j’allais abandonner et me résigner à tout retaper quand je me suis dit qu’un fichier dump.xml ce n’est que du texte.
Or, pour les sites que je réalise en espéranto j’utilise un éditeur de texte qui si j’ouvre un nouveau document, colle un texte en iso-8859-1 et enregistre en unicode me fait directement la conversion.
J’ai donc ouvert dump.xml avec wordpad puis collé le texte dans unired (le logiciel en question). Puis à la main j’ai remplacé en tête du document iso-8859-1 par UTF-8 et enregistré sous un autre nom (dump-unicode.xml). Une fois la base rechargé dans spip...
Merveille : ça marche.
le site d’unicode : http://www.esperanto.mv.ru/UniRed/UTF8/index.html
Autre merveille, c’est gratuit, sous licence libre et en 7 langues... avec des correcteurs orthographique et ça ne pèse que 857 ko.
Est-ce que quelqu’un a dit que l’esperanto ne servait à rien ?
Répondre à ce message
Bonjour,
J’ai installé un SPIP 1.9.1 en test et en le paramétrant en UTF-8 ansi que ma base. Cependant Il n’affiche pas les accents correctements sur les documents saisies aprés ces modifications. Le seul moyen est mettre la base et SPIP en iso-8859-1.
J’ai vérifié les en-têtes des squelettes, elles sont correctes ("").
Quelqu’un peut-il m’éclairer SVP ?
Cordialement.
Dans configuration, gestion des langues, domaine/ecrire/ ?exec=config_lang, tu as un lien pour une moulinette de conversion d’iso en utf-8.
Domaine/ecrire/ ?exec=convert_utf8
Ton répertoire ecrire/data doit etre en 777.
Fais une sauvegarde avant de ta base en iso, c’est plus prudent meme si la moulinette est très fiable.
Ensuite, dans tes squelettes, met bien
Bonjour,
Merci pour l’info.
Malheureusement, Ca ne résoud pas le problème, ni pour les anciens documents, ni pour ceux entrées aprés la manip ??? :-(
Alors que ma base et SPIP sont bien UTF-8 !!
J’ai bien mis meta http-equiv=« Content-Type » content=« text/html ; charset=#CHARSET » dans l’en-tête (dans la balise head).
Cordialement.
J’ai finalement trouvé le problème :
Dans mes squellettes, j’avais ajouté l’en-tête #HTTP_HEADERContent-Type : text/html. Il semble que cela pose problème, car en le supprimant, je supprime aussi le problème.
Cordialement
Re-Bonjour,
Je viens de m’appercevoir, que j’ai absolument besoin de cette balise #HTTP_HEADER !!
Je suis coincé.
Help....Quelqu’un ç une solution ??
essaie :
#HTTP_HEADER{Content-Type : text/html; charset=#CHARSET}
Désolé, un espace en trop :
#HTTP_HEADER{Content-Type: text/html; charset=#CHARSET}
Non, ça ne marche pas.
La balise n’est pas prise en compte, donc pb d’accent.
En fait j’ai besoin de cette balise, car sans elle, les boutons d’administrations empêchent apparemment mes fonctions javascript de fonctionner.
J’ai bien essayer d’activer $flag_preserver=true (qui va être abandonné à la version 2) qui est censé désactiver ces boutons.... mais ça ne marche pas.
Merci qu’en même.
Heu correction : pas de Pb d’accent, au contraire, mais pb de fonctionnement de mes Javascript....
Répondre à ce message
Y a-t’il une actualisation prévue pour la version 1.9 ? Elle serait la bienvenue compte tenu des nouveautés de cette version
Bien vu. J’ai ajouté un chapô indiquant que l’article est obsolète.
Bonjour Fil,
pourrais-tu nous mettre également un lien vers une explication de fonctionnement du convertisseur de SPIP 1.9. Pour ma part, j’ai un des admin qui a modifié la config du site et l’a passé en UTF-8 et tous les anciens articles se retrouvent avec des caractères accentués vraiment nuls ;-)
Merci pour tout Fil,
Bien cordialement,
Répondre à ce message
Si l’on a des articles en utf8 et en iso comment adapter ce script. En effet si l’on utilise la fonction de conversion utf8 sur du texte qui est déjà en utf8 on obtient des caractères « copyright » ou « $ » . Donc comment faire un test sur le type de codage du texte. J’utilise cette routine pour insérer des articles qui peuvent être en Iso ou en utf8, je ne l’utilise pas sur le Dump. Merci.
Répondre à ce message
Je viens également de convertir mon tout nouveau site web en Spip (que j’avais assez bêtement commencé en Latin-1) en utf-8 grâce à cet excellent script. Merci Fil !
Et merci aussi à Louis, puisque ce n’est qu’après avoir intégré sa modification que ça a fonctionné correctement.
J’ai proposé une variante qui intègre cette modification, en plus d’utiliser des extensions en .php au lieu de .php3.
Louis et toi avez raison, et je n’aurais pas dû laisser traîner — le zip contient maintenant la correction demandée (par contre ça le fera peut-être échouer sur des versions plus anciennes de SPIP).
Répondre à ce message
J’ai utilisé cette contrib avec un export SQL depuis phpMyAdmin (dernière version qui permet de faire un export des BLOB non encodé en hexa) et ça a parfaitement marché.
Merci Fil
Répondre à ce message
Bonjour,
Merci pour cette contrib, qui cependant a nécessité une bidouille pour fonctionner.
J’ai du changer la ligne de code suivante dans la fonction my_charset_utf8 du script « changer_charset.php3 » :
$t = charset2unicode(chr($i),$charset_import) ;
en
$t = charset2unicode(chr($i),$charset_import,true) ;
Sinon la valeur par défaut du dernier paramètre est false, ce qui empèche la conversion de s’efectuer normalement.
en effet la ligne suivante :
if (!$forcer) return $texte ;
dans la fonction charset2unicode est un magnifique croche patte qui vous fera perdre une bonne heure voire plus !
Mais cela peut être lié au faite que je suis en version SPIP 1.8a2.
Merci de m’en informer si vous en savez plus à ce sujet.
Et merci encore au généreux contributeur, car si j’avais du écrire la fonction, ce n’est pas une heure mais quelques jours que j’y aurais passé !
SPIP SPIP SPIP ... HOURRA
Miracle, enfin la reponse a mon probleme avec ce script, mais je n’y ai passe que 30 minutes !!!!!
J’ai installe SPIP il y a seulement deux semaines, avis aux nouveaux venus
merci merci merci !!! A l’auteur du script mais aussi à Louis pour son astuce sans laquelle je n’aurai jamais trouvé la solution. Maintenant mon site peut-être syndiqué partout dans le monde (ce n’est pas forcément pour l’intérêt ;-))
Répondre à ce message
Merci pour ces instructions. Bien que je n’aie pas utilisé votre script, elles m’ont fait comprendre le principe (assez simple) du basculement, la liste des choses à penser (squelettes, cache), et surtout m’ont fait découvrir (je suis un peu nouveau en spip) l’existence de cette sauvegarde en dump.xml.
Plutôt que d’utiliser votre script, j’ai trouvé plus simple rapatrier le fichier chez moi, le convertir en utf-8, le remettre en place et restaurer. Je comprends l’intérêt du script pour les gros sites, quand le transfert du dump.xml.gz devient impraticable. J’ai fait la conversion sous Mac par BBEdit, c’est immédiat ; sinon, sous Unix (Mac, Linux, ...) il y a aussi iconv et native2ascii (dans le package Java). Sous Windows aussi je suppose qu’il y a ce qu’il faut.
Un oubli dans vos instructions : penser aussi à corriger le nom du site, s’il comportait des accents.
J’ai eu un petit problème, qui m’a obligé à refaire la conversion et l’importation. Ce n’est pas moi qui ai installé mon site, et pour une raison que je n’ai pas bien comprise il était de fait non en Latin-1 (= ISO-8859-1), mais dans sa variante Windows, qui en diffère en particulier par le codage de ’œ’ et de ’€’. Pourtant, sur la page d’administration, il était indiqué « iso-8859-1 » tout court. Je ne sais pas trop si ça vient de SPIP, du php installé chez mon hébergeur, ou quoi d’autre. Donc un conseil aux usagers : vérifiez bien la conversion des œufs et des euros, on ne remarque pas forcément tout de suite le problème, et si on le remarque plus tard ça peut être un peu la catastrophe.
Sinon, je suis content, en une demi-heure tout mon site (Les Cahiers antispécistes) est passé en utf-8, alors que ça faisait un moment que j’en rêvais, en pensant que ça allait être la grosse galère.
Merci pour ce retour très complet !
Et n’hésite pas à signaler ton site dans la liste des sites sous SPIP
À vrai dire, j’ai eu un autre petit souci, suite à la conversion.
Dans le dump.xml, les données ont des fins de ligne en CR+LF. C’est logique, vu qu’ils sont chargés par des formulaires HTML, pour qui le standard est CR+LF. Mais il se trouve que l’outil que j’ai utilisé pour convertir - BBEdit - me les a tous transformés en LF+LF, ce qui fait qu’en définitive je me suis retrouvé avec toutes les fins de lignes doublées.
C’est généralement sans conséquences sur la présentation des textes en ligne (sauf s’il y a une mise en page forcée par <pre>...</pre>, par exemple), mais ça ne m’a pas bien plu (les textes sont quand même présentés dans les formulaires d’édition avec 3 lignes blanches au lieu d’une entre chaque paragraphe !).
Alors j’ai testé les autres outils que j’ai mentionnés. Ils s’avère que le pipe :
a pour effet de transformer CR+LF en LF seul.
Par contre, avec iconv :
on préserve les CR+LF, ce qui est l’idéal.
Comme j’ai d’abord testé une troisième solution, qui, comme native2ascii, supprime les CR (sed -e ’s/^V^M//’ puis BBEdit), et que cette suppression semble sans conséquences, je vais garder les choses comme ça, mais l’idéal me semble la solution iconv, le but de la manœuvre étant bien de convertir en utf-8 en changeant le moins possible le reste.
Ces deux méthodes laissent intacte le tag XML au début du fichier, qui indique donc de façon erronée :
alors qu’il s’agit d’un fichier utf-8. Je suppose que c’est sans conséquences. Je ne sais pas si le script de Fil corrige ce tag ?
Merci pour l’indication de la page des sites sous SPIP, je m’en vais inscrire le mien.
Répondre à ce message
Ajouter un commentaire
Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :
Merci d’avance pour les personnes qui vous aideront !
Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.
Suivre les commentaires : |