zaLinux.ru

Ошибка «ERROR: ASCII ‘\0’ appeared in the statement, but this is not allowed» (РЕШЕНО)


При импорте базы данных через mysql клиент примерно следующим образом:

mysql -uroot < z:\all-databases.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: ' ■-'.

В ней сказано, что появился символ, который стал неожиданностью для СУБД. Подразумевался текстовый файл, а программа столкнулась с символами, характерными для бинарного файла. Поэтому она нас советует — что если это действительно бинарный файл, то нужно установить соответствующий режим с помощью опции --binary-mode.

Обычно дамп базы данных НЕ является бинарным файлом, поэтому опция --binary-mode будет неуместной в данном случае. Необходимо найти настоящую причину проблемы.

Во-первых, убедитесь, что вы по ошибке не импортируете архив. То есть если вы поместили дамп базы данных в архив, не забудьте перед восстановлением базы данных извлечь её из этого архива.

Вторая причина может быть в кодировке файла дампа. Как мы можем видеть, MySQL предполагает, что это файл в ASCII кодировке.

С помощью команды file можно проверить, какая именно это кодировка. Например, у меня файл расположен по пути /mnt/disk_d/Share/all-databases.sql, проверяю его:

file '/mnt/disk_d/Share/all-databases.sql'

В моём случае выведено:

/mnt/disk_d/Share/all-databases.sql: Little-endian UTF-16 Unicode text, with very long lines, with CRLF line terminators

То есть это UTF-16 с очень длинными строками.


Чтобы исправить проблему в данном случае, конвертируйте файл в UTF-8 с помощью iconv командой вида:

iconv -f utf-16 -t utf-8 ИСХОДНЫЙ_ФАЙЛ.sql > НОВЫЙ_ФАЙЛ_utf8.sql

Реальный пример в моей ситуации:

iconv -f utf-16 -t utf-8 '/mnt/disk_d/Share/all-databases.sql' > '/mnt/disk_d/Share/all-databases_utf8.sql'

После этого я успешно смог импортировать новый файл all-databases_utf8.sql для восстановления базы данных:

mysql -uroot < z:\all-databases_utf8.sql

Такая ситуация у меня возникла когда я файл дампа, созданный в Windows, хранил в Linux. Затем в Linux же я его распаковал и вернул в Windows для восстановления. Также есть сообщение, что другой пользователь столкнулся с этой же ошибкой при переносе файла из Windows в Mac. То есть причиной неправильного определения кодировки может стать подготовка дампа в одной операционной системе и импорт в другой. Для решения этой проблемы достаточно конвертировать кодировку показанным выше способом.

Чтобы правильно определить исходную кодировку файла, смотрите статью «Как определить кодировку файла или строки. Как конвертировать файлы в кодировку UTF-8 в Linux».

P.S.

У меня на скриншоте новая ошибка:

ERROR 3554 (HY000) at line 24230: Access to data dictionary table 'mysql.index_stats' is rejected.

Это какая-то новая «фича» MySQL 8.0 с которой ещё предстоит разобраться…


Рекомендуемые статьи:

Оставить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *