私はMySQLが非常に新しく、Windowsで実行しています。MySQLのダンプファイルからデータベースを復元しようとしていますが、次のエラーが表示されます。

$ >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'.

試してみました$ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlが、次のようERROR at line 1: Unknown command '\☻'. になりました。これは500 Mbのダンプファイルです。gVIMを使用してその内容を表示すると、わかりにくい式とデータしか表示されません。また、ファイルから内容をコピーしてここに投稿しようとすると、コピーできるのは次のとおりSQLite format 3です。

--binary-mode（MySQL 5.6.3で導入された）への参照は、おそらく注意散漫です。

そこで、mysqldump出力ファイルを扱っているようには思えません。fileユーティリティを試してください。

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

ASCII text応答が得られない場合は、まったくダンプファイルではないmysqldumpものを扱っているか、圧縮されたもの（たとえば、gzipまたはbzip2で）を扱っています。 dにパイプする前に解凍する必要がありmysqlます。

表示された場合はSQLite 3.x database、間違いなく答えがあります。それは、MySQLダンプファイルではなく、生のSQLiteデータベースです。

実際、SQLiteデータベースの最初の数バイトは次のとおりです。

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

ここでの16番目のオクテットは0x00であり、ERROR: ASCII '\0' appeared in the statement...この場合のメッセージを説明していることに注意してください。--binary-mode適切な提案は、誤報です。

Windowsユーザー：「ファイル」ユーティリティはUnixのツールですが、Windowsバージョンはこちらにあります。

ウィンドウズ

このコマンドでダンプファイルを作成します

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

を使用して：

.\mysqldumb --help

-r、-result-file = name

                 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.

mysqldumpWindows PowerShellで次のように実行した後、一度このエラーが発生しました。

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

私はこれをこれに変更しました（代わりに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

そして問題はなくなりました！

私もPowerShellで

私は呼び出すためにPowerShellを使用していたとき、私は、この問題が発生しmysqldumpをし、>をファイルにパイプに出力します。PowerShellはファイルの作成時に誤ったエンコードを使用していたため、mysqlを使用してファイルをインポートしようとしたときに同じエラーが表示されました。

PowerShellセッションでデフォルトのエンコーディングをUTF8に設定すると、この問題が解決されることがわかりました。

私の解決-テスト済みのPowerShell 5.1：

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

例：エクスポートの作成方法（簡略化）：

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

注：これはPowerShell 4.0では機能しないことが発見されました

開発環境は5.1を実行していましたが、prodは4.0であり、初期修正はPowerShellの古いバージョンでは機能しません。

使用する必要がある | Set-Content -Encoding UTF8 $fileName

これはすでにIfediによって提案されました

notepad ++（または別のエディター）で開き、UTF-8に変換/保存してみましたか？

参照：https : //stackoverflow.com/questions/7256049/notepad-converting-ansi-encoded-file-to-utf-8

別のオプションは、textwrangleを使用してファイルをUTF-8として開いて保存することです。http：//www.barebones.com/products/textwrangler/

誰かが圧縮されたgtarを送ってくれました。gtarにあまり慣れていませんでしたが、これは別の圧縮形式です。

$ 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

ただし、通常どおりに解凍できました。

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

そして、インポートを行うことができます：

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

解決策：バックアップファイルを抽出し、この抽出されたSQLダンプを復元します。

例：

バックアップはdump.sql.gzファイルとして取得され、次のようにgunzip cmdを使用して抽出します。

shell>  gunzip dump.sql.gz

そして、RESTOREはdump.sqlファイルを抽出しました。

参照：MySQLバイナリおよびインタラクティブモードについて。

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

それは私とすべてのセットで動作します!!

私の場合、ファイルは破損しています。データベースは拡張子で圧縮されまし.bz2たが、実際には.tar.bz2。

を使用bzip2 -dkして逆コンパイルしてもエラーは出力されず、ファイルが生成されます。fileファイル出力でコマンドbzip2 compressed data, block size = 900kを使用するので、使用するのが間違っているようにも見えません。

私は使わなければなりませんでした tar -xf myfile.bz2