Niepoprawna wartość ciągu: '\ xC2 \ x9Fe 10 ...' dla kolumny

Question

Mamy stary serwer 5.1 MySQL działający na serwerze 2003. Ostatnio przechodzimy do nowszego środowiska z MySQL 5.6 i serwerem 2008. Teraz na nowym serwerze ciągle dostajemy błędy podczas wstawiania specjalnych znaków, takich jak "Ã".

Teraz sprawdziłem kodowanie źródłowe i jest to kodowanie UTF-8. Ale stary serwer Mysql został skonfigurowany jako latin1 (serwer/tabele/colonms) z kolacją latin_swedish_ci i nie otrzymaliśmy żadnych błędów w starym środowisku.

Teraz zrobiłem kilka testów, ponieważ nie żyjemy w nowym środowisku. Próbowałem ustawić wszystkie tabele na tabele/colonms, a także latin1. W obu przypadkach ciągle dostaję te błędy.

Zauważyłem, że na starym serwerze domyślny zestaw znaków serwera to latin1, a na nowym serwerze jego utf-8. Czy to może być problem? Uważam to za bardzo dziwne, ponieważ źródłem jest utf-8.

Czy jest jakaś opcja poradzenia sobie z tym, które można włączyć w starym środowisku? Nie jestem pewien, czy coś takiego istnieje. Porównywałem ustawienia w narzędziu administratora mysql i oprócz domyślnego zestawu znaków wygląda to tak samo.

EDIT:

POKAŻ zmienne jak char '%';

starego serwera:

+--------------------------+-----------------------------------------------+ 
| 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           | 

Nowy Serwer:

+--------------------------+-----------------------------------------------+ 
| 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           | 

O ile rozumiem z artykułu nad na utf8mb4 stronie MySQL jest super-zestaw utf8 nie powinno to stanowić problemu dla kodowania Myślę, że ponieważ są one zasadniczo identyczne na kodowaniu, prawda?

Answer 1

Numer old UTF-8 of MySQL nie był prawdziwy UTF-8. Jeśli spróbujesz "specjalnych" znaków (japońskiego lub chińskiego), prawdopodobnie skończysz z kwadratami lub znakami zapytania na starym serwerze.

Twój nowy serwer teraz naprawdę używa UTF-8 (mb4 oznacza wiele bajtów 4). Serwer odbiera znaki UTF-8, ale oczywiście nie może przechowywać znaków UTF-8, ponieważ twoja tabela nie używa UTF-8. Konwertuj wszystkie tabele na UTF-8 i bazę danych na UTF-8, a rozwiążesz problem.

Można to zrobić za pomocą:

ALTER DATABASE databasename CHARACTER SET utf8 COLLATE utf8_unicode_ci; 
ALTER TABLE tablename CONVERT TO CHARACTER SET utf8 COLLATE utf8_unicode_ci; 

przed Nie zapomnij o kopii zapasowej.

Źródło: https://stackoverflow.com/a/6115705/1980659

Answer 2

Jeden z doświadczonych dostałem, kiedy przenosiłem moją aplikację do nowego środowiska. Podczas wstawiania danych związanych z danymi, które mają być wstawione do tabeli, coś dziwnego, moja sprawa narzekała na to, że data była pusta, więc nie można jej wstawić do tabeli (Brak zmiany kodu źródłowego Tylko nowy serwer env (serwer Mysql od 5.1 do 5.6) Tomcat 6 Tomcat 7, nowa wersja serwera Suse).

próbuję zastąpić sterownik złącze mysql do nowszej wersji dla mojej aplikacji i on rozwiązany.

Answer 3

1. po pierwsze, ponieważ stare środowisko było działa poprawnie, pierwszym wyborem byłoby użycie tego samego ustawienia "zestawu znaków" w nowym środowisku.Jeśli nadal masz dostęp do serwera 5.0, chwyć SHOW VARIABLES;.

5.0 domyślnie ustawiono na ; 5.6 domyślnie przyjmuje wartość utf8. Jest to najbardziej widoczne w

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; wyznacza trzy oznaczone liniami.

Ã to hex C3 w latin1 i C383 w utf8.More encodings here. Czy to aby zobaczyć co jest aktualnie w tabeli:

SELECT col, HEX(col) FROM table WHERE ... 

1. Inną możliwością jest to, że „ruch” zniekształcone dane. Jeśli możesz zrobić to samo na obu komputerach i jeśli wyjdą inaczej, migracja była zła. Ponieważ istnieje wiele sposobów przenoszenia danych, podaj szczegóły migracji, abyśmy mogli przeanalizować, co mogło się nie udać.

2. W tytule masz C29F. To dziwne - to kod kontrolny APPLICATION PROGRAM COMMAND, o którym nigdy nie słyszałem. (Uwaga: nie jest to związane z Ã, o której wspomniałeś później.) Proszę podać więcej przykładów problemów; żadna z tych wskazówek nie jest pomocna.

Answer 4

Znaczna część tego jest, że Twój stary serwer miał:

| character_set_database | latin1 

czasie, gdy nowy serwer ma

| character_set_database | utf8 

To nie ma znaczenia, że ​​połączenie i klient używa UTF8, jeśli baza danych używa Latin1, tabele będą domyślnie latin1, więc dane będą przechowywane w latin1, a otrzymasz swój błąd. Można oczywiście jawnie ustawić zestaw znaków i sortowanie dla każdej tabeli, która będzie inna niż domyślna baza danych.

Domyślam się, że podczas migracji schematu bazy danych nie edytowano kodowania znaków dla bazy danych lub tabel przed uruchomieniem skryptu migracji.

Teraz możesz ręcznie zmienić bazę danych i tabelę, albo edytować skrypt migracji i ponownie go uruchomić. Większość skryptów migracji i zrzutów bazy danych zawiera specyficzny zestaw znaków dla każdej tabeli, a także dla bazy danych, nawet jeśli wszystkie są takie same.