Проблема с кодировкой UTF-8 при импорте файла sql

Question

У меня есть сервер, на котором размещается MySQL, PHPMyAdmin сообщает:

Server version: 5.1.56-community
MySQL charset: UTF-8 Unicode (utf8)

Я экспортирую sql с использованием mysqldump -uroot -p database > file.dump или mysqldump -uroot -p database -r file.dump (оба сгенерированных файла в любом случае идентичны).

Локально я установил MySQL 5.5 и HeidiSQL 9.5.

В качестве файла SQL сервера my.ini имеет:

default-character-set=utf8

Я изменил локальный файл my.ini на

default-character-set=utf8

Но также:

character-set-server=utf8

Им обоим присвоено значение latin1.Не знаю, почему у меня установлен character-set-server, а сервер - нет.В любом случае.

Теперь я запускаю HeidiSQL, он показывает utf8mb4 ссылки вместо utf8 для параметров сеансов.Я не знаю почему:

Теперь я импортирую свой дамп-файл и вижу, что даже если все явно настроено в utf8похоже, у меня есть некоторые проблемы с кодировкой.

На сервере я вижу:

Локально, в HeidiSQL, я вижу:

Специальные символы, такие как à, не отображаются правильно в локальной базе данных.

Я что-то не так делаю?

Обратите внимание, что если я устанавливаю HeidiSQLна сервере на вкладке переменных отображаются те же значения для параметров Session и Global , и à отображается правильно.

Так что это может быть основной причиной проблемы, но я не знаю, как ее исправить.Если я изменю значения Session перед импортом файла sql, это не решит проблему, и при следующем запуске HeidiSQL значения вернутся к utf8mb4.

Answer 1

Благодаря комментарию deceze я мог бы решить эту проблему.

В HeidiSQL, когда я выбираю файл sql для выполнения, на самом деле есть опция "ncoding", которую я изначально не заметил; -)

Если я сохраню «автоопределение», при импорте будет получен плохой контент (с символами моджибаке)

Если ввести «UTF-8», импорт будет идеальным

Не знаю, почему HeidiSQLне удается автоматически определить кодировку ...

Answer 2

У вас есть "Моджибаке".à превращается в Ã (есть два символа, второй - пробел).

Это происходит, когда latin1 участвует где-то в процессе.Настройки SESSION и GLOBAL не являются ошибочными.Давайте посмотрим SHOW CREATE TABLE.

См. Моджибаке в Проблема с символами UTF-8;я вижу не то, что я сохранил для вероятных причин.Это может включать «двойное кодирование»;давайте посмотрим SELECT col, HEX(col) ....

Что касается исправления данных - это зависит от того, используете ли вы просто Mojibake или Double Encoding.См. http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases для обоих.

Answer 3

Несколько мыслей:

Похоже, у вас правильно настроен набор символов.Тот факт, что HeidiSQL отображает другой набор символов, возможно, связан с тем, что клиенты сами устанавливают набор символов.

Например, ваш сервер mysql может использовать «Набор символов A» по умолчанию.Если клиент подключается и говорит, что хочет «Набор символов B», сервер преобразует его на лету.

utf8mb4 - это расширенный набор символов (и превосходит) utf8.По умолчанию ваш сервер должен иметь значение utf8mb4.Популярный вариант использования utf8mb4 - эмодзи.

В любом случае, причина, по которой вы получаете mojibake , вероятно, не связана с правильной настройкой этих наборов символов.

Что я думаюмогло произойти следующее (это предположение).

1. Ваши таблицы / столбцы были установлены как UTF-8.
2. Клиент подключается и сообщает серверу "Я хочувместо этого используйте ISO-8559-1 / latin ".
3. Сервер с радостью соблюдает и преобразует строки ISO-8559-1 клиентов в UTF-8 на лету.
4. Несмотря на желание клиентачтобы использовать ISO-8559-1, он на самом деле отправляет UTF-8.
5. Сервер считает, что данные ISO-8559-1 и обрабатывает их как таковые, и преобразует UTF-8используя ISO-8559-1 для UTF.По сути, это двойное кодирование.

Если я прав, это означает, что вы можете установить для всех ваших столбцов, соединений и таблиц UTF-8, но ваши данные просто плохие.

Если это правильно, этот процесс является обратимым

Вам просто нужна противоположная операция.Например, если бы у вас была строка PHP $data, которая «дважды кодируется» как UTF-8, процесс будет просто вызывать это:

$output = utf8_decode($input)

Это также можно исправить вMySQL.См. Этот вопрос переполнения стека.

Несколько вещей, о которых следует знать:

1. Убедитесь, что это действительно так.Получаете ли вы правильный вывод после этой операции?
2. Совершайте резервные копии, очевидно.
3. Также убедитесь, что все, что записывало UTF-8 с двойным кодированием в вашу базу данных, теперь исправлено.Последнее, что вам нужно, это таблица, представляющая собой смесь разных кодировок.

Sidenote: Эта проблема встречается крайне часто.Вам несколько повезло, что вы француз, потому что это выдвигает на первый план проблему.У многих английских систем, которые я видел, есть эта проблема, но она в основном остается незамеченной долгое время, потому что большая часть текста не выходит за пределы общего диапазона ASCII.