Было бы еще лучше перейти к сопоставлениям utf8mb4 вместо utf8.
Да, возможно, было бы целесообразно перенести почти все на utf8mb4.
Если у вас есть MySQL 5.5 или 5.6, могут быть проблемы с utf8mb4. Однако есть обходные пути.
Существует несколько способов преобразования таблиц, но только один способ будет правильным. И какой путь является «правильным», зависит от того, испорчены ли данные в таблице. SELECT HEX(col) ...
выдаст FCDCEF80E1E0E9C9
для üÜï€áàéÉ
, если CHARACTER SET
(то есть «кодировка») - latin1. Для utf8 или utf8mb4, гекс будет C3BCC39CC3AFE282ACC3A1C3A0C3A9C389
.
См. SHOW VARIABLES LIKE 'chara%';
- некоторые из них не должны быть изменены. Те, на которых нужно сосредоточиться, - это три, установленные SET NAMES utf8mb4;
. (Сделайте еще раз SHOW
, чтобы увидеть, какие из них изменились. Затем еще один SET
, чтобы вернуть их.)
Что касается COLLATION
до go с, ..._general_ci
наименее интересен , Однако, пока вы не разберетесь в деталях сравнений или упорядочения для разных языков, параметры сортировки не будут иметь большого значения.
Кодировка и параметры сортировки базы данных - это значения по умолчанию для вновь создаваемых таблиц , Вместо того, чтобы беспокоиться об этом, приобретите привычку явно указывать на CREATE TABLE
. Набор символов и параметры сортировки таблицы - это значения по умолчанию для новых столбцов в таблице.
Затем в соединении есть набор символов и параметры сопоставления. Это важно, потому что он объявляет кодировку (кодировку) байта в клиенте. Сопоставление связи может повлиять на вопрос, который вы задали. (Извините, но перед тем, как перейти к вашему Вопросу, нужно было многое заложить). Так что приведите сопоставление в соответствие с вашими базами данных и таблицами.