127

我对 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'.

我试过放入--binary-modeini文件，但它仍然给出同样的错误。我应该怎么办？请帮忙。

更新

正如尼克在他的评论中所建议的那样，我尝试$ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sql了，但它给了我以下内容ERROR at line 1: Unknown command '\☻'. 。这是一个 500 Mb 的转储文件，当我使用 gVIM 查看其内容时，我只能看到无法理解的表达式和数据。

4

18 回答 18

286

解压缩文件，然后再次导入。

于 2014-05-09T16:48:06.323 回答
70

我在 Windows 恢复转储文件时遇到了同样的问题。我的转储文件是使用 windows powershell 和 mysqldump 创建的，例如：

mysqldump db > dump.sql

问题来自powershell的默认编码是UTF16。为了更深入地了解这一点，我们可以使用 GNU 的“文件”实用程序，这里有一个 windows版本。
我的转储文件的输出是：

Little-endian UTF-16 Unicode 文本，行很长，带有 CRLF 行终止符。

然后需要编码系统的转换，并且有各种软件可以做到这一点。例如在 emacs 中，

M-x set-buffer-file-coding-system

然后输入所需的编码系统，如utf-8。

将来，为了获得更好的 mysqldump 结果，请使用：

mysqldump <dbname> -r <filename>

然后输出由mysqldump自身处理，而不是powershell的重定向。

参考：https ://dba.stackexchange.com/questions/44721/error-while-restoring-a-database-from-an-sql-dump

于 2013-11-20T03:46:59.320 回答
30

在 Windows 机器上，请按照上述步骤操作。

  1. 在记事本中打开文件。
  2. 点击另存为
  3. 选择编码类型 UTF-8。

现在获取您的数据库。

于 2017-01-05T04:38:31.777 回答
10

mysqldump在像这样在 Windows 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

问题消失了！

于 2016-01-18T06:41:02.697 回答
10

使用 Tar 归档工具提取文件。你可以这样使用它： 

tar xf example.sql.gz
于 2017-05-11T17:27:09.143 回答
9

如果你没有足够的空间或者不想浪费时间解压，试试这个命令。

gunzip < compressed-sqlfile.gz | mysql -u root -p

不要忘记将compressed-sqlfile.gz 替换为您的文件名。

如果没有我上面提供的命令，.gz restore 将无法工作。

于 2018-11-04T11:41:53.063 回答
8

您是否尝试过在记事本++（或其他编辑器）中打开并将我们转换/保存为 UTF-8？

请参阅：notepad++ 将 ansi 编码文件转换为 utf-8

另一种选择可能是使用 textwrangle 打开文件并将其保存为 UTF-8：http ://www.barebones.com/products/textwrangler/

于 2013-06-18T00:31:12.840 回答
5

可能是您的 dump.sql 文件开头有垃圾字符，或者开头有空行。

于 2015-05-08T12:55:06.717 回答
3

它必须你文件dump.sql问题。使用Sequel Pro检查你的文件编码。它应该是你的dump.sql中的垃圾字符。

于 2014-10-20T03:22:40.890 回答
3

I had the same problem, but found out that the dump file was actually a MSSQL Server backup, not MySQL.

Sometimes legacy backup files play tricks on us. Check your dump file.

On terminal window:

~$ cat mybackup.dmp

The result was:

TAPE??G?"5,^}???Microsoft SQL ServerSPAD^LSFMB8..... etc...

To stop processing the cat command:

CTRL + C
于 2015-07-15T21:29:27.460 回答
2

zcat /path/to/file.sql.gz | mysql -u 'root' -p your_database

于 2020-02-26T07:54:30.333 回答
2

在 linux 下使用 gunzip 解压你的文件 编辑你的解压 sql 文件

vi unzipsqlfile.sql

使用 esc dd 删除第一个二进制行 使用 esc shift g 删除最后一个二进制行 使用 dd 保存文件 esc x: 然后重新导入到 mysql ：

mysql -u 用户名 -p new_database < unzipsqlfile.sql

我使用 jetbackup cpanel mysql 备份中的 20go sql 文件执行该操作。耐心等待 vi 处理大文件

于 2020-06-23T19:27:34.983 回答
1

您尝试导入的文件是一个 zip 文件。解压缩文件，然后再次尝试导入。

于 2018-11-13T08:50:03.060 回答
0

您可以使用它来修复错误：

zcat {address_sql_database(.tar.gz)} | mysql -u root -p {database_name} --binary-mode
于 2019-10-09T20:44:20.030 回答
0

您的文件应该只有 .sql 扩展名，（.zip、.gz .rar）等将不支持。示例：dump.sql

于 2017-10-23T01:02:14.990 回答
0

旧但黄金！

在 MacOS (Catalina 10.15.7) 上，这有点奇怪：我不得不将我的名字重命名dump.sql为dump.zip，之后，我不得不使用 finder(!) 来解压缩它。在终端中，unzip dump.zipodertar xfz dump.sql[or .gz .tar ...]会导致错误消息。

最后，finder 已经完全解压了，之后我可以毫无问题地导入文件。

于 2020-10-13T17:01:42.547 回答
0

我有一个类似的问题。我在 PowerShell 上使用 mysqldump 导出了所有数据库：

mysqldump -u root -p --all-databases

当我尝试在 PowerShell 上导入它时：

mysql -u root -p < .\all-databases.sql

我收到一个错误，说<要为将来的版本保留一些东西。

所以我尝试了上面的命令cmd并得到了和OP一样的错误。

解决方案是使用 PowerShell 和以下命令：

Get-Content '.\all-databases.sql' | &mysql.exe -u user -p

于 2022-02-08T11:32:05.397 回答
0

我知道最初的海报问题已经解决，但我是通过谷歌来到这里的，各种答案最终让我发现我的 SQL 被转储的默认字符集与用于导入它的字符集不同。我得到了与原始问题相同的错误，但由于我们的转储被传送到另一个 MySQL 客户端，我们无法使用另一个工具打开它并以不同方式保存它。

对我们来说，解决方案被证明是一种--default-character-set=utf8mb4选择，既可以用于调用 ，mysqldump也可以用于调用通过 导入它mysql。当然，对于面临相同问题的其他人来说，参数的值可能会有所不同，保持它相同很重要，因为服务器（或工具）的默认设置可能是任何字符集。

于 2020-01-23T09:04:24.860 回答