Je suis extrêmement nouveau sur MySQL et je l'exécute sur Windows. J'essaie de restaurer une base de données à partir d'un fichier de vidage dans MySQL, mais j'obtiens l'erreur suivante:

$ >mysql -u root -p -h localhost -D database -o < dump.sql
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'SQLite format 3'.

J'ai essayé $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlmais cela m'a donné ce qui suit. ERROR at line 1: Unknown command '\☻'. Il s'agit d'un fichier de vidage de 500 Mo, et lorsque je regarde son contenu à l'aide de gVIM, tout ce que je peux voir, ce sont des expressions et des données qui ne sont pas compréhensibles. De plus, lorsque j'essaie de copier le contenu du fichier pour le publier ici, tout ce que je peux copier est: SQLite format 3Ce genre de chose semble étrange.

La référence à --binary-mode(introduite dans MySQL 5.6.3) est probablement une distraction.

Il ne semble pas que vous ayez affaire à un fichier de sortie mysqldump, là. Essayez l' fileutilitaire.

shell> file dumpfile.sql
dumpfile.sql: ASCII text

Si vous n'obtenez pas la ASCII textréponse, vous avez affaire à quelque chose qui n'est pas du tout un fichier de vidage mysqldump, ou vous avez affaire à quelque chose qui a été compressé (avec gzip ou bzip2, par exemple), que vous ' d besoin de décompresser avant de le canaliser mysql.

Si vous voyez, SQLite 3.x databasevous avez certainement votre réponse ... c'est une base de données SQLite brute, pas un fichier de vidage MySQL.

En effet, les premiers octets d'une base de données SQLite sont les suivants:

53 51 4C 69 74 65 20 66  SQLite f
6F 72 6D 61 74 20 33 00  ormat 3^@

Notez que le 16e octet est ici 0x00, expliquant le ERROR: ASCII '\0' appeared in the statement...message dans ce cas. La suggestion --binary-modeappropriée est une fausse alarme.

Utilisateurs Windows: l'utilitaire 'file' est un outil d'Unix, mais la version Windows peut être trouvée ici .

les fenêtres

Créez vos fichiers de vidage avec cette commande

.\mysqldump [dbname] -r [filename.sql]

En utilisant:

.\mysqldumb --help

-r, --result-file = nom

                 Direct output to a given file. This option should be used
                 in systems (e.g., DOS, Windows) that use carriage-return
                 linefeed pairs (\r\n) to separate text lines. This option
                 ensures that only a single newline is used.

J'ai eu cette erreur une fois, après avoir exécuté mysqldumpsur Windows PowerShell comme ceci:

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF > db_objects.sql

Ce que j'ai fait était de le changer en ceci (à la place de Set-Content):

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF | Set-Content db_objects.sql

Et le problème a disparu!

Moi aussi dans PowerShell

J'ai rencontré ce problème lorsque j'utilisais PowerShell pour appeler mysqldump et > pour diriger la sortie vers un fichier. PowerShell utilisait un encodage incorrect lors de la création du fichier et j'ai été confronté à la même erreur lorsque j'ai essayé d'importer le fichier en utilisant mysql .. <exports-file.sql

J'ai constaté que la définition du codage par défaut sur UTF8 dans la session PowerShell a résolu ce problème.

Ma résolution - Tested PowerShell 5.1:

$PSDefaultParameterValues["Out-File:Encoding"] = "utf8";

Exemple: Comment je produisais l'exportation (simplifiée) :

$cmdExportDB = "mysqldump --host $Host --databases $DbName -u $UID =p$PWD > $fileName";
Invoke-Expression "& $cmdExportDB";

Remarque: découvert que cela ne fonctionne pas sur PowerShell 4.0

Mon environnement de développement fonctionnait sous 5.1, mais prod est à 4.0 et mon correctif initial ne fonctionne pas dans les anciennes versions de PowerShell.

Besoin d'utiliser | Set-Content -Encoding UTF8 $fileName

Cela a déjà été suggéré par Ifedi

Avez-vous essayé d'ouvrir dans notepad ++ (ou un autre éditeur) et de nous convertir / enregistrer en UTF-8?

Voir: /programming/7256049/notepad-converting-ansi-encoded-file-to-utf-8

Une autre option peut être d'utiliser textwrangle pour ouvrir et enregistrer le fichier au format UTF-8: http://www.barebones.com/products/textwrangler/

Quelqu'un m'a envoyé un gtar compressé. Je ne connaissais même pas trop gtar, mais c'est un autre format de compression.

$ file core_production-1432173533.sql.gtar
core_production-1432173533.sql.gtar: gzip compressed data, from Unix, last modified: Wed May 20 21:59:31 2015

Cependant, j'ai pu le décompresser comme d'habitude:

tar -zxvf core_production-1432173533.sql.gtar
$ file core_production-1432173533.sql
core_production-1432173533.sql: ASCII text, with very long lines

Et puis je pourrais faire l'importation:

mysql -u root -p -h localhost core_production < core_production-1432173533.sql

Solution: extrayez le fichier de sauvegarde, puis restaurez ce vidage sql extrait.

Exemple :

La sauvegarde a été prise en tant que fichier dump.sql.gz et extrayez-la à l'aide de gunzip cmd comme suit,

shell>  gunzip dump.sql.gz

Et RESTORE a extrait le fichier dump.sql.

Réf: À propos du mode binaire et interactif MySQL.

http://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html#option_mysql_binary-mode

Cela fonctionne pour moi et tout ensemble !!

Dans mon cas, le fichier était corrompu. La base de données a été compressée avec extension .bz2mais c'était en fait un fichier .tar.bz2.

La décomposition en utilisant bzip2 -dkne génère aucune erreur et génère le fichier. En utilisant la commande filesur les sorties de fichiers bzip2 compressed data, block size = 900k, il ne semble même pas mauvais de l'utiliser.

Je devais utiliser tar -xf myfile.bz2