Discussion :

[The Wretched]

Bonjour,

J'ai une base "ma_base" sous mysql 3.23, avec un jeu de caractère en latin1.
La base contient une seule table :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
table1
IDtable1  	        mediumint(9)
Quantité  	        mediumint(9)  	
Unité  	        char(10)

Je veux transférer cette base vers un autre serveur sous mysql 5.5.
Je tiens à conserver le même jeu de caractère (latin1), et le nouveau mysql a été configuré pour ça.

J'ai recréé ma base sur le nouveau mysql :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CREATE DATABASE ma_base DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

(je vous passe l'attribution des droits sur cette base)

J'ai fait un dump de l'ancienne base depuis le nouveau mysql avec la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump.exe -h [IP_serveur_ancienne_base] -u[login] -p[mot_passe] --allow-keywords --default-character-set=latin1 -f --no-tablespaces ma_base > C:\dump_mabase.sql

Quand j'essaye de réintégrer ce dump dans mysql5, ça m'affiche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ERROR 1300 (HY000): Invalid utf8 character string: 'Quantit\x82'

Apparemment le problème vient des noms des colonnes qui sont accentués.

En ouvrant le dump créé, j'ai remarqué que mysql rajoute des instructions conditionnelles qui ont l'air de forcer le character_set à UTF8, alors que je le veux en latin1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
DROP TABLE IF EXISTS `table1`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `table1` (
  `IDtable1` mediumint(9) NOT NULL auto_increment,
  `Quantité` mediumint(9) default NULL,
   `Unité` char(10) default NULL, 
  PRIMARY KEY  (`IDtable1`),
  UNIQUE KEY `Table1_IDtable1_NDX` (`IDtable1`)
) ENGINE=MyISAM;
/*!40101 SET character_set_client = @saved_cs_client */;

Si je supprime ces instructions du dump, l'importation dans la nouvelle base se déroule sans problème.

1è question : est-ce que vous savez si on peut faire quelque chose pour empêcher mysql de rajouter ces instructions sur les character-set dans les dump ?


Ensuite, si je modifie le dump en supprimant les "SET character_set_client = utf8" et que je l'importe dans la nouvelle base, puis que j'essaye de recréer un fichier dump depuis cette base, le fichier dump créé pose problème sur les noms des colonnes accentués :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
DROP TABLE IF EXISTS `table1`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `table1` (
  `IDtable1` mediumint(9) NOT NULL AUTO_INCREMENT,
  `QuantitÔÇÜ` mediumint(9) DEFAULT NULL,
   `UnitÔÇÜ` char(10) DEFAULT NULL,
  PRIMARY KEY (`IDtable1`),
  UNIQUE KEY `Table1_IDtable1_NDX` (`IDtable1`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = @saved_cs_client */;

Question2 : j'ai l'impression d'avoir un sacré problème au niveau des jeux de caractères, et je me demande si j'ai configuré mysql correctement pour avoir ma base en latin1... Est-ce que vous savez ce qui pourrait clocher ?

La seule chose que je ne pourrai pas faire c'est changer le nom de mes colonnes accentuées.

Désolé pour le pavé et merci d'avance de votre aide

[Artemus24]

Salut The Wretched.

1) Quand tu vas créer une table ou quoi que ce soit d'autre, elle va automatiquement se charger dans la base de données 'mysql'.
Or par défaut, le jeu de caractères utilisé est le 'UTF8'. Voici une visualisation des jeux de caractères chez moi.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
--------------
SHOW global  Variables where Variable_name LIKE 'character\_set\_%'
--------------
 
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | latin1 |
| character_set_connection | latin1 |
| character_set_database   | latin1 |
| character_set_filesystem | latin1 |
| character_set_results    | latin1 |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+

La partie 'système' correspond bien à la base de données 'mysql' qui est le cœur de ton SGBDR. Donc tu ne peux pas changer ce jeu de caractères.

2) il est de coutume, pour les noms de colonnes et autres, d'utiliser le jeu de caractères ASCII, dans sa partie allant de 0x20 à 0x7F.
Et plus précisément, l'alphanumérique en minuscule, sans accents. Si tu veux séparer un nom composé, tu peux mettre le souligné.

1è question : est-ce que vous savez si on peut faire quelque chose pour empêcher mysql de rajouter ces instructions sur les character-set dans les dump ?

3) je n'ai pas trouvé dans mysql, comment supprimer tout ce qu'il rajoute lors d'un export sous phpmyadmin ou en utilisant l'utilitaire 'mysqldump'.
Cette question m'intéresse aussi !

Question2 : j'ai l'impression d'avoir un sacré problème au niveau des jeux de caractères, et je me demande si j'ai configuré mysql correctement pour avoir ma base en latin1... Est-ce que vous savez ce qui pourrait clocher ?

4) Le jeu de caractères, ce n'est pas uniquement dans les bases de données ou dans les tables de mysql.
Il y a toute une chaîne allant de MySql en passant aussi par Apache, par Php, dans le source, à l'affichage ...
Il est vrai que ce problème est un peu complexe dans une application et selon les outils que l'on utilise.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE DATABASE `base` DEFAULT CHARACTER SET `latin1` DEFAULT COLLATE `latin1_general_ci`;
 
CREATE TABLE `test` (...) ENGINE=InnoDB DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci` ROW_FORMAT=COMPRESSED;

La seule chose que je ne pourrai pas faire c'est changer le nom de mes colonnes accentuées.

5) Aïe ! Justement, tu as fait le mauvais choix.
J'ai quant même fait le test de création d'une base de données et de table avec des accents dans les noms, histoire de voir s'il y a un blocage quelque part. Voici mon exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
DROP DATABASE IF EXISTS `été`
--------------
 
--------------
CREATE DATABASE `été`
        DEFAULT CHARACTER SET `latin1`
        DEFAULT COLLATE       `latin1_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `forêt`
--------------
 
--------------
CREATE TABLE `forêt`
(
  `clé`      int      NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `quantité` char(20) NOT NULL COLLATE `latin1_bin`
) ENGINE=InnoDB
  DEFAULT CHARSET=`latin1` COLLATE=`latin1_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
INSERT INTO `forêt` (`clé`,`quantité`) VALUES
(1, 'vingt-cinq')
--------------
 
--------------
select * from forêt
--------------
 
+-----+------------+
| clé | quantité   |
+-----+------------+
|   1 | vingt-cinq |
+-----+------------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

Donc cela ne pose aucun problème. Je tiens à préciser que je suis comme toi en 'latin1'.
Et je précise que la base 'mysql', le coeur de mon SGBDR est bien en 'UTF8'.

Oui, mais quand est-il avec 'mysqldump' ?
Voici ce que j'obtiens par un export sous 'phpmyadmin' :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
-- phpMyAdmin SQL Dump
-- version 4.5.1
-- http://www.phpmyadmin.net
--
-- Client :  127.0.0.1
-- Généré le :  Jeu 19 Novembre 2015 à 12:30
-- Version du serveur :  5.7.9-log
-- Version de PHP :  7.0.0RC7
 
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";
 
 
/*!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 utf8mb4 */;
 
--
-- Base de données :  `été`
--
 
-- --------------------------------------------------------
 
--
-- Structure de la table `forêt`
--
 
CREATE TABLE `forêt` (
  `clé` int(11) NOT NULL,
  `quantité` char(20) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci ROW_FORMAT=COMPRESSED;
 
--
-- Contenu de la table `forêt`
--
 
INSERT INTO `forêt` (`clé`, `quantité`) VALUES
(1, 'vingt-cinq');
 
--
-- Index pour les tables exportées
--
 
--
-- Index pour la table `forêt`
--
ALTER TABLE `forêt`
  ADD PRIMARY KEY (`clé`);
 
--
-- AUTO_INCREMENT pour les tables exportées
--
 
--
-- AUTO_INCREMENT pour la table `forêt`
--
ALTER TABLE `forêt`
  MODIFY `clé` int(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Dans cet exemple, on voit que l'export a forcé à 'utf8mb4' et non à 'utf8' comme dans la base 'mysql'.

Alors comment procéder ?
a) vérifier que votre fichier contenant l'extraction de votre base de données soit 'encoder en utf-8 (sans bom)'. Oui, j'utilise notepad++.
b) remplacer le 'utf8mb4' si c'est le cas chez vous par un 'utf8', mais ne supprimez pas les lignes ajoutés par l'export, comme dans mon exemple.
c) si les accents ne passent pas, c'est que vous n'êtes pas dans le bon jeu de caractères. Il faudra forcer les accents dans le bon jeu de caractères.
Comment faire ? Dans le fichier, j'ai forcer l'encodage en 'ANSI'. Normalement, c'est l'équivalent du 'Windows-1252'.
d) dans l'import, sous phpmyadmin, j'ai juste indiqué que mon nouveau jeu de caractères est 'windows-1252'.
J'ai fait l'import et tout c'est bien passé !

@+

[The Wretched]

Merci d'avoir pris le temps de me répondre

4) Le jeu de caractères, ce n'est pas uniquement dans les bases de données ou dans les tables de mysql.
Il y a toute une chaîne allant de MySql en passant aussi par Apache, par Php, dans le source, à l'affichage ...
Il est vrai que ce problème est un peu complexe dans une application et selon les outils que l'on utilise.

Pour préciser un peu mon contexte, ma base est utilisée par un logiciel, pas par un site, donc normalement je n'aurai pas de problème avec apache ni php.

5) Aïe ! Justement, tu as fait le mauvais choix.

Ce n'est pas un choix de ma part, la base existe depuis longtemps et ce n'est pas moi qui ai créé ces noms de champs non conventionnels.
Je ne peux pas les changer parce que ça impliquerait de modifier également le logiciel qui fonctionne sur cette base.

Oui, mais quand est-il avec 'mysqldump' ?
Voici ce que j'obtiens par un export sous 'phpmyadmin' :
[...]
Dans cet exemple, on voit que l'export a forcé à 'utf8mb4' et non à 'utf8' comme dans la base 'mysql'.

Je pense que la commande mysqldump et l'export avec phpmyadmin ne renvoient pas la même chose ; notamment tu as dans ton fichier de sortie "SET NAMES utf8mb4" alors que j'ai "SET character_set_client = utf8", outre la différence de jeu de caractère ça ne modifie pas le même paramètre.

Le problème avec phpmyadmin c'est que (corrigez-moi si je me trompe) on ne peut pas automatiser l'exportation (quotidiennement par exemple).


Je pense que tu tiens quelque chose quand tu parles de l'encodage du fichier de sortie, par contre.

a) vérifier que votre fichier contenant l'extraction de votre base de données soit 'encoder en utf-8 (sans bom)'. Oui, j'utilise notepad++.

J'ai l'impression que mon fichier contenant l'extraction de ma vieille base est en ANSI (quand je vais dans "encodage" sur notepad++ ça m'affiche "ansi").

J'ai lu ça sur un autre site, je vais essayer voir ce que ça donne :

According to this forum thread, the culprit is the > filename redirection on Windows, which seems to have trouble with UTF-8 characters.

Try using the --result-file parameter instead.

Je suis aussi en train de regarder les outils mysql pour la migration de base et le passage de latin1 en UTF8 (plutôt que de faire ça "à la main").

Merci encore de votre aide, je vous tiens au courant !

[Artemus24]

Salut The Wretched.

Je pense que la commande mysqldump et l'export avec phpmyadmin ne renvoient pas la même chose;

Je peux me tromper, mais je pense que c'est le même outil, à savoir mysqldump, mais avec un paramétrage différent.
Et puis, je ne suis pas dans la même version mysql 5.7.9, que vous.

J'ai l'impression que mon fichier contenant l'extraction de ma vieille base est en ANSI (quand je vais dans "encodage" sur notepad++ ça m'affiche "ansi").

Qu'est-ce que vous avez mis comme jeu de caractères lors de l'export de votre base de données ?

Il ne faut pas aussi oublier de paramétrer votre SGBDR pour avoir le bon jeu de caractères. A mettre dans le fichier my.ini :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
[wampmysqld]
port   = 3306
socket = mysql
 
# --------------- #
#     Charset     #
# --------------- #
 
character-set-server     = latin1
collation-server         = latin1_general_ci
character-set-filesystem = latin1
 
init-connect             = 'SET NAMES latin1 COLLATE latin1_general_ci'

Voici un lien pouvant vous aider sur le paramétrage de mysqldump : https://dev.mysql.com/doc/refman/5.7...sqldump-syntax

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump  --databases base --tables test  --where="id < 10" --result-file=test.sql  --default-character-set=latin1  --set-charset

Il est inutile pour vos tests de charger une grosse table.
La clause where permet ici de prendre que dix lignes.
J'ai précisé le 'latin1' et ainsi que le 'set names' dans la commande 'mysqldump'.

Avez-vous réussi à importer votre base de données ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ERROR 1300 (HY000): Invalid utf8 character string: 'Quantit\x82'

La solution la plus simple est de convertir votre fichier 'export.sql' à l'aide de notepad++ en 'utf-8 (sans bom)'.

@+

[The Wretched]

Désolé du délai de réponse, weekend toussa toussa...

Qu'est-ce que vous avez mis comme jeu de caractères lors de l'export de votre base de données ?

J'avais fait mon exportation (depuis la vieille base) avec la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump.exe -h [IP_serveur_ancienne_base] -u[login] -p[mot_passe] --allow-keywords --default-character-set=latin1 -f --no-tablespaces ma_base > C:\dump_mabase.sql

Voici un lien pouvant vous aider sur le paramétrage de mysqldump : https://dev.mysql.com/doc/refman/5.7...sqldump-syntax

J'avais déjà regardé un peu, mais ça n'a pas l'air de coller avec le comportement de mes commandes. Par exemple un mysqldump avec l'option "--skip-quote-names" me sort quand même un fichier avec les noms entre quotes.

A mettre dans le fichier my.ini [...]

Je vais essayer ça pour avoir des fichiers plus propres.

Cela dit, je remarque que (une fois ma nouvelle base en place) si je fais l'exportation vers un fichier dump, le fichier contient des caractères bizarres pour les noms de colonnes accentués, mais quand je réimporte ce fichier dans la base, les noms des colonnes dans la base importée sont corrects.
En bref si je ne me préoccupe pas du contenu du fichier dump, tout fonctionne normalement (même sans forcer le default-character-set dans les commandes dump et de réimportation).

A demain pour de nouvelles aventures !

[Artemus24]

Salut The Wretched.

Inutile de vous excuser, il n'y a aucune urgence.

A mettre dans le fichier my.ini [...]

Je vais essayer ça pour avoir des fichiers plus propres.

Les problèmes de jeu de caractères proviennt fréquemment d'un mauvais paramétrage du fichier my.ini.

Cela dit, je remarque que (une fois ma nouvelle base en place) si je fais l'exportation vers un fichier dump, le fichier contient des caractères bizarres pour les noms de colonnes accentués, mais quand je réimporte ce fichier dans la base, les noms des colonnes dans la base importée sont corrects.

C'est tout à fait normal. Voici un exemple de l'affichage en ligne de commande.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
--------------
SET AUTOCOMMIT = 0
--------------
 
--------------
START TRANSACTION
--------------
 
--------------
SET NAMES utf8 COLLATE utf8_general_ci
--------------
 
--------------
SET character_set_results=latin1
--------------
 
--------------
DROP DATABASE IF EXISTS `base`
--------------
 
--------------
CREATE DATABASE `base`
        DEFAULT CHARACTER SET `utf8`
        DEFAULT COLLATE       `utf8_general_ci`
--------------
 
--------------
DROP TABLE IF EXISTS `test`
--------------
 
--------------
CREATE TABLE `test`
(
  `id`     int          NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `chaine` varchar(255) NOT NULL
) ENGINE=InnoDB
  DEFAULT CHARSET=`utf8` COLLATE=`utf8_general_ci`
  ROW_FORMAT=COMPRESSED
--------------
 
--------------
INSERT INTO `test` (`chaine`) VALUES
('chaîne'),('après'),('forêt'),('noël'),('été'),('©¶×÷þ')
--------------
 
--------------
select *
from test
--------------
 
+----+--------+
| id | chaine |
+----+--------+
|  1 | chaîne |
|  2 | après  |
|  3 | forêt  |
|  4 | noël   |
|  5 | été    |
|  6 | ©¶×÷þ  |
+----+--------+
--------------
COMMIT
--------------
 
--------------
SET AUTOCOMMIT = 1
--------------
 
 
Appuyez sur une touche pour continuer...

J'exécute ce script sql en ligne de commande, où le jeu de caractères est 'latin1'.
C'est "SET character_set_results=latin1" qui va régir le jeu de caractères à l'affichage.
Autrement dit, quand je fais un select, le résultat (le tableau) est dans ce jeu de caractères.

Or vous voyez que ma base est en utf8. Le script est aussi en "utf-8 (sans bom)" avec l'éditeur notepad++.
Et j'ai bien de drôle de caractères dans la partie 'values' de l'insert.
Et quand je vais sous phpmyadmin pour consulter le contenu de ma table, les caractères sont lisibles.

Donc vous devez vous assurez :
1) que la base et les tables sont bien dans le jeu de caractères que vous avez sélectionnez !

2) que le fichier contenant les données (le script mysqldump) est bien encodé dans le bon jeu de caractères.

3) que le fichier 'my.ini' contient les bonnes déclarations. Surtout, ne pas oublier de déclarer 'set names ...'.
C'est ce que va régir les transferts des données entre votre script et le SGBDR.

4) s'assurer que le jeu de caractères dans le script mysqldump est bien celui que vous attendez.
Je vous rappelle qu'il fait faire la distinction entre la base de données MySql qui est obligatoirment en utf8 et votre base de données qui est en latin1.
Quand vous mettez des accents à vos noms de colonnes, c'est bien en utf8 que vous devez travailler.

5) vérifiez que votre paramétrage est correcte :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
--------------
SHOW global  Variables where Variable_name LIKE 'character\_set\_%'
--------------
 
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | latin1 |
| character_set_connection | latin1 |
| character_set_database   | latin1 |
| character_set_filesystem | latin1 |
| character_set_results    | latin1 |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+
--------------
SHOW session Variables where Variable_name LIKE 'character\_set\_%'
--------------
 
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | latin1 |
| character_set_connection | latin1 |
| character_set_database   | latin1 |
| character_set_filesystem | latin1 |
| character_set_results    | latin1 |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+

--> character_set_system : c'est pour la base de données MySql, c'zst-à-dire, là où on stocke le descriptif des bases et des tables.
--> character_set_results : c'est l'affichage.
--> character_set_database : valeur par défaut de vos bases de données.
--> character_set_connection : je crois que c'est ceci : "init-connect = 'SET NAMES latin1 COLLATE latin1_general_ci'".

@+

[The Wretched]

J'ai pas trop envie de me prendre la tête plus longtemps sur ce problème.

Pour résumer :
- S3 est mon serveur actuel sur mysql3.3
- S5 est le serveur sur lequel je veux migrer sous mysql5.5
- B3 est ma base actuelle sur S3
- F3 est mon fichier dump créé avec la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump.exe -h S3 -ulogin -pmotpasse --databases B3 --allow-keywords  --default-character-set=latin1 -f --no-tablespaces --result-file="C:\migration\dump_SQL.sql"

(Cette commande est lancée depuis S5)
- B5 est la base sur S5
- F5 est le fichier dump créé avec la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

mysqldump.exe -ulogin -pmotpasse --databases B5 --allow-keywords  --default-character-set=latin1 -f --no-tablespaces --result-file="C:\migration\dump_SQL5.sql"

(Cette commande est lancée depuis S5)


Quand j'essaye d'importer B3 sur S5, il me met "Invalid utf8 character".
Si j'enlève les lignes "/*!40101 SET character_set_client = utf8 */;", l'importation se passe correctement et j'obtiens la base B5.

Je peux créer F5 sans problème et quand je le réimporte dans S5, tout fonctionne.

Il y a des différences entre les fichiers F3 et F5, notamment "SET NAMES latin1" dans F5 et pas dans F3, et "DEFAULT CHARSET=latin1" à la fin de la déclaration de chaque table dans F5 et pas dans F3.



Comme je ne peux pas toucher aux jeux de caractères sur S3 ni B3 (c'est le serveur et la base de prod), je vais être obligé de modifier F3, soit pour rajouter "set names latin1" et "default charset=latin1", soit pour enlever "SET character_set_client = utf8".

Avec cette deuxième option j'ai fait des tests et je sais que ça fonctionne, donc je vais m'en tenir à ça.

Normalement je n'aurai cette modification de dump F3 à faire qu'une seule fois pendant la migration, mon dump quotidien F5 pouvant être remonté sans modification.


Merci encore pour ton aide !