Comment passer son site en utf-8

Publié le : 19 mai 2004 – Dernière modification le 21 décembre 2021 – par Fil – 43 commentaires

1
2
3
4
5
1 vote

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Ce script vous permet de convertir votre dump de la base de données, de iso-8859-1 vers utf-8.

ATTENTION : cet article est obsolète. Le convertisseur de jeux de caractères vers utf-8 est désormais intégré à SPIP 1.9, et beaucoup plus facile et sûr que la méthode exposée ci-dessous.

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, &eacute;... 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).

Si vous avez converti votre site grâce à cette méthode, je vous remercie de le signaler, soit dans le forum ci-dessous, soit en m’envoyant un mail privé, indiquant son URL.

PS : Pour convertir depuis l’arabe (windows-1256), il faudra au préalable ouvrir le fichier du script et modifier la valeur de $import_charset.

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

17 discussions

  • ben

    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

  • 1
    Tomtom

    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 ;)

    • Tomtom

      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

  • frederiko

    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

  • 8
    monsieurL

    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.

    • Alexandra

      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

      [(#REM) Preciser le charset ]
<meta http-equiv="Content-Type" content="text/html; charset=#CHARSET" />
    • monsieurL

      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.

    • monsieurL

      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

    • monsieurL

      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 ??

    • Fil

      essaie :

      #HTTP_HEADER{Content-Type : text/html; charset=#CHARSET}

    • Fil

      Désolé, un espace en trop :

      #HTTP_HEADER{Content-Type: text/html; charset=#CHARSET}

    • monsieurL

      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.

    • monsieurL

      Heu correction : pas de Pb d’accent, au contraire, mais pb de fonctionnement de mes Javascript....

    Répondre à ce message

  • 2
    FdM

    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

    • Fil

      Bien vu. J’ai ajouté un chapô indiquant que l’article est obsolète.

    • Bionet

      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

  • jeronimo

    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

  • 1
    sholby

    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.

    • Fil

      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

  • RealET

    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

  • 2
    Louis

    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

    • Dom75

      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

  • 2
    David Olivier

    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.

    • Fil

      Merci pour ce retour très complet !

      Et n’hésite pas à signaler ton site dans la liste des sites sous SPIP

    • David Olivier

      À 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 :

      native2ascii -encoding windows-1252 <dump.xml | \
  native2ascii -reverse -encoding utf-8 >dump-utf8.xml

      a pour effet de transformer CR+LF en LF seul.

      Par contre, avec iconv :

      iconv -f CP1252 -t UTF-8 <dump.xml >dump-utf8.xml

      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 :

      <?xml version="1.0" encoding="iso-8859-1"?>

      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

  • George

    J’ai passe mon autre site en UTF-8, mais il n’y a aucun serveur qui va permettre un temps d’execution de 10 min. J’ai du faire le tout en local puis de telecharger le fichier dump-utf8.xml (30Mb) par ftp sur le serveur.

    Répondre à ce message

  • 1
    #Olivier

    L’opération s’est globalement bien passée.

    J’ai eu quelques souscis avec les symboles € (ils ont disparu des articles suite au passage en utf-8 / j’ai rajouté les € a posteriori).

    Plus quelques apostrophes « fantôme » (dans certains articles et pas tous : bizarre). Les apostrophes apparaissent normalement sauf lorsque l’on veut modifier l’article, ces apostrophes disparaissent dans l’interface d’édition. Si on rajoute les apostrophes manquantes et que l’on valide, on se retrouve finalement avec deux apostrophes !

    A part cela, RAS.

    • Fil

      Merci pour l’info.

      Ton site était probablement en iso-8859-15 ? Ces caractères-là n’existent pas, pour ce que j’en ai compris, en iso-8859-1.

    Répondre à ce message

  • Fil

    Nouvelle version du script :
    — compatible windows-1256 ;
    — suivi de la conversion dans le fichier spip.log

    Répondre à ce message

  • Soÿ

    Tout a marché comme sur des roulettes
    ...
    mis à part que tout le contenu de mes champs extras a purement et simplement volé dans la manip.
    Y’a plus un champ extra rempli :D

    Le problème n’est pas énorme vu que j’ai mon site en double, commencé depuis peu, et que je peux repiquer « à mano » les infos ... mais si j’avais eu 2 ans de saisie de champs extra ... j’aurais à coup sûr fait une crise cardiaque !

    En tous cas, voilà une initiative d’uniformisation des langages (codage et lecture) heureuse.

    Bien à tous

    Soÿ

    Répondre à ce message

  • 2
    Suske

    Comme je l’ai écrit le 6 mai, la conversion s’est faite sans problème... Sauf que j’ai découvert depuis que les stats du site sont vidées avant le 6 mai... dommage.

    • Fil

      Tu as vidé ta base avant de recharger la sauvegarde ? La sauvegarde ne contient pas les stats ? Hum...

    • Fil

      Je confirme : la sauvegarde ne contenant ni les statistiques, ni les référers, ni les messages privés :

      — ceux-ci sont détruits si tu effaces la base ;
      — les messages privés ne sont pas convertis en utf-8.

      (Ce commentaire correspond à toutes les version de SPIP, au 12 mai 2004 ; ça pourrait évoluer par la suite).

    Répondre à ce message

  • 3
    JFB

    OK merci FIL, on va essayer de rebabeliser ... mais ...
    qq chtites kouetches :
    -  pourquoi faut-il nettoyer les caractères accentués dans les skelettes et pas seulement dans le DATA ?
    -  si je lis bien ton script, il faudrait également modifier le

    <?xml iso-8859-1 en <?xml utf-8 dans les skelettes
_ ... mais pour les skel qui sont encore en HTMLxx ??
_ i.e. idem pour ceux qui ne signalent pas le 'lang' ??
- où peut-on trouver une table de toutes les correspondances pour transcoder de l'iso éàùê vers les entites_html ?
- idem pour les caractères Copyright & co .. 

Merci
    • Fil

      A propos du bidule XML, c’est inutile (juste une fioritue que j’ai ajoutée dans le code).

      A propos des squelettes, j’ai oublié de signaler dans l’article qu’il fallait vérifier que les squelettes contiennent bien la ligne précisant le #CHARSET : je l’ajoute.

    • JFB

      merci pour l’info sur le META CHARSET, j’aurais du y penser :-/

      .. tiens moi aussi je bosse (HI ...partiellement) :
      j’ai trouvé une table de correspondance qui m’apparait complète pour les utilisateurs de l’iso-latin (à tester par les pro, je ne suis pas pro) :
      -  http://www.trucsweb.com/HTML/trucs....

      (PS : un remarque destinée au ouèpmestre de spip-contrib (je la vois car je suis dans le formulaire-forum : ne serait-il pas interessant d’avoir ET l’article originel ET le commentaire auquel on répond A COTE à Gauche, au lieu de n’avoir seulement que l’article originel EN DESSOUS ??
      ... et une liste des smileys, tant qu’on y est, non ? ;-) )

    • Suske

      Pour moi, tout s’est passé sur des roulettes !

      Suggestiuon concernant le texte (!)

      Une fois que vous avez exporté votre base en iso-8859-1 dans le fichier ecrire/data/dump.xml (ou ecrire/data/dump.xml), (...)

      Bref, deux fois ecrire/data/dump.xml . Il manque un petit .gz...

      J’avais dit que c’était pour fignoler ;-)

    Répondre à ce message

  • 4
    spipjfb

    .... tiens voilà le résultat ... grrr heureusement que c’est un de mes qq sites de test ;)
    -  ... j’ai modifié les skel
    -  ... j’ai chargé le changer_charset
    -  ... j’ai fait mouliné ( zéro pb)
    -  ... j’ai paramétré le uft-8 dans le site
    -  ... j’ai vidé le cache ( il y a eu un plantage page inaccessible) et j’ai revidé (il laissait tous les skel_machin.php3, avec un .htaccess) puis à la main => totalement vide
    -  ... j’ai réindexé

    • Fil

      Mais pourquoi #CHARSET s’affiche-t-il en clair dans la page, hein ?

    • spipjfb

      ... peut-être que c’est tout simplement la moulinette qui a coincé (site en 1.7.1) ?

      car j’ai constaté qu’un clone du site sur la même base sql était devenu illisible avec ses anciens skel resté en iso-latin avec un SPIP également resté en iso-latin

      http://www.burtega.net/eva7/article...
      (... un bon vieux skel EVA de derrières les fagots )

      j’ai recommencé la restauration du dumputf8 à la main .. ; et apparement rien n’y fait ( ou alors j’ai fait une grooooossière erreur vu l’heure tardive (le #CHARSET est pourtant installé) ???

      Ce qui est curieux est que le rubricage fonctionne bien dans le menu déroulant à droite et que l’encodage fonctionne avec les liens en dur [ :/
      ... mais que le rubricage de l’ancien skel Eva (iso) est lui perturbé... je vais me coucher ;)

      .. ; je retenterai la moulinette demain, bonne nuit ...des fois SPIP ça s’arrange tout seul pendant la nuit ;)

    • spipjfb

      je suis hebergé sur PHPnet/OVH

      infophp

      @+ (soupir déçu .. ; comme pour spikini ...)

    • Fil

      Ah oui, tu utilises <INCLURE(metatags.html)> ; si tu veux avoir une chance de fonctionner, déjà cela devrait être <INCLURE(metatags.php3)>.

    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 :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

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.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom