0

В приложении Django с внутренними пользователями MySQL DB стараются вставлять заметки, содержащие несколько смайликов и сердец и прочее, которые являются символами Юникода. MySQL отказывается от операций с ошибкой:MySQL Неверная ошибка строкового значения

(1366, "Incorrect string value: '\\xE2\\x9D\\xA4\\xEF\\xB8\\x8F' for column 'note' at row 1") 

(столбец в вопросе имеет longtext Введите символы Unicode в этом случае действительные, это сердце и модификатор https://codepoints.net/U+2764https://codepoints.net/U+FE0F, так что это не то, что они были бы 4 байта. длинные символы UTF-8. Я убедился, что набор символов по умолчанию MySQL - utf-8.)

Интересно, что я не могу полностью воспроизвести эту ошибку в своей локальной среде разработчика. Одно из отличий заключается в том, что оно излучает предупреждение только для этой аномалии.


Update1:

Это все еще беспокоит меня:

mysql> SELECT default_character_set_name FROM information_schema.SCHEMATA WHERE schema_name="sblive"; 
+----------------------------+ 
| default_character_set_name | 
+----------------------------+ 
| latin1      | 
+----------------------------+ 
1 row in set (0.00 sec) 

я преобразовал кодовую в конкретной таблицы в UTF-8:

mysql> alter table uploads_uploads convert to character set utf8 COLLATE utf8_general_ci; 
Query OK, 1209036 rows affected (1 min 10.31 sec) 
Records: 1209036 Duplicates: 0 Warnings: 0 

mysql> SELECT character_set_name FROM information_schema.`COLUMNS` WHERE table_schema = "sblive" AND table_name = "uploads_uploads" AND column_name = "note"; 
+--------------------+ 
| character_set_name | 
+--------------------+ 
| utf8    | 
+--------------------+ 
1 row in set (0.00 sec) 

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  | utf8      | 
| character_set_system  | utf8      | 
| character_sets_dir  | /usr/share/mysql/charsets/ | 
+--------------------------+----------------------------+ 
8 rows in set (0.01 sec) 

mysql> SHOW VARIABLES LIKE '%colla%'; 
+----------------------+-------------------+ 
| Variable_name  | Value    | 
+----------------------+-------------------+ 
| collation_connection | utf8_general_ci | 
| collation_database | latin1_swedish_ci | 
| collation_server  | utf8_unicode_ci | 
+----------------------+-------------------+ 
3 rows in set (0.00 sec) 

ответ

1

Вы просите ❤️ за которым следует «непересекающийся» «ПЕРЕКЛЮЧАТЕЛЬ ИЗМЕНЕНИЙ-16».

  • Ваши байты utf8 - хорошая
  • Ваше соединение должно указать utf8 - не так ли?
  • Столбец TEXT необходимо указать CHARACTER SET utf8 - не так ли? Используйте SHOW CREATE TABLE для проверки.
  • Если вы используете HTML-код, ему необходимо указать charset=UTF-8 - не так ли?

Предлагаем вам перейти на utf8mb4, если «back-end users» могут ввести больше смайликов - «Emoji» понадобится.

Addenda

Давайте проверим данные ... Пожалуйста, запустите этот

SELECT col, HEX(col) FROM ... 

Те два персонажа должны поставить Hex E29DA4 и EFB88F. Если вы видите C3A2C29DC2A4C3AFC2B8C28F, у вас есть «двойная кодировка», что является проблемой более беспорядочной. 2764FE0F будет указывать utf16, я думаю.

+0

Я убедился, что конкретная таблица - UTF-8 с 'alter table table_name конвертировать в набор символов utf8;'. HTML - это запрос API REST, а полезная нагрузка - в JSON. Я попытался указать charset в заголовке ('Content-Type: application/json; charset = utf-8'), но это не повлияло на ситуацию (технически в полезной нагрузке эти символы попадают в кодировку UTF-16). –

+0

Я добавил конфигурацию для сервера по умолчанию для UTF-8. «Character_set_database» («показать переменные типа« character_set_database »;') по-прежнему остается «latin1» (обратите внимание: после того, как я по умолчанию полностью отключил UTF-8 в файле конфигурации, я перезапустил сервер). Однако теперь кодировка таблицы и конкретного столбца должна переопределить это значение для UTF-8, не так ли? –

+0

Где находится utf-16? Это несовместимо с utf8 (но оно может быть преобразовано.) –