Bien, nous voilà revenu au point de départ…
Les bases ont été restaurées et réimportées.
Je remercie tous ceux qui ont bien voulu me faire des suggestions aussi heureuses que diverses, et en particulier de Guillaumin, qui m’a proposé une solution aussi élégante qu’efficace.
En clair, ce que doctclear avait fait, dotclear pouvait le défaire.
On se rappelle que j’avais malencontreusement — ou du fait de l’installation de dotclear 1.28 — converti mes bases en UTF-8. Il s’agissait donc de les reconvertir en ISO-8859-1.
Mais la reconversion via un utilitaire dédié modifiait les requêtes dans les fichiers de sauvegarde de la base de donnée. Autrement dit, je tombait sur un os en forme de doubles apostrophes importunes. D’où l’idée de travailler directement à partir de dotclear.
Bien sûr, il valait mieux prendre quelques précautions…
J’ai donc travaillé en local[1], puis effectué les modifications sur un site distant, avant de revenir à la maison.
Voici les différentes phases, pour ceux qui seraient intéressés.
1. Installation d’un serveur local Apache + phpMyadmin tournant sous une mandriva. Il faut également ajouter les utilitaires xml. Donc, urpmi[2] tout cela ; puis configuration et installation de ce joli petit monde et sécurisation du tout, histoire qu’on ne puisse y accéder qu’en local (sinon, c’est la porte ouverte à toutes les fenêtres).
2. Installation de dotclear 1.28 en local.
3. Exportation des bases dotclear de http://dinersroom.free.fr en procédant table par table (histoire de se faciliter l’exportation distante future).
4. Suppression des tables dotclear en local et importation des bases corrompues.
5. Et c’est là que Guillaumin intervient : modification de la fonction latin1utf8 dans /inc/libs/lib.util.php.
Il peut être bon de sauvegarder /inc/libs/lib.util.php pour ceux qui ne savent pas décommenter. Car il faudra modifier la fonction à nouveau.
En fait, cette nouvelle fonction ne convertit pas d’ISO et UTF-8 (comme la fonction par défaut), mais d’UTF-8 en ISO. C’est la finesse.
function latin1utf8($str) {
/*$conv = array(
chr(194).chr(128) => chr(226).chr(130).chr(172),
chr(194).chr(130) => chr(226).chr(128).chr(154),
chr(194).chr(131) => chr(198).chr(146),
chr(194).chr(132) => chr(226).chr(128).chr(158),
chr(194).chr(133) => chr(226).chr(128).chr(166),
chr(194).chr(134) => chr(226).chr(128).chr(160),
chr(194).chr(135) => chr(226).chr(128).chr(161),
chr(194).chr(136) => chr(203).chr(134),
chr(194).chr(137) => chr(226).chr(128).chr(176),
chr(194).chr(138) => chr(197).chr(160),
chr(194).chr(139) => chr(226).chr(128).chr(185),
chr(194).chr(140) => chr(197).chr(146),
chr(194).chr(145) => chr(226).chr(128).chr(152),
chr(194).chr(146) => chr(226).chr(128).chr(153),
chr(194).chr(147) => chr(226).chr(128).chr(156),
chr(194).chr(148) => chr(226).chr(128).chr(157),
chr(194).chr(149) => chr(226).chr(128).chr(162),
chr(194).chr(150) => chr(226).chr(128).chr(147),
chr(194).chr(151) => chr(226).chr(128).chr(148),
chr(194).chr(152) => chr(203).chr(156),
chr(194).chr(153) => chr(226).chr(132).chr(162),
chr(194).chr(154) => chr(197).chr(161),
chr(194).chr(155) => chr(226).chr(128).chr(186),
chr(194).chr(156) => chr(197).chr(147),
chr(194).chr(159) => chr(197).chr(184)
);
$str = utf8_encode($str);*/
$conv = array(
chr(226).chr(130).chr(172) => chr(194).chr(128) ,
chr(226).chr(128).chr(154) => chr(194).chr(130) ,
chr(198).chr(146) => chr(194).chr(131) ,
chr(226).chr(128).chr(158) => chr(194).chr(132) ,
chr(226).chr(128).chr(166) => chr(194).chr(133) ,
chr(226).chr(128).chr(160) => chr(194).chr(134) ,
chr(226).chr(128).chr(161) => chr(194).chr(135) ,
chr(203).chr(134) => chr(194).chr(136) ,
chr(226).chr(128).chr(176) => chr(194).chr(137) ,
chr(197).chr(160) => chr(194).chr(138) ,
chr(226).chr(128).chr(185) => chr(194).chr(139) ,
chr(197).chr(146) => chr(194).chr(140) ,
chr(226).chr(128).chr(152) => chr(194).chr(145) ,
chr(226).chr(128).chr(153) => chr(194).chr(146) ,
chr(226).chr(128).chr(156) => chr(194).chr(147) ,
chr(226).chr(128).chr(157) => chr(194).chr(148) ,
chr(226).chr(128).chr(162) => chr(194).chr(149) ,
chr(226).chr(128).chr(147) => chr(194).chr(150) ,
chr(226).chr(128).chr(148) => chr(194).chr(151) ,
chr(203).chr(156) => chr(194).chr(152) ,
chr(226).chr(132).chr(162) => chr(194).chr(153) ,
chr(197).chr(161) => chr(194).chr(154) ,
chr(226).chr(128).chr(186) => chr(194).chr(155) ,
chr(197).chr(147) => chr(194).chr(156) ,
chr(197).chr(184) => chr(194).chr(159)
);
$str = str_replace(array_keys($conv),array_values($conv),$str); $str = utf8_decode($str);
return $str; }
6. Modification dotclear.ini pour lui faire dire que le blog est en ISO-8859-1.
On trompe dotclear en lui faisant croire que le blog est en ISO.
7. Dans les outils, on applique « Conversion en UTF-8« .
Si tout se passe bien, on a récupéré une bonne partie des tables qui sont désormais propres. Je passe les détails de certaines petites difficultés qui ont supposé des variables d’importation modifiées. Mais baste… Mes bases étaient vraiment corrompues.
8. On exporte à nouveau chaque table, désormais propre, dans un dossier Tables dotclear propres » », en n’oubliant pas de les compresser en .zip ou .gz$$J je préfère le .gz qui s’importe plus rapidement.
9. On ferme dinersroom, et on supprime les tables qui posent problème à la main ; on les réimporte à partir des tables locales propres.
10. On fait un billet à la gloire de ses visiteurs attentionnés.
Merci à tous.
Et maintenant, on essaye de passer à wordpress.
MAIS TOUT EN LOCAL, d’abord, petits padawans !!!
Je n’ai rien compris mais je vous prie de recevoir toutes mes félicitations.
Cela fait plaisir de vous retrouver !
Attention commentaire technique.
Les bases de dotclear 1 enregistre toutes les données en ISO-8859-1. La conversion en UTF-8 de dotclear transforme les données en charabia dans la base de données (transformation de é en é).
En même temps la variable dc_encode dans le dotclear.ini est modifiée en UTF-8, ce qui fait que le navigateur qui lit ces données les retraduit dans le sens inverse(cf content= »text/html; charset=UTF-8″ dans le code source des pages php).
Donc si vous avez un problème d’affichage de ce type (les é qui apparaissent comme des é), la première chose a verifier est le charset de vos pages, et donc pour dotclear, la valeur de la variable dc_encode dans le fichier dotclear.ini. S’il est en ISO-8859-1, le changer en UTF-8 devrait régler le problème.
Le problème ici était que les billets du blog ont été convertis deux fois(le é était devenu é). C’est comme si on traduisait du chinois en chinois en pensant qu’il s’agissait de français. Le but a donc été de les reconvertir en UTF-8, en lançant une conversion UTF-8 vers ISO de l’UTF-8 corrompu par la traduction supplémentaire.
(Je réitère mes consignes de prudence : un fonctionnement correct en local ne garantit nullement un fonctionnement « iso » sur free.)
Voilà qui est clair. Si on traduit du chinois en chinois, on n’a aucune chance de parler français. Tandis que si on traduit du français en chinois, puis du chinois en français, ça réconforte le lama tibétain. Encore que s’il s’agit d’un français local voire infra-local comme celui de Sarkozy, la compréhension du mandarin n’est pas assurée.
je comprends rien mais je compatis depuis le début et te souhaite bien du courage pour continuer ta restauration
Ils sont où les nouveaux graphismes ?
Faut-il comprendre que maintenant c’est réglé ?
Merci pour le plantage, Messire Jules-en-sa-salle-à-dîner, et pour la réparation expliquée ; ce qui me permet de commencer à comprendre où je me suis emmêlé les électrons avec DotClear.
Tout ce charabia non sans poésie ésotérique est la raison technique qui a motivé le basculement vers WordPress -sans regret aucun, tant l’ergonomie de l’interface d’administration est réussie et sans cesse mise à jour-. Avec ma gratitude d’apprenti toile-maître, avec une mention particulière pour un certain Guillaumin.