Base de donnée et utf8

bonjour
je suis désolé de venir vous importuner, mes demandes sur les forums joomla et ovh sont restées vaines

j'ai plusieurs sites joomla sur la même base
certaines tables ont été virées et j'ai fait un dump chez ovh (un fichier texte pour remplacer ma base)

or, cette "sauvegarde" si elle m'installe bien tout, le fait pour certaines tables avec des fichiers qui me donnent des signes bizarres à la place des accents.

je vérifie tout, et ma base est en utf8, mes tables aussi , à priori, même le contenu, donc

je ne comprends pas

je cherche donc un moyen (simple) de prendre l'ensemble de mes tables (ou la partie malade) et de lui dire : maintenant tu es en utf8 , convertis toi correctement !!

d'avance , merci

Vérifies l'encodage de ton fichier de dump (Enregistrer-sous).

je veux bien le faire, mais...
il s'agit chez ovh d'un fichier texte qui apparait et que , si j'ai bien compris je dois copier coller dans les requètes sql de ma base
ça a fonctionné , sauf que mes données ne sont pas reconnues comme utf8 par les navigateurs (et surtout par joomla)
alors, je repose la question : existe t il un moyen pour convertir une base entière , ou en partie, en utf8 afin de ne pas avoir à me retaper mes sites à la main ?

essaye avec ça :

ALTER TABLE tbl_name CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ou ça : mysql_convert_table_format (documentation mysql)

Hello,

Est-ce que ta base source et ta base cible sont toutes les deux en UTF8 ? Les champs des tables sont-ils en collation UTF8 aussi ?

Tu peux faire ton export en cochant la case "save as file", ça te permettra de downloader le fichier plutôt que de l'afficher.

mistike a écrit :
Hello,

Est-ce que ta base source et ta base cible sont toutes les deux en UTF8 ? Les champs des tables sont-ils en collation UTF8 aussi ?

Tu peux faire ton export en cochant la case "save as file", ça te permettra de downloader le fichier plutôt que de l'afficher.

le souci chez ovh, c'est que leur sauvegardes sont au format web
quand tu cliques pour avoir la sauvegardes de la veille ou de la semaine précédente cela t'affiches un dump sur une page web
aucune possibilité de faire autrement qu'un copié collé dans un fichier texte

bon,
je m'auto réponds
je crois que je vais être obligé de tout refaire à la main
heureusement le site est neuf

j'explique :
tout est désormais en utf8, ou ai je fait l'erreur ? je ne sais pas
en tout cas, j'ai beau modifier comme indiqué par les copains au dessus... ça ne fonctionne pas , et pour cause. c'est déjà en utf8
dans la table jos_modules un des title est bannières
sauf que là , il apparait comme : Bannières, et quand je le modifie en utf8 (ce qu'il est déjà) il l'interprête comme : ......... Bannières
il m'est donc impossible de revenir en arrière directement sur la base

il me reste à voir ce que je peux faire avec ma sauvegarde, parce que celle ci est forcément dans un codage qu'il me suffirait de retranscrire avant de la remettre en place

comment ?
je m'y replonge... si quelqu'un sait comment faire ou a déjà eu le souci
a+

je m'auto-auto réponds

je viens de tenter de prendre le dump et de l'implanter dans une base en local :
je mets tout en utf8 et malgrè cela j'ai des problèmes d'accents

je mets l'entête du dump :

-- MySQL dump 10.11
--
-- Host: localhost    Database: netlorgde-s
-- ------------------------------------------------------
-- Server version	5.0.88-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES latin1 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Table structure for table `bak_banner`

faut il dé-commenter quelque chose ?

pour mieux expliquer comment j'ai fait : j'ai copié coller mon fichier texte dans mysql et j'ai fait exécuter (importation ne fonctionne pas avec un dump)

merci de m'aider
ce n'est pas très urgent, mais j'aimerai savoir ou j'ai fait une erreur afin de ne pas la refaire

Hello sergeweb54 et bienvenue,

pour y voir plus clair il faudrait commencer par lire : Comment bien déclarer l'encodage des caractères d'une page.

Pour ce qui est de tes données, si certaines sont en utf8 et d'autres en latin1 il faudrait retrouver le bout de code qui pose problème et le corriger en priorité (SET NAMES, balise meta, utf8_encode, etc.). Ensuite il faudra les corriger, par exemple avec une moulinette à base de utf8_decode et de utf8_encode.

Ensuite tu dis que le dump a été fait en utf8 mais je vois SET NAMES latin1. Le plus simple est de paramétrer mysql de la même façon qu'il l'est sur le serveur du site et donc s'il est en iso-8859-1 tu devrais à priori travailler en LATIN1.

Bonjour,

Il me semble que tu n'as pas répondu à ma question. Ta base source est-elle en UTF8 ? A voir ton fichier dump, j'ai un doute...

Si tes données sont encodées en LATIN-1, il ne suffit pas de dire à mySQL que c'est de l'UTF8. Il faut aussi les convertir avant de les importer.

Donc, question : ta base source est en quel character set, et les données qu'elle contient sont en quel character set ?

Bon je m'auto-réponds aussi

J'ai rencontré un problème de ce genre avec OVH.

Contexte : base locale en UTF8, données en UTF8. Ma base locale est full UTF8, y compris le serveur et les connexions client (par défaut dans my.ini).

Quand j'ai voulu l'importer chez OVH, paf, caractères farfelus. En fait il y a plusieurs choses à faire et à vérifier. Au niveau serveur et au niveau client.

En gros il faut que ta base soit en UTF8, mais aussi ta connexion (sinon tu verras des caractères mal encodés alors qu'ils le sont correctement en réalité).

* Premier problème : chez OVH, on mélange latin-1 et UTF8 au niveau serveur et base (je suis en mutualisé, pro) :

SHOW VARIABLES LIKE 'character_set%';

Variable_name 	Value
character_set_client 	utf8
character_set_connection 	utf8
character_set_database 	latin1
character_set_filesystem 	binary
character_set_results 	utf8
character_set_server 	latin1
character_set_system 	utf8
character_sets_dir 	/usr/share/mysql/charsets/

==> Première chose à faire, passer la base en UTF8 (dans phpMyAdmin, onglet "Operations", puis "Collation" "utf8_general_ci" (pourtant ce sont deux choses différentes, mais en l'occurrence ça a marché)

SHOW VARIABLES LIKE 'character_set%';

Variable_name 	Value
character_set_client 	utf8
character_set_connection 	utf8
character_set_database 	utf8
character_set_filesystem 	binary
character_set_results 	utf8
character_set_server 	latin1
character_set_system 	utf8
character_sets_dir 	/usr/share/mysql/charsets/

Ensuite, éditer ton fichier dump. ATTENTION, il faut impérativement le faire avec un éditeur qui te permette de sauvegarder le fichier en UTF8 (sans BOM). Notepad++ est parfait pour ça.


Dans l'entête du fichier, décommenter la ligne :

SET NAMES utf8

Ajouter

SET character_set_client = utf8;

Importer le fichier, s'il est trop gros il faut passer en ligne de commande :

$  mysql -u<user_mysql>  -p<password> -h<serveur_mysql> <nom_de_la_base> <dump.sql

Enfin, côté client, les connexions par défaut chez OVH étant en LATIN-1, si tes données sont correctement encodées en UTF8, tu verras quand même des caractères bizarres sur tes pages web. La raison : la base est en UTF8, tu te connectes en LATIN-1, mySQL t'envoie les données re-converties. Et ton navigateur les affiche en croyant que c'est de l'UTF8, alors qu'en fait non

Donc dans ton script de connexion à la base, il faut mettre ça, après avoir réalisé (et testé ) la connexion au serveur, puis à la base :

mysql_set_charset("utf8");

Bon, maintenant, vu ton fichier dump, j'ai un doute sur le fait que tes données soient réellement encodées en UTF8. Si ce n'est pas le cas, il faut rajouter une ou plusieurs étapes de conversion des données dans le fichier dump.sql avant de l'importer dans ta base cible. Je l'ai fait il y a quelques mois, mais évidemment je ne retrouve plus mes notes !
Modifié par mistike (09 Jan 2010 - 18:49)