Кодування в mysql

Ну ось. Злий кодування latin1 немає і в помині, можна перевіряти наш пологовий будинок)))

І ось той страшний удар граблями, який так довго відтягувався! Уважний читач міг помітити, що коли була зроблена спроба примусово змінити кодування стовпчика, що містить дані в latin1, то на кожну запис, що містить російські літери, у MySQL був Варнінг! Це був крик про те, що сервер не знає, яким чином можна перевести дані з latin1 в cp1251, ну і кращого способу, ніж замінити символом не latin1 питаннячко, він не знайшов :))). Пологовий будинок безповоротно втрачений тому, що тепер замість кирилиці в базі містяться вопросики.

Питаннячко можна було уникнути

Насправді, ситуація, коли спочатку виставлена неправильна кодування, зустрічається часто-густо. Симптоми можна виявити наступним чином:

Саме ці змінні відповідають за дефолтні значення кодувань.

character_set_client - кодування, в якій дані будуть надходити від клієнта
character_set_connection - кодування за замовчуванням для всього, що в рамках з'єднання не має кодування
character_set_database - кодування за замовчуванням для баз
character_set_filesystem - кодування для роботи з файловою системою (LOAD DATA INFILE, SELECT. INTO OUTFILE, і т.д.)
character_set_results - кодування, в якій буде обраний результат
character_set_server - кодування, в якій працює сервер
character_set_system - кодування, в якій задаються ідентифікатори MySQL, завжди UTF8
character_sets_dir - папка з кодуваннями

ВАЖЛИВО: Якщо character_sets_dir встановлена невірно, то робота з кодуваннями буде під загрозою. Не намагайтеся змінювати її значення, якщо ви не впевнені в своїх силах. Якщо ви системний адміністратор, то перед установкою краще ознайомитися з мануалом.

Найбільш значимі для простих користувачів такі змінні: character_set_client, character_set_results, character_set_connection. Оскільки саме вони відповідають за внесення, вилучення інформації і створення таблиць / баз відповідно. Якими вони можуть бути?

Будь-яку з цих кодувань можна використовувати на свій смак. Зазвичай російськомовні користувачі вважають за краще cp1251 або utf8, але по суті, неважливо, в якому кодуванні зберігаються дані, важливо, щоб вона була з самого початку правильно вказана і дані були коректно внесені.

Налаштування кодувань

Мануал пропонує нам три варіанти завдання кодувань:

УВАГА. Перші два варіанти працюють тільки в рамках поточного з'єднання. Це означає, що під час наступного підключення всі налаштування повернуться в початковий стан! Щоб не виставляти кодування кожен раз, потрібно скористатися третім варіантом.

Варіант 1 - Через names

Але краще, коли кодування налаштовується прямо в з'єднанні.

Що робити, якщо дані внесені в неправильному кодуванні

Якщо база / таблиця / дані були створені / внесені в кодуванні відмінною від потрібної, то необхідно зробити наступне:

Цей варіант підходить майже для всіх випадків, за винятком деяких особливих ситуацій, наприклад, коли порівняння, виставлене за замовчуванням, недоречно для деяких полів. Приклад - поле для зберігання пароля, необхідно порівнювати його з урахуванням регістру, тоді як за замовчуванням виставляється порівняння без урахування регістру.

Правильний варіант роботи з MySQL

Таким чином, клієнт працює в KOI8-R, але дані зберігаються в cp1251, MySQL знає про це і робить перекодування на льоту.

Ну і на ціпок: