Convertir un site SPIP 3 en utf-8 avec le plugin Grenier

Publié le : 8 janvier 2014 – Dernière modification le 27 janvier 2024 – par erational – 34 commentaires

1
2
3
4
5
18 votes

Et SPIP 4 ?

Cet article est une archive pour les sites en SPIP 3 qui n’étaient pas encore en utf-8

Pour SPIP 4, le plugin grenier ne propose plus ces fonctions de conversion en utf-8.

La solution est d’utiliser spip-cli qui fournit une commande en ligne pour convertir en utf-8 (pour un site en mysql)

spip sql:convert:toutf8

Convertir un site SPIP 3 en utf-8 avec le plugin Grenier

SPIP 3 fonctionne nativement avec l’encodage universel unicode utf-8.

Sur certains sites (par exemple sur une mise à jour), on peut avoir un site qui est resté en iso-latin ce qui n’est pas conseillé (source de bugs, d’incompatibilité, ...) .

Voici la manière de le convertir simplement en utf-8.

  1. Télécharger et activer le plugin Grenier
  2. Faire un sauvegarde de votre site (à la fois en créant un dump SPIP mais aussi un export MySQL sous phpMyAdmin pour pouvoir restaurer l’existant en cas de problème)
  3. Se rendre sur la page ecrire/?exec=base_convert_utf8
  4. Lancer le script !

Autre script lié à l’encodage de la base de donnée
Le plugin grenier dispose aussi d’un autre script qui lui permet de modifier l’interclassement de votre base pour le repasser en utf-8 si ce n’est pas le cas.

Par exemple : vous avez un site SPIP déclaré en unicode mais l’interclassement est resté en latin. (Si vous l’éditez sous phpmyadmin, les champs sont encodés bizarrement).

Dans ce cas, il faut appeler le script ecrire/?exec=base_convert_sql_utf8

Cas d’une base sqlite
Pour le cas très particulier des personnes avec une base en Sqlite.
Voici les lignes de commandes requises pour convertir votre base (astuce fournie par ben).

echo "On dump la base spip.sqlite dans un fichier dump.sql"  
echo ".dump" | sqlite3 spip.sqlite > dump.sql

echo "On convertit la base en utf8 à l'aide de l'utilitaire iconv" 
iconv -f iso-8859-1 -t UTF-8 < dump.sql > dump-utf.sql

echo "On reconstruit un fichier sqlite à partir du dump sql utf8" 
echo ".restore" | sqlite3 spiputf.sqlite < dump-utf.sql

echo "On met de coté la base iso"
mv spip.sqlite spip.sqlite.iso

echo "La base utf est maintenant la base spip "
mv spiputf.sqlite spip.sqlite

echo "Victoire (normalement) "

Autres ressources

Dans les cas où cela ne fonctionne pas, consulter aussi
http://zzz.rezo.net/Reparer-le-char...
Bouée de sauvetage utf8

Pour les versions SPIP 2.1

Pour les anciennes versions de SPIP, le plugin grenier n’est pas nécessaire, les scripts sont disponibles à l’adresse suivante depuis la partie privée :

  • ?exec=convert_sql_utf8
  • ?exec=convert_utf8

Discussion

5 ans 1 an 3 mois Sans limite
par date
Filtrer

15 discussions

  • DD

    Ce plugin est excellent ! Je ne sais pas si c’est voulu mais il ne s’affiche pas dans la liste des plugins sur la page ecrire/ ?exec=charger_plugin

    dd

    Répondre à ce message

  • 1
    pverrier

    Bonjour,

    J’ai un site sur lequel la conversion de la structure des tables ne s’est pas bien déroulée, au final certains champs se sont retrouvés en utf8, d’autres sont restés en latin1.
    Ce qui est dommage, c’est que les erreurs MySQL rencontrées ne sont pas affichées.
    Je propose donc l’ajout de cette ligne juste après l’affichage des requêtes de conversion exécutées :
    if (!_DEBUG_CONVERT && sql_errno()!=0)  print '<p style="color:red;">Erreur: '.sql_error().'</p>';

    Avec ces affichages j’ai pu identifier un premier problème lié à des index FULLTEXT, que j’ai pu régler.

    Puis un second lot d’erreurs lié à la conversion intermédiaire en BLOB comme ces exemples :

    SQL : ALTER TABLE spip_articles CHANGE statut statut blob   NOT NULL
    Erreur : BLOB/TEXT column 'statut' used in key specification without a key length

    SQL : ALTER TABLE spip_articles CHANGE export export blob  DEFAULT 'oui'
    Erreur : BLOB/TEXT column 'export' can't have a default value

    Provenant de cette portion de code (fichier base/convert_sql_utf8.php ligne 92) :

      $type_texte= $row2['Type'];
  $type_blob = "blob";
  if (strpos($type_texte,"text")!==FALSE)
    $type_blob = str_replace("text","blob",$type_texte);

    plus bas on exécute (L107) :
    "ALTER TABLE spip_$nom CHANGE $champ $champ $type_blob $default $notnull"

    En clair, le type destination est d’office blob sauf si le type orifinal est machinTEXT alors il devient machinBLOB. Je suppose qu’il faut passer provisoirement en binaire pour éviter une quelconque transformation des données lors du passage en utf8 (?). Toujours est-il que cette opération est refusée sur beaucoup de champs (généralement en VARCHAR). Faut-il s’en inquiéter ?

    Sont concernés les champs (soit avec une valeur par défaut, soit utilisés dans un index) :
    -  statut, export, lang, langue_choisie de spip_articles
    -  login, statut, source, webmestre de spip_auteurs
    -  objet, vu de spip_auteurs_liens
    -  langue_choisie de spip_breves
    -  media, mode, distant, extension de spip_documents
    -  objet, vu de spip_documents_liens
    -  objet, statut de spip_forum
    -  objet de spip_jobs_liens
    -  nom, impt de spip_meta
    -  objet de spip_mots_liens
    -  actif, installe, superieur, obsolete, attente de spip_paquets
    -  statut de spip_petitions
    -  prefixe de spip_plugins
    -  lang, langue_choisie de spip_rubriques
    -  statut de spip_signatures
    -  statut, moderation, miroir, oubli, resume de spip_syndic
    -  url, statut de spip_syndic_articles
    -  extension, inclus, upload, media_defaut de spip_types_documents
    -  url, type de spip_urls
    -  objet de spip_versions
    -  objet de spip_versions_fragments
    (sans parler des autres champs ou tables non installées par le core)

    Ca fait beaucoup de champs en erreur sur cette étape de conversion en BLOB ; cela dit, beaucoup d’entre eux contiennent des chaînes prédéfinies (objet, langue, statut) qui ne poseront pas de problème.

    J’ai modifié le script pour qu’il affiche les erreurs et des instructions SELECT DISTINCT champs à copier-coller dans phpMyAdmin pour vérifier que les données de ces champs en erreur n’ont pas subi de dommages.
    Il peut être téléchargé à cette adresse (site du Kit labos CNRS) : http://www.harmoweb.cnrs.fr/IMG/zip/convert_sql_utf8-2.zip

    Pour info, aucun de ces champs récalcitrants à la conversion en BLOB n’ont finalement posé de problème de conversion.

    • pverrier

      Une autre remarque : j’ai constaté que les champs <span class="base64" title="PGNvZGUgY2xhc3M9InNwaXBfY29kZSBzcGlwX2NvZGVfaW5saW5lIiBkaXI9Imx0ciI+c3RhdHV0PC9jb2RlPg=="></span> varchar(10) NOT NULL DEFAULT '0', (présents dans de nombreuses tables) perdent leur valeur par défaut '0' après conversion des structures.

      Géré en ajoutant L105 :
      $default = $row2['Default'] || $row2[’Default’]===’0’ ?(" DEFAULT ".sql_quote($row2['Default'])):"";

    Répondre à ce message

  • Nadir

    Super boulot, cela m’a pris à peine 30s. Bravo !!!

    Répondre à ce message

  • pverrier

    Bonjour et merci pour ce plugin qui m’a permis de convertir un site iso-8859-1 en utf-8 ; une remarque cependant, ce site utilisait le plugin Agenda et les événements n’étaient pas convertis (table spip_evenements) ; à cette fin j’ai ajouté dans grenier/base/convert_utf8.php la ligne
    ’spip_evenements’ => ’titre’,
    (après ’spip_articles’), cela a fonctionné.

    Répondre à ce message

  • 1
    peter bang

    Voici un cas de figure qui se présente à moi : j’ai des tables en utf8 et d’autres en iso 8859. Faut-il procéder avec Grenier ?

    • Loiseau2nuit

      Ce pourrait être un retour d’expérience assez intéressant à priori. Tu peux nous tenir au courant de tes tests ?

      MErci d’avance ;)

    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