Неверное строковое значение: '\ xC2\x9Fe 10...' для столбца
У нас есть сервер Old 5.1 Mysql, работающий на сервере 2003. Недавно мы переходим к более новой среде с Mysql 5.6 и сервером 2008. Теперь на новом сервере мы продолжаем получать ошибки при вставке специальных символов, таких как "Ã".
Теперь я проверил исходную кодировку, и это UTF-8. Но старый сервер Mysql был настроен как latin1 (Server/tables/colms) с collation latin_swedish_ci, и мы не получили никаких ошибок в старой среде.
Теперь я провел некоторое тестирование, так как мы не живем в новой среде. Я попытался установить все таблицы на таблицы/столбцы, а также на latin1. В обоих случаях я продолжаю получать эти ошибки.
Я заметил, что на старом сервере сервер по умолчанию char -set - latin1, а на новом сервере - utf-8. Может ли это быть проблема? Я нахожу это очень странным, потому что источником является utf-8.
Есть ли какой-нибудь вариант для обработки этого, который может быть включен в старой среде? Я не уверен, что существует нечто подобное. Я сравнил настройки в инструменте администрирования mysql и, кроме стандартного char -set, выглядит одинаково.
EDIT:
ПОКАЖИТЕ ПЕРЕМЕННЫЕ КАК char% ';
Старый сервер:
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8 | *
| character_set_connection | utf8 | *
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 | *
| character_set_server | latin1 |
| character_set_system | utf8 |
Новый сервер:
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8mb4 | *
| character_set_connection | utf8mb4 | *
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8mb4 | *
| character_set_server | utf8 |
| character_set_system | utf8 |
Насколько я понимаю из статьи на сайте MySQL utf8mb4 - это супер-набор utf8, это не должно создавать проблемы для кодирования, я думаю, поскольку они в основном идентичны по кодировке правильно?
Ответы
Ответ 1
старый UTF-8 из MySQL не был реальным UTF-8. Если вы попробуете "специальные" символы (японский или китайский), вы, вероятно, окажетесь на квадратах или вопросительных знаках на своем старом сервере.
Теперь ваш новый сервер действительно использует UTF-8 (mb4 означает несколько байтов 4). Сервер получает символы UTF-8, но, очевидно, не может хранить символы UTF-8, потому что ваша таблица не использует UTF-8. Преобразуйте все таблицы в UTF-8 и базу данных в UTF-8, и вы решите свою проблему.
Вы можете сделать это с помощью
ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci;
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Не забудьте сделать резервную копию ранее.
Источник: fooobar.com/questions/19544/...
Ответ 2
- Во-первых, поскольку прежняя среда работала правильно, первым выбором было бы использование той же настройки набора символов в новой среде. Если у вас все еще есть доступ к серверу 5.0, возьмите
SHOW VARIABLES;.
5.0 по умолчанию latin1; 5.6 по умолчанию - utf8. Это в основном видно в
mysql> SHOW VARIABLES LIKE 'char%';
+--------------------------+-----------------------------------------------+
| Variable_name | Value |
+--------------------------+-----------------------------------------------+
| character_set_client | utf8 | *
| character_set_connection | utf8 | *
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | utf8 | *
| character_set_server | latin1 |
| character_set_system | utf8 |
SET NAMES utf8; устанавливает три отмеченные строки.
à - hex C3 в latin1 и C383 в utf8. Дополнительные кодировки здесь. Сделайте это, чтобы увидеть, что в настоящее время находится в таблице:
SELECT col, HEX(col) FROM table WHERE ...
-
Другая возможность заключается в том, что "движение" исказило данные. Если вы можете сделать то же самое SELECT на обеих машинах, и если они выйдут иначе, то миграция будет плохим. Поскольку существует много способов перемещения данных, предоставьте подробности миграции, чтобы мы могли проанализировать, что могло бы пойти не так.
-
В вашем заголовке есть C29F. Это странно - это управляющий код APPLICATION PROGRAM COMMAND, о котором я никогда не слышал. (Примечание: это не связано с Ã, о котором вы упомянули ниже.) Пожалуйста, предоставьте больше примеров проблем; ни один из этих подсказок не является полезным.
Ответ 3
Значительная часть этого заключается в том, что ваш старый сервер:
| character_set_database | latin1
в то время как ваш новый сервер имеет
| character_set_database | utf8
Не имеет значения, что соединение и клиент используют utf8, если база данных использует latin1, таблицы будут по умолчанию для latin1, и поэтому данные будут сохранены в latin1, и вы получите свою ошибку. Вы можете, конечно, явно задать набор символов и сортировку для любой таблицы, отличной от базы данных по умолчанию.
Я предполагаю, что при переносе схемы базы данных вы не редактировали кодировку символов для базы данных или таблицы перед запуском миграции script.
Теперь вы можете вручную изменить базу данных и каждую таблицу или изменить миграцию script и повторить ее. Большинство переносов script и дампов базы данных будут содержать специфический набор символов для каждой таблицы, а также для базы данных, даже если они все одинаковы.
Ответ 4
Один опыт, который я получил, когда я переносил свое приложение на новый env. У меня возникла какая-то странная вещь при вставке данных, связанных с данными, которые нужно вставить в таблицу, мой случай, когда он жаловался на дату, был пустым, поэтому он не может быть вставлен в таблицу (без изменения исходного кода). Только новый env (сервер Mysql от 5.1 до 5.6, tomcat 6 to tomcat 7, новая версия сервера Suse).
Я пытаюсь заменить драйвер соединителя mysql на более новую версию для моего приложения и решил проблему.
