[Résolu] Problème d'importation de base MySQL en UTF8 chez 1&1

[Marie-Aude]

Bonsoir,

C'est à devenir dingue, si le pire du pire existe en matière de serveur MySQL, vous le trouverez chez 1&1. C’est du délire complet. Ça fait deux jours que j’essaie d’importer une base que j’ai vérifié X fois (reçue de quelqu’un), que j’ai importé X fois en local (pour vérifier) sans aucun problème, que j’ai re-exporté X fois avec toutes les combinaisons d’options imaginable depuis cette même base locale.

Quand je l’importe chez 1&1, c’est à devenir dingue ou à se tordre de rire, au choix : certaines entrées des tables sont importés normalement, et certaines sont importées comme si elle étaient reçue en ISO 8859-1 puis ré-encodées en UTF-8. Et cela, au sain d’une même table ! Dans une même table (c’est un forum), certaines entrée encodent les caractère accentué normalement, et d’autres non, et les enregistre comme si l'UTF-8 dans lequel est encodé le fichier SQL avait été interprété comme de l’ISO pour être ensuite ré-encodé en UTF-8, c’est à dire que je me retrouve avec des ’ ou é, mais en UTF-8!

J’ai vérifié évidemment X fois que tous est en UTF-8 pour dans les tables, j'ai vérifier que le fichier SQL indique bien d’utiliser UTF-8, etc, tout est là pourtant.

Deux jours, et pas moyen de faire comprendre à 1&1 ce que c’est que de l’UTF-8, alors que ça marche sur deux autres bases MySQL.

Je sais pas si leur serveur tourne au pinard ou au cannabis, mais pour interpréter, depuis un fichier encodé en UTF-8, certaines entrée comme si elles étaient en UTF-8 et d’autres comme si elles étaient en ISO 8859, il faut quand-même en tenir un bonne couche de plusieurs kilomètres.

Vous avez déjà vu une idiotie pareille ? Moi jamais, et il n’y a qu’avec cette base 1&1 que je n’ai jamais vu ça.

Si quelqu’un sait quels champignons ils font manger à leurs serveur MySQL, ça pourrait m’aider, au moins ça me donnerait peut-être un idée de l’antidote à lui injecter.

N’importe quoi… interpréter un fichier UTF-8 tantôt comme de l’UTF-8, tantôt comme de l’ISO, au gré des lignes, jamais vu un truc pareil… et surtout aussi pénible.

Un truc qui aurait dut être fait en 1h maximum avec un serveur MySQL décent, n’a pas même pas put être fait en deux jours + une nuit (entre les deux) sur un serveur MySQL de chez 1&1.

[hibou57]

Aawaaaah, ça marche! Va pouvoir faire dodo

Il y a deux choses, une qui venait de ma manière de procéder et une qui vient de 1&1, qui me semble toujours aussi bizarre : si vous envoyez des fichiers SQL avec une compression GZip, le serveur MySQL de 1&1 cafouille et fait n’importe quoi avec l’encodage. C’est fou, parce que l’encodage ne peut évidemment pas s’appliquer à un fichier gzip, sinon il serait altéré et deviendrait illisible, alors je ne sais pas pourquoi il supporte mal l’UTF-8 quand on lui envoi un fichier gzippé, et semble mieux le supporter quand on lui envoie un fichier tel-quel.

La deuxième chose, ben sorry, je la garde secrète, ça fait partie d’une manière de découper les trop gros fichiers SQL pour les envoyer par une interface PHPMyAdmin quand ils sont trop gros pour passer tel-quel. J'ai l'idée de peut-être mettre ce programme en téléchargement contre micro-paiement de 1€ (raison pour laquelle je ne donne pas cette partie de la solution ici).

Bon, en tous cas, les gens qui sont chez 1&1, notez que au delà d’une certaine taille, n’envoyez pas de fichier SQL gzippé, sinon vous allez déguster une soupe d’encodage indigeste.

Yellah, je marque « Résolu » now.

-- EDIT -- Ah bah non, je suis bête, c’est vrai qu’on ne peut pas éditer les topics pour marquer résolu ici.

[DadouDuck]

En fait, c'est PHPmyadmin qui a du mal avec l'UTF-8 et pas MySQL, depuis que j'utilise MySQL workbench, je n'ai plus les problèmes d'encodage que j'ai pus avoir avec PHPmyadmin, le seul défaut de ce type d'outil, c'est qu'il faut que le port 3306 accepte les connexion distantes.

[Marie-Aude]

Sinon pour les "trop" gros fichiers, il y a bigdump qui fonctionne bien et qui est totalement gratuit...

[UsagiYojimbo]

Ou le passage pare des outils comme HeidiSQL, qui permettent l'import SQL de gros fichiers.

[hibou57]

Dernière édition par Marie-Aude le Lun Juil 04, 2011 1:10, édité 1 fois.
Raison: En plus du "résolu", je me suis permis de mettre un titre un peu plus factuel

C’était bien vu


Je recommande aussi de limiter la taille des fichiers SQL à 3M avec l’interface PHPMyAdmin de 1&1, car sinon au delà, et j’ignore pourquoi, s’il existe une erreur dans le texte SQL (ça peut arriver, ben oui), il ne donne aucune information au sujet de l’erreur, et on se retrouve avec un simple message du style « la connexion n’a pas put être établi » de la part du navigateur, qui ne reçoit aucune réponse à la demande de rafraichissement de la page.

Il faut vraiment fractionner petit… (parce qu’en effet, fractionner par part de 3M, ça fait pas beaucoup), mais au moins ça permet de suivre ce qu’il se passe plus finement.

Dommage qu’il ne soit pas possible d’utiliser la commande mysql en Telnet (j’ai essayé, ça me renvoie un message d’erreur à propos d’une connexion impossible).

Bon, bilan : limiter la taille des SQL à 20M environ si on veut que ça passe et qu’on est sûr(e) à 100% qu’il n’est pas possible qu’ils contiennent une erreur; et limiter la taille à 3M si on veut en plus être informé d’éventuels erreurs présentes.