Неверное строковое значение: '\ 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 на более новую версию для моего приложения и решил проблему.