Comment passer son site en utf-8

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

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

  • 1

    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

  • 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

    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

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

  • 2

    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

  • 1

    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

  • 2

    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

  • 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.

    • 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

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