Базы данных: кодировка столбцов, когда это важно?

Question

Мы импортируем данные из .sql сценария, содержащий данные в кодировке UTF-8 закодированы в базу данных MySQL:

mysql ... database_name < script.sql

Позже эти данные отображается на странице в веб-приложения (подключенного к этой базе данных), опять-таки в UTF-8. Но где-то в процессе что-то пошло не так, потому что символы не-ascii отображались некорректно.

Наша первая попытка решить это изменить MySQL столбцы, кодирующим в UTF-8 (как описано, например here):

alter table wp_posts change post_content post_content LONGBLOB;` 
alter table wp_posts change post_content post_content LONGTEXT CHARACTER SET utf8; 

Но это не помогло.

Наконец, мы решили эту проблему, импортировав данные из сценария .sql с дополнительным флагом командной строки, который, как я полагаю, заставил клиента mysql обрабатывать данные из сценария .sql как UTF-8.

mysql ... --default-character-set=utf8 database_name < script.sql

Это помогло, но потом мы поняли, что на этот раз мы забыли изменить кодировку столбца utf8 - он был установлен в latin1 даже если utf8 закодированные данные, протекающий через базу данных (от SQL скрипт для приложения) ,

Итак, если данные, полученные из базы данных, отображаются правильно, даже если набор символов базы данных установлен неверно, то почему я должен беспокоиться о настройке правильной кодировки базы данных?

Особенно я хотел бы знать:

1. Какие части базы данных полагаться на настройки кодирования столбца? Когда этот параметр имеет какой-то реальный смысл?
2. В каких случаях выполняется неявное преобразование кодировки столбцов?
3. Как трюк с преобразованием столбца в двоичный формат, а затем в целевую кодировку работает (см. Фрагмент кода выше)? Я все еще не понимаю.

Надежда кто-то помочь мне убрать вещи ...

Answer 1

Самая главная причина, на мой взгляд, является то, что она разрушает вашу последовательность DB.

• часто случается, что вам нужно проверить данные в базе данных. И если вы не можете правильно вводить строки UTF-8, поступающие с веб-страницы, на ваш клиент CLI MySQL, это очень жаль;
• Если вам нужно использовать phpMyAdmin для администрирования вашей базы данных через «правильную» сеть, то вы ограничиваете себя (возможно, это не проблема);
• Если вам нужно создать отчет о своих данных, то вы сильно ограничены количеством возможных вариантов, так как только веб производит правильный результат;
• , если вам нужно доставить частичный бланк базы данных вашему партнеру или внешней компании для анализа, а извлечение испорчено - очень жаль.

Теперь вопросы:

1. Когда вы запрашиваете базу данных для ORDER BY некоторого столбца типа данных строки, то правил сортировки учитывает кодировку вашей колонки, так как некоторые внутренние trasformation применимы в Если у вас разные кодировки для разных столбцов. То же самое относится, если вы пытаетесь сравнить строки, здесь важна информация о кодировании. Кодирование происходит вместе с сортировкой, хотя большинство людей так часто не используют эту функцию.

2. Как уже упоминалось, если у вас есть какой-либо набор столбцов в разных кодировках, база данных будет выбирать неявное преобразование значений в общую кодировку, которая в настоящее время является UTF8. Неявное кодирование строк может выполняться в клиентских средах/библиотеках в зависимости от кодировки среды клиента. Обычно данные перекодируются в кодировку базы данных при отправке на сервер и обратно в кодировку клиента при отправке результатов.

3. Двоичные данные не имеют понятия кодирования, это всего лишь набор байтов. Поэтому, когда вы конвертируете в двоичный файл, вы сообщаете базе данных «забыть» кодировку, хотя вы сохраняете данные без изменений. Позже вы конвертируете в строку, обеспечивающую правильную кодировку. Этот трюк помогает, если вы уверены, что данные физически находятся в UTF-8, в то время как в некоторых случаях была указана другая кодировка.

Учитывая, что вам удалось загрузить в данных в базу данных с помощью --default-character-set=utf8 то было что-то делать с окружающей средой, я полагаю, это не была установка UTF8.

Я думаю, что лучшая практика сегодня будет:

• имеет всех ваших сред будучи UTF8 готовы, в том числе оболочек;
• есть все ваши базы данных по умолчанию для кодировки UTF8.

Таким образом, у вас будет меньше полей для ошибок.