从SQL转储还原数据库时启用二进制模式

我对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文件，但仍然给出相同的错误。我该怎么办？请帮忙。

更新

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

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

我在还原转储文件的Windows中遇到相同的问题。我的转储文件是使用Windows powershell和mysqldump创建的，如下所示：

mysqldump db > dump.sql

问题来自powershell的默认编码为UTF16。为了更深入了解这一点，我们可以使用GNU的“文件”实用工具，并且存在一个Windows版本在这里。
我的转储文件的输出是：

小尾数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

在Windows计算机中，请按照前述步骤操作。

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

现在获取您的数据库。

使用Tar存档工具提取文件。您可以通过以下方式使用它：

tar xf example.sql.gz

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

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

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

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

问题就解决了！

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

如果您没有足够的空间或不想在解压缩时浪费时间，请尝试以下命令。

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

不要忘记用压缩文件名替换compressed-sqlfile.gz。

没有上面提供的命令，.gz恢复将无法工作。

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

我遇到了同样的问题，但发现转储文件实际上是MSSQL Server备份，而不是MySQL。

有时，旧版备份文件会给我们带来麻烦。检查您的转储文件。

在终端窗口上：

~$ cat mybackup.dmp 

结果是：

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

要停止处理cat命令：

CTRL + C

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

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

在linux下，使用gunzip解压缩文件，然后使用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做大文件

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

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

zcat {address_sql_database(.tar.gz)} | mysql -u root -p {database_name} --binary-mode

我知道原始的发帖人问题已经解决了，但是我是通过Google来到这里的，各种各样的答案最终使我发现我的SQL转储的默认字符集与导入时的默认字符集不同。我遇到了与原始问题相同的错误，但是由于我们的转储已通过管道传输到另一个MySQL客户端中，因此我们无法采用其他工具打开它并以不同的方式保存它。

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

老但黄金！

在MacOS（Catalina 10.15.7）上，这有点奇怪：我不得不将其重命名dump.sql为它dump.zip，然后，我不得不使用finder（！）解压缩它。在终端中，unzip dump.zipodertar xfz dump.sql[or .gz .tar ...]导致错误消息。

最后，finder将其完全解压缩，之后我可以毫无问题地导入文件。