mysql collate что это

Sergey Danielyan

Корректная настройка MySQL для работы с UTF8

Основная цель данного поста — выяснить, какие параметры и с какими значениями следует прописать в конфигурационный файл my.cnf (my.ini) для дальнейшей беспроблемной работы с Юникодом.

Рабочее окружение

UTF8 на данный момент у меня успешно работает в Мастер-Слейв конфигурации:

Любой внешний клиент в состоянии корректно работать с UTF8 базой (проверено на EMS Manager for MySQL c Windows 8 x64).

Все опции и настройки я привожу для версии сервера 5.1.x, однако с минимальными (а то и вовсе без оных) изменениями все это будет работать и на версиях 5.5.x и 5.6.x.

Параметры кодировок MySQL

Довольно часто приходится видеть в ответах на вопросы о настройке UTF8 следующее:

Предполагается, что после вставки всего этого добра (тут кстати есть противоречащие друг другу опции) в конфигурационный файл my.cnf (my.ini) магический Юникод начнет работать.

Но давайте забудем о списке и попытаемся разбираться со всеми опциями сами и начнем с самого начала. То есть с документации. Потому как все это прекрасно описано в документации MySQL на официальном сайте. Я лишь постараюсь последовательно рассказать о параметрах сервера и прояснить неясные моменты.

Символьная кодировка может быть задана для:

Сделано это для гибкой настройки баз данных и доступа клиентов с разными кодировками. Однако, последнее не входит в область рассмотрения данного поста, поэтому будем рассматривать вариант с кодировкой UTF8 настроенной для всего по-умолчанию.

Все параметры могут быть переданы серверу тремя разными способами:

Второй и третий варианты рассматриваться не будут. Тут уместно будет просто прочитать официальные доки — в каждом разделе приведены примеры конфигурации с использованием всех трех способов. Я же буду использовать первый вариант.

Кодировка (character set) и представление (collation) сервера

Тут есть несколько фундаментальных вещей которые надо понимать.

Можно задать оба параметра либо только один из них. При этом важно знать как задача того или иного влияет на определение отсутствующего:

SHOW COLLATION LIKE ‘your_character_set_name’;

Поле Default дает ответ о представлении выбранной кодировки.

В нашем случае, при настройке дефолтной кодировки в UTF8, параметры должны быть определены, так как могут быть использованы при определении кодировки или представления базы данных:

Наши команды:
my.cnf (my.ini)

[mysqld]
character-set-server = utf8
collation-server = utf8_unicode_ci

Кодировка (character set) и представление (collation) базы данных

Тут есть два варианта определения кодировки и представления:

явно — при выполнении запроса на создание базы данных:

CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci;

Вообще при работе с базой данных огромную роль помимо серверных настроек играют настройки клиент-серверного соединения (connection). На этом этапе вступают в игру следующие специфичные для соединения параметры:

Есть еще представление кодировки соединения ( colation_connection ). Для чего нужен этот параметр думаю пояснять не надо.

Озадачиваться проблемой инициализации всех этих переменных не стоит (хотя в нашем случае присвоить им значения необходимо). Есть способ проще: существует два типа запросов (statements) которые задают настройки соединения клиента с сервером группой:

Запрос SET NAMES ‘charset_name’ [COLLATE ‘collation_name’]

Параметр определяет в какой кодировке теперь будут приходить сообщения для сервера от клиента. Прелесть в том, что запрос SET NAMES x эквивалентен следующей группе:

SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;

Для определении представления кодировки соединения ( colation_connection ) отличного от дефолтного, следует дополнить запрос:

SET NAMES x COLLATE y

SET NAMES utf8 COLLATE utf8_unicode_ci

Таким образом, используя только этот запрос, можно добиться корректной UTF8 инициализации соединения.

Однако, тут есть один нюанс:

init_connect=‘SET collation_connection = utf8_unicode_ci’

Запрос SET CHARACTER SET charset_name

Запрос групповой и он также эквивалентен следующей группе:

SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

Согласно документации, разница между двумя запросами в том, что параметры character_set_connection и collation_connection будут установлены на @@character_set_database и @@collation_database соответственно (выше я про них упоминал).

Наши команды:
my.cnf (my.ini)

[client]
default_character_set = utf8

[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’

Кодировка (character set) и представление (collation) таблиц

Тут все довольно просто. Задать кодировку и ее представление можно через команды:

CREATE TABLE t1 ( … )
CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Тут главное иметь в виду, что если эти настройки не заданы, то берутся настройки базы данных (см. пред. раздел). Нам эти настройки не интересны.

Кодировка (character set) и представление (collation) колонок в таблице

Тут по аналогии с пред. секцией. Если параметры кодировок не указаны, берутся те, что указывались для таблицы.

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

skip-character-set-client-handshake

Верификация настроек

Итак, вот финальный snapshot наших изменений в файле my.cnf (my.ini):

[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’
character-set-server = utf8
collation-server = utf8_unicode_ci

[client]
default-character-set = utf8

После применения всех опций и рестарта сервера mysql для проверки настроек можно воспользоваться командами SHOW VARIABLES LIKE ‘char%’ и SHOW VARIABLES LIKE ‘collation%’ ;

Состояние среды до изменений:

Состояние среды после изменений (в случае, если вы приконнектились не SUPER пользователем):

Для примера, вот отличие при соединении через mysql.exe пользователем с и без привилегии SUPER:

с привилегией и выполненной вручную командой ‘SET collation_connection = utf8_unicode_ci’:

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

Источник

А какая разница какой Collation выбрать?

Статья подготовлена для студентов курса «MS SQL Server разработчик»
Хочу поделиться историей из одного из предыдущих проектов, которая иллюстрирует, что Collation нужно выбирать очень вдумчиво. И о том, что бывает, если этот параметр все-таки выбрали неверно, и какие варианты решения проблемы бывают.

Сначала небольшое введение о том, что же такое Collation. В SQL Server параметр Collation указывает серверу, как нужно сортировать и сравнивать строки. Вот, например, строки “Apple” и “apple”. Они разные или нет? Это зависит от указанного Collation. Если с регистром все более менее понятно, то что делать с примером “елка” и “ёлка”? Считать их как одинаковые или как разные? Это все тоже в Collation.

История случилась в проекте, функционал которого очень похож на DropBox или Google Диск. Он предоставляет возможность управлять своими синхронизированными папками и файлами на разных машинах, а также возможность другим пользователям иметь доступ к данной синхронизированной папке.

Итак, история началась с того, что на Prod серверах было 75-90% ошибок в логах (см скриншот ниже), и непонятно откуда они возникали, и в чем была их причина. Ошибка звучала так: “ReadWrtLst is not complete”. Далее шли детали пользователя и его папки.

По коду довольно быстро было найдено место, которое генерирует ошибку, но понять, почему она возникала, и как ее воспроизвести, у нас не получалось.Понятно было только то, что ошибка каким-то образом связана с тем, что пользователь как-то умудрился сделать еще одну папку с таким же именем в своей ОС.

Мы собрали информацию по пользователям, по которым выдается эта ошибка. И тут нас ждал первый сюрприз: из миллионов пользователей системы эта ошибка случалась всего у 50. И эти 50 пользователей генерируют 90% логов об ошибках. Так как ситуацию не получалось воспроизвести, то мы решили связаться с одним из пользователей и выяснить, по какой причине у него не синхронизируется одна из папок. Папка выглядела для нас так же, как и другие, единственное отличие было в том, что называлась она на языке пользователя с использованием иероглифов. А пользователь был японцем. К слову сказать, среди этих 50 пользователей, японцев было большинство.

Благодаря одному из разработчиков команды, нам удалось воспроизвести ошибку. Ошибка заключалась в том, что операционная система считала названия папок разными, а SQL Server считал их одинаковыми из-за выбранного Collation.

Collation, который использовался в проекте:
SQL_Latin1_General_CP1_CI_AS

Небольшое отступление о том, как прочесть Collation. (Если вы знакомы с ним, смело пропускайте.)

Итак, в Collation есть несколько частей:

Этот Collation был когда-то Collation по умолчанию, когда устанавливали SQL Server.

Какие опции есть еще?

Все текстовые поля в БД использовали тип NVARCHAR.
Получается, что, так как текущий Collation игнорировал разницу написания японских иероглифов и разницу в ширине символов, то SQL Server сравнивал строки не так, как это делала операционная система, что и вызывало проблему, т.е. пользователь мог создать папки, не мог их добавить в систему для синхронизации. Тоже самое возникло бы в дальнейшем при сравнении имен файлов.

Мы стали думать о том, как можно решить данную проблему и изменить Collation.

Collation можно выставлять на нескольких уровнях:

При этом, не рекомендуется иметь внутри БД разные Collation, потому что каждый раз при сравнении строк с разным Collation нужно будет делать преобразование с помощью COLLATE, указывая серверу, какой порядок сравнения ему нужно использовать.

Какие опции есть в ситуации, когда понятно, что Collation выбран не очень правильно?

Первая опция — изменение Collation на уровне БД — наиболее сложна. В случае с БД потребовалось бы пересоздать базу данных и перезалить туда данные. Так как система работала 24/7, эта опция была отвергнута сразу.

Вторая опция про изменение поля: самый простой вариант ее реализовать — это добавить поле с нужным Collation и туда перенести данные. Но тогда нужно будет изменять код в БД, который работает с этим полем, а кода в БД было очень много.

Третья опция понравилась нам больше всего, так как в теории это вносило меньше всего изменений, так как основное поле продолжало бы существовать с текущим Collation, и мы бы не имели проблем с его преобразованием, при этом весь нужный функционал в виде учета японской азбуки или широких символов бы работал. Минус в том, что нужно было вносить изменения в часть ПО, но так как эта серверная часть, это можно было сделать.

Четвертая опция была наиболее простой в данном случае, потому что общее число пользователей было несколько миллионов, а проблема возникала только у 50. Однако, если бы приложение активно использовалось в Японии, данное решение было бы мало применимо.

После представления данных руководству, было решено известить пользователей о том, что ПО не поддерживает ряд символов, и при их использовании в названии синхронизируемых файлов и папок ПО может работать некорректно. Это временное решение, потому что при дальнейшем распространении, количество пользователей, сталкивающихся с подобной проблемой, будет нарастать, и нужно будет что-то менять, используя первые три опции.

Лучший вариант выбора Collation — исходить из требований вашего приложения. Если вам нужно, чтобы SQL Server сравнивал строки так же как ОС, то Collation по умолчанию точно неверен. К сожалению, такие нюансы редко видны на старте проекта при проектировании системы, но, надеюсь, прочитав статью, Вы вспомните об описанной ситуации и не наступите на подобные грабли сами.

Источник

COLLATE (Transact-SQL)

Определяет параметры сортировки базы данных или столбца таблицы либо операцию приведения параметров сортировки при использовании с выражением строки символов. Именем параметров сортировки может быть либо имя параметров сортировки Windows, либо имя параметров сортировки SQL. Если не указывать этот параметр при создании базы данных, ей будут назначены параметры сортировки по умолчанию для экземпляра SQL Server. Если не указывать его при создании столбца таблицы, столбцу назначаются параметры сортировки по умолчанию для базы данных.

Синтаксические обозначения в Transact-SQL

Синтаксис

Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.

Аргументы

collation_name — имена параметров сортировки, применяемых к выражению, определению столбца или определению базы данных. Аргументом collation_name может быть только заданное имя Windows_collation_name или SQL_collation_name. Аргумент collation_name должен быть литеральным значением. Имя collation_name не может быть представлено переменной или выражением.

Аргумент Windows_collation_name является именем параметров сортировки для Windows Collation Name.

Аргумент SQL_collation_name является именем параметров сортировки для SQL Server Collation Name.

database_default — заставляет предложение COLLATE наследовать параметры сортировки текущей базы данных.

Примечания

Предложение COLLATE можно указывать на нескольких уровнях. В их числе можно назвать следующие:

Создание или изменение базы данных.

Предложение COLLATE можно использовать в инструкциях CREATE DATABASE и ALTER DATABASE для указания параметров сортировки по умолчанию для базы данных. Можно также задать параметры сортировки при создании базы данных с помощью среды SQL Server Management Studio. Если не указывать параметры сортировки, базе данных присваиваются параметры сортировки по умолчанию для экземпляра SQL Server.

Параметры сортировки Windows в Юникоде могут использоваться с предложением COLLATE только для типов данных nchar, nvarchar, and ntext на уровне столбцов и на уровне выражений. Ими нельзя пользоваться в предложении COLLATE для задания и изменения параметров сортировки базы данных или экземпляра сервера.

Создание или изменение столбца таблицы.

Кроме того, в предложении COLLATE можно использовать параметр database_default для указания того, что столбец во временной таблице должен использовать параметры сортировки текущей пользовательской базы данных, заданные по умолчанию для соединения, а не параметры сортировки базы данных tempdb.

Приведение параметров сортировки выражения.

Предложение COLLATE можно использовать для применения символьного выражения к определенным параметрам сортировки. Символьным литералам и переменным присваиваются параметры сортировки по умолчанию для текущей базы данных. Ссылкам столбцов присваивается определение параметров сортировки для столбца.

Параметры сортировки идентификатора зависят от уровня, для которого определен этот идентификатор. К идентификаторам объектов на уровне экземпляров, таких как имена входа и имена базы данных, применяются параметры сортировки по умолчанию для экземпляра. К идентификаторам объектов внутри базы данных, таких как таблицы, представления и имена столбцов, применяются параметры сортировки, используемые по умолчанию для базы данных. Например: две таблицы, имена которых отличаются только регистром, можно создать в базе данных с параметрами сортировки, учитывающими регистр букв, но нельзя создать в базе данных с параметрами сортировки без учета регистра. Дополнительные сведения см. в разделе Идентификаторы баз данных.

Переменные, метки GOTO, временные хранимые процедуры и временные таблицы можно создавать, если контекст соединения связан с одной базой данных, и ссылка на которую сохраняется, когда контекст переключается на другую базу данных. Идентификаторы переменных, меток GOTO, временных хранимых процедур и временных таблиц имеют параметры сортировки по умолчанию для экземпляра сервера.

Предложение COLLATE можно применять только к типам данных char, varchar, text, nchar, nvarchar и ntext.

COLLATE использует аргумент collate_name для ссылки на имя параметров сортировки SQL Server или Windows, которые применяются к выражению, определению столбца или определению базы данных. collation_name может быть только указанным Windows_collation_name или SQL_collation_name, и параметр должен содержать литеральное значение. Имя collation_name не может быть представлено переменной или выражением.

Параметры сортировки обычно определяются по имени, за исключением программы установки. В программе установки вместо имени указывается обозначение базовых параметров сортировки (языковой стандарт параметров сортировки) для параметров сортировки Windows, а затем определяются настройки сортировки с учетом или без учета регистра или диакритических знаков.

Чтобы получить список всех допустимых имен параметров сортировки для Windows и SQL Server, можно выполнить системную функцию fn_helpcollations:

SQL Server поддерживает только кодовые страницы, существующие в базовой операционной системе. При выполнении операции, зависящей от параметров сортировки, используемых ссылочным объектом, параметры сортировки SQL Server должны использовать кодовую страницу, которая поддерживается работающей на компьютере операционной системой. Эти операции могут включать:

Преобразование кодовых страниц поддерживается для типов данных char и varchar, однако поддержка типа данных text не предусмотрена. Сообщения о потере данных во время преобразования кодовых страниц не выводятся.

Если параметры сортировки, заданные или применяемые объектом, на который указывает ссылка, используют кодовую страницу, не поддерживаемую Windows, SQL Server выдает ошибку.

Примеры

A. Указание параметров сортировки во время SELECT

В следующем примере создается простая таблица, а затем вставляются четыре строки. Затем в примере применяются два параметра сортировки при выборе данных из таблицы, при этом демонстрируется, что Chiapas сортируется по-разному.

Ниже приведены результаты первого запроса.

Ниже приведены результаты второго запроса.

Б. Дополнительные примеры

Дополнительные примеры, в которых используется COLLATE, приведены в разделе Ж. Создание базы данных и назначение имени и параметров сортировки статьи CREATE DATABASE и в разделе Ф. Изменение параметров сортировки столбца статьи ALTER TABLE.

Источник

Mysql collate что это

Эта глава обсуждает следующие темы

Что является наборами символов и объединениями?

Заданная по умолчанию система с многоими уровнями для назначения набора символов.

Синтаксис для определения наборов символов и объединений.

Функции и операции с символами.

Поддержка стандарта Unicode.

Наборы символов и объединения, которые доступны, с примечаниями.

Проблемы набора символов воздействуют на хранение данных, но также и на связь между программами пользователя и сервером MySQL. Если Вы хотите, чтобы программа пользователя связалась с сервером, использующим набор символов, отличный от значения по умолчанию, вы должны будете указать, который именно. Например, чтобы использовать utf8 Unicode, выдайте эту инструкцию после соединения с сервером:

10.1. Наборы символов и объединения вообще

Набор символов представляет собой множество символов и их кодов. Объединение задает набор правил для сравнения символов в наборе символов. Давайте сделаем различие явным с помощью примера.

MySQL может делать эти дела для Вас:

Хранить строки, использующие ряд наборов символов.

Сравнивать строки, использующие ряд объединений.

Смешивать строки с различными наборами символов или объединениями в той же самой базе данных или даже той же самой таблице.

Позволяет спецификацию набора символов и объединения в любом уровне.

В этих отношениях MySQL далек от большинства других систем управления базами данных. Однако, чтобы использовать эти свойства, Вы должны знать, какие наборы символов и объединения являются доступными, как изменить значения по умолчанию, и как они воздействуют на поведение строковых операторов и функций.

10.2. Наборы символов и объединения в MySQL

Объединения в latin1 имеют следующие значения:

Объединения имеют эти общие характеристики:

Два различных набора символов не могут иметь то же самое объединение.

Имеется соглашение для имен объединения: они начинаются с имени набора символов, с которым они связаны, они обычно включают имя языка, и они заканчиваются на _ci (case insensitive), _cs (case sensitive) или на _bin (binary).

10.3. Определение наборов символов и объединений

Имеются установки по умолчанию для наборов символов и объединений в четырех уровнях: сервер, база данных, таблица и столбец. Следующее описание может показаться сложным, но было показано практически, что много уровней значений по умолчанию ведет к естественным и очевидным результатам.

10.3.1. Набор символов и объединение на стороне сервера

Сервер MySQL имеет набор символов и объединение сервера. Они могут быть установлены при запуске и изменены во время выполнения.

mysqld и скрипт configure проверяют, что комбинация объединений и наборов символов допустима. Если это не так, каждая из упомянутых программ отображает сообщение об ошибке и завершается.

10.3.2. Набор символов и объединение базы данных

Каждая база данных имеет набор символов и объединение базы данных. Инструкции CREATE DATABASE и ALTER DATABASE имеет факультативные предложения для определения набора символов базы данных и объединения:

Предложения CHARACTER SET и COLLATE делают возможным создать базы данных с различными наборами символов и объединениями на том же самом сервере MySQL.

MySQL выбирает набор символов и объединение базы данных следующим способом:

Иначе, применяется набор символов и объединение сервера.

10.3.3. Набор символов и объединение таблицы

Каждая таблица имеет набор символов таблицы и объединение. Инструкции CREATE TABLE и ALTER TABLE имеют факультативные предложения для определения набора символов таблицы и объединения:

MySQL выбирает набор символов таблицы и объединение следующим способом:

Иначе, используется набор символов и объединение от базы данных.

Набор символов таблицы и объединение используется как значения по умолчанию, если набор символов столбца и объединение не определен в индивидуальных определениях столбца. Набор символов и объединение таблицы представляют собой расширения MySQL, не имеется ничего такого в стандарте SQL.

10.3.4. Набор символов и объединение столбца

MySQL выбирает набор символов столбца и объединение следующим способом:

Иначе, используется набор символов и объединение таблицы.

Предложения CHARACTER SET и COLLATE стандартны для SQL.

10.3.5. Набор символов и объединение символьных строковых литералов

Каждый символьный строковый литерал имеет набор символов и объединение.

Символьный строковый литерал может иметь факультативный набор символов и предложение COLLATE :

MySQL определяет набор символов литерала и объединение следующим способом:

Строка с набором символов latin1 и объединением latin1_german1_ci :

Строка с набором символов latin1 и заданным по умолчанию объединением (то есть, latin1_swedish_ci ):

Строка с набором символов и объединением по умолчанию подключения:

Набор символов и предложение COLLATE выполнены согласно стандарту SQL

10.3.6. Национальный набор символов

Стандарт SQL определяет NCHAR или NATIONAL CHAR как способ указать, что столбец CHAR должен использовать некоторый предопределенный набор символов. MySQL 5.1 использует utf8 как этот предопределенный набор символов. Например, эти объявления типа данных эквивалентны:

Эти тоже взаимозаменяемы:

10.3.7. Примеры назначения набора символов и объединения

Следующие примеры показывают, как MySQL определяет заданные по умолчанию набор символов и объединение.

Пример 1: определение таблицы и столбца

Пример 2: определение таблицы и столбца

Пример 3: определение таблицы и столбца

Пример 4: определение базы данных, таблицы и столбца

10.3.8. Совместимость с другими СУБД

Для совместимости с MaxDB эти две инструкции те же самые:

10.4. Наборы символов и объединения подключения

Несколько переменных системы для наборов символов и объединений касаются взаимодействия пользователя с сервером. Некоторые из них были упомянуты в более ранних разделах:

Дополнительный набор символов и объединения переменные системы включаются в трафике обработки для подключения. Каждый пользователь имеет связанные с подключением переменные системы набора символов и объединения.

Когда Вы соединяетесь с сервером, клиент посылает инструкции SQL. Сервер посылает ответы, типа наборов результатов, обратно пользователю. Это ведет к нескольким вопросам относительно набора символов и обработки объединения для подключений пользователя, каждому из которых можно отвечать в терминах переменных системы:

В каком наборе символов является инструкция от пользователя?

В какой набор символов сервер должен транслировать инструкцию после получения?

К какому набор символов сервер должен транслировать данные перед пересылкой наборов результатов или сообщений об ошибках обратно пользователю?

Переменная системы character_set_results указывает набор символов, в котором сервер возвращает результаты запроса пользователю. Это включает данные результата типа значений столбца, и метаданных результата типа имени столбца.

Вы можете подстраивать параметры настройки для этих переменных или зависеть от значений по умолчанию (тогда Вы можете пропустить остальную часть этого раздела).

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

Инструкция SET NAMES ‘ x ‘ эквивалентна этим трем инструкциям:

Установка collation_connection также устанавливает character_set_connection к набору символов, связанному с объединением (эквивалент выполнения SET character_set_connection = @@character_set_database ).

Если Вы не хотите, чтобы сервер выполнил любое преобразование наборов результатов, установите character_set_results в NULL :

Обратите внимание : в настоящее время UCS-2 не может использоваться как набор символов пользователя, это означает, что SET NAMES ‘ucs2’ не работает.

Чтобы видеть значения переменных системы набора символов и объединения, которые обращаются к Вашему подключению, используйте эти инструкции:

10.5. Проблемы объединения

Следующие разделы излагают различные аспекты объединений набора символов.

10.5.1. Использование COLLATE в SQL-инструкциях

С предложением COLLATE Вы можете отменять любое заданное по умолчанию объединение для сравнения. COLLATE может использоваться в различных частях инструкций SQL. Имеются некоторые примеры:

С агрегатными функциями:

10.5.2. Старшинство предложения COLLATE

Предложение COLLATE имеет высокое старшинство (выше, чем || ), так следующие два выражения эквивалентны:

10.5.3. Оператор BINARY

Оператор BINARY приводит строку после него к двоичной строке. Это простой способ вынудить сравнение быть выполненным байт в байт, а не символ в символ. BINARY также заставляет конечные пробелы быть значительными.

Эффект BINARY как атрибута столбца отличается от эффекта до MySQL 4.1. Прежде BINARY помечал столбец, который обрабатывался как двоичная строка, то есть строка байтов, которая не имеет никакого набора символов или объединения, что отличается от не двоичной символьной строки, которая имеет двоичное объединение. Для обоих типов строк сравнения основаны на числовых значениях строкового модуля, но для не двоичных строк, модулем является символ, и некоторые наборы символов позволяют многобайтовые символы.

10.5.4. Некоторые специальные случаи, где определение объединения сложно

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

Однако, когда включаются многократные операнды, может иметься неоднозначность. Например:

Явное предложение COLLATE имеет 0 (не имеет coercible вообще).

Конкатенация двух строк с различными объединениями имеет coercibility 1.

Объединение столбца, сохраненного стандартного параметра или локальной переменной имеет coercibility 2.

Константа системы (строка, возвращенная функциями типа USER() или VERSION() ) имеет coercibility 3.

Объединение литерала имеет coercibility 4.

Предшествующие значения coercibility текущие для MySQL 5.1.

Эти правила решают неоднозначности следующим способом:

Используют объединение с самым низким значение coercibility.

Если обе стороны имеют тот же самый coercibility, то это ошибка, если объединения не те же самые.

Функция COERCIBILITY() может использоваться, чтобы определить coercibility строкового выражения:

10.5.5. Объединения должны быть для правильного набора символов

Каждый набор символов имеет одно или большее количество объединений, но каждое объединение связано с одним и только одним набором символов. Следовательно, следующая инструкция вызывает сообщение об ошибке, потому что объединение latin2_bin не допустимо с набором символов latin1 :

10.5.6. Пример эффекта объединения

Предположите, что столбец X в таблице T имеет эти значения столбца latin1 :

Предположите также, что значения столбца получены, используя следующую инструкцию:

Следующая таблица показывает возникающий в результате порядок значений, если мы используем ORDER BY с различными объединениями:

Символ, который вызывает различные порядки сортировки в этом примере: U с двумя точками сверху, который в Германии известен как U-umlaut.

10.6. Операции, на которые воздействует поддержка набора символов

Этот раздел описывает операции, которые берут во внимание информацию о наборе символов.

10.6.1. Строки результата

MySQL имеет много операторов и функций, которые возвращают строку. Этот раздел отвечает на вопрос: каков набор символов и объединение у такой строки?

Для операций, которые объединяют многостроковые вводы и возвращают одиночный строковый вывод, правила соединения частей стандарта SQL дают определение объединения результата:

Иначе, результат не имеет никакого объединения вообще.

10.6.2. CONVERT() и CAST()

CONVERT() обеспечивает способ преобразовать данные между различными наборами символов. Синтаксис:

В MySQL имена перекодировки такие же, как соответствующие имена наборов символов.

10.6.3. Инструкции SHOW и INFORMATION_SCHEMA

Если никакое предложение COLLATE не показывается, заданное по умолчанию объединение для набора символов применяется.

Набор символов не отображается, но подразумевается именем объединения.

10.7. Поддержка Unicode

MySQL 5.1 поддерживает два набора символов для сохранения данных Unicode:

В настоящее время UCS-2 не может использоваться как набор символов пользователя, это означает, что SET NAMES ‘ucs2’ не работает.

UTF-8 (трансформируемое представление Unicode) представляет собой альтернативный способ сохранить Unicode данные. Это выполнено согласно RFC 3629. Идея относительно UTF-8 состоит в том, что различные символы Unicode, используя последовательности байтов различных длин:

Базисные латинские символы, цифры и пунктуация используют один байт.

Большинство европейских и ближневосточных символов вписываются в двухбайтовую последовательность: расширенные латинские символы (с тильдой, апострофом, острые, умлауты и другие диакритические знаки), кириллица, греческие, армянские, еврейские, арабские, сирийские и прочие.

Корейские, китайские и японские иероглифы использует трехбайтовые последовательности.

RFC 3629 описывает последовательности кодирования, которые берут от одного до четырех байтов. В настоящее время MySQL-поддержка для UTF-8 не включает последовательности с четырьмя байтами. Старый стандарт для кодирования UTF-8 задан RFC 2279 и описывает UTF-8-последовательности, которые берут от одного до шести байтов. RFC 3629 объявляет RFC 2279 устаревшим, по этой причине последовательности с пятью и шестью байтами больше не используются.

10.8. UTF-8 для метаданных

Представление метаданных должно удовлетворять эти требованиям:

Метаданные должны включить все символы во все языки. Иначе пользователи не способны называть столбцы и таблицы, использующие их собственные языки.

Чтобы удовлетворять обоим требованиям, MySQL сохраняет метаданные в наборе символов Unicode, а именно в UTF-8. Это не вызывает никаких сбоев, если Вы никогда не используете не латинские или символы с диакритическим знаком. Но если Вы это делаете, Вы должны знать, что метаданные находятся в UTF-8.

Сервер устанавливает переменную системы character_set_system к имени набора символов метаданных:

Сообщения об ошибках, возвращенные сервером, преобразованы в набор символов пользователя автоматически, как в случае с метаданными.

Если Вы используете (например) функцию USER() для сравнения или назначения внутри одиночной инструкции, можете не волноваться. MySQL выполняет автоматическое преобразование для Вас.

Это работает потому, что содержание latin1_column автоматически преобразовано в UTF-8 перед сравнением.

Это работает потому, что содержание USER() автоматически преобразовано в latin1 перед назначением. Автоматическое преобразование полностью все же не выполнено, но должно работать правильно в более поздней версии.

Хотя автоматическое преобразование не в SQL стандарте, документ SQL-стандарта говорит, что каждый набор символов (в терминах обеспечиваемых символов) подмножество Unicode. Поэтому объединение для Unicode может применяться для сравнения с не-Unicode строками.

10.9. Преобразование набора символов столбца

Преобразование может быть с потерями, если столбец содержит символы, которые не содержатся в обоих наборах символов.

Следующий шаг должен преобразовать столбец в не двоичный тип данных с соответствующим набором символов:

10.10. Наборы символов и объединения, которые поддерживает MySQL

MySQL поддерживает свыше 70 объединений для более 30 наборов символов. Этот раздел указывает, которые наборы символов MySQL поддерживает. Имеется один подраздел для каждой группы связанных наборов символов. Для каждого набора символов, перечислены допустимые объединения.

Вы можете всегда вносить в список доступные наборы символов и их заданные по умолчанию объединения инструкцией SHOW CHARACTER SET :

10.10.1. Наборы символов Unicode

MySQL имеет два набора символов Unicode. Вы можете сохранять текст приблизительно для 650 языков, используя эти наборы символов.

Объединения ucs2 (UCS-2 Unicode):

Объединения utf8 (UTF-8 Unicode):

Объединения ucs2_hungarian_ci и utf8_hungarian_ci были добавлены в MySQL 5.1.5.

В настоящее время объединение utf8_unicode_ci имеет только частичную поддержку для Unicode Collation Algorithm. Некоторые символы все же не обеспечиваются. Также полностью не обеспечивается объединение меток. Это воздействует прежде всего на вьетнамский и некоторые малораспространенные языки в России, типа Udmurt, Tatar, Bashkir и Mari.

Например, следующие равенства верны в utf8_general_ci и в utf8_unicode_ci :

Различие между объединениями: это является истинным для utf8_general_ci :

В то время, как это истинно для utf8_unicode_ci :

MySQL осуществляет специфические для языка объединения для набора символов utf8 только, если упорядочение с utf8_unicode_ci не работает хорошо для языка. Например, utf8_unicode_ci работает прекрасно для German и French, а значит нет никакой потребности создавать специальные объединения utf8 для этих двух языков.

10.10.2. Западноевропейские наборы символов

Западноевропейские наборы символов покрывают большинство западноевропейских языков, типа French, Spanish, Catalan, Basque, Portuguese, Italian, Albanian, Dutch, German, Danish, Swedish, Norwegian, Finnish, Faroese, Icelandic, Irish, Scottish и English.

Объединения ascii (US ASCII):

ascii_general_ci (значение по умолчанию)

Объединения cp850 (DOS West European):

cp850_general_ci (значение по умолчанию)

Объединения dec8 (DEC Western European):

dec8_swedish_ci (значение по умолчанию)

Объединения hp8 (HP Western European):

hp8_english_ci (значение по умолчанию)

Объединения latin1 (cp1252 West European):

latin1_swedish_ci (значение по умолчанию)

Объединение latin1_swedish_ci это значение по умолчанию, которое, вероятно, используется большинством заказчиков MySQL. Хотя часто скажется, что это основано на правилах объединения Swedish/Finnish, имеются шведы и финны, кто не соглашаются с этой инструкцией.

Правила latin1_german1_ci (словарного):

Правила latin1_german2_ci (телефонного справочника):

Объединения macroman (Mac West European):

macroman_general_ci (значение по умолчанию)

Объединения swe7 (7bit Swedish):

swe7_swedish_ci (значение по умолчанию)

10.10.3. Центральноевропейские наборы символов

MySQL обеспечивает поддержку для наборов символов, используемых в Czech Republic, Slovakia, Hungary, Romania, Slovenia, Croatia и Poland.

Объединения cp1250 (Windows Central European):

cp1250_general_ci (значение по умолчанию)

Объединения cp852 (DOS Central European):

cp852_general_ci (значение по умолчанию)

Объединения keybcs2 (DOS Kamenicky Czech-Slovak):

keybcs2_general_ci (значение по умолчанию)

Объединения latin2 (ISO 8859-2 Central European):

latin2_general_ci (значение по умолчанию)

Объединения macce (Mac Central European):

macce_general_ci (значение по умолчанию)

10.10.4. Южноевропейские и ближневосточные наборы символов

Южныоевропейские и ближневосточные наборы символов, обеспечиваемые MySQL, включают Armenian, Arabic, Georgian, Greek, Hebrew и Turkish.

Объединения armscii8 (ARMSCII-8 Armenian):

armscii8_general_ci (значение по умолчанию)

Объединения cp1256 (Windows Arabic):

cp1256_general_ci (значение по умолчанию)

Объединения geostd8 (GEOSTD8 Georgian):

geostd8_general_ci (значение по умолчанию)

Объединения greek (ISO 8859-7 Greek):

greek_general_ci (значение по умолчанию)

Объединения hebrew (ISO 8859-8 Hebrew):

hebrew_general_ci (значение по умолчанию)

Объединения latin5 (ISO 8859-9 Turkish):

latin5_turkish_ci (значение по умолчанию)

10.10.5. Балтийские наборы символов

Балтийские наборы символов охватывают Estonian, Latvian и Lithuanian.

Объединения cp1257 (Windows Baltic):

cp1257_general_ci (значение по умолчанию)

Объединения latin7 (ISO 8859-13 Baltic):

latin7_general_ci (значение по умолчанию)

10.10.6. Наборы символов кириллицы

Наборы символов и объединения кириллицы для использования с Belarusian, Bulgarian, Russian и Ukrainian.

Объединения cp1251 (Windows Cyrillic):

cp1251_general_ci (значение по умолчанию)

Объединения cp866 (DOS Russian):

cp866_general_ci (значение по умолчанию)

Объединения koi8r (KOI8-R Relcom Russian):

koi8r_general_ci (значение по умолчанию)

Объединения koi8u (KOI8-U Ukrainian):

koi8u_general_ci (значение по умолчанию)

10.10.7. Азиатские наборы символов

Азиатские наборы символов, которые поддерживает пакет, включают Chinese, Japanese, Korean и Thai. Они могут быть усложнены. Например, китайские наборы должны учесть тысячи различных символов.

Объединения big5 (Big5 Traditional Chinese):

big5_chinese_ci (значение по умолчанию)

Объединения cp932 (SJIS for Windows Japanese):

cp932_japanese_ci (значение по умолчанию)

Объединения eucjpms (UJIS for Windows Japanese):

eucjpms_japanese_ci (значение по умолчанию)

Объединения euckr (EUC-KR Korean):

euckr_korean_ci (значение по умолчанию)

Объединения gb2312 (GB2312 Simplified Chinese):

gb2312_chinese_ci (значение по умолчанию)

Объединения gbk (GBK Simplified Chinese):

gbk_chinese_ci (значение по умолчанию)

Объединения sjis (Shift-JIS Japanese):

sjis_japanese_ci (значение по умолчанию)

Объединения tis620 (TIS620 Thai):

tis620_thai_ci (значение по умолчанию)

Объединения ujis (EUC-JP Japanese):

ujis_japanese_ci (значение по умолчанию)

10.10.7.1. Набор символов cp932

В MySQL набор символов sjis соответствует Shift_JIS определенному IANA, который поддерживает символы JIS X0201 и JIS X0208 (см. http://www.iana.org/assignments/character-sets).

Много японских пользователей испытали проблемы при использовании этих символов расширения. Эта проблема складывается из следующих факторов:

MySQL автоматически преобразовывает наборы символов.

Наборы символов преобразованы через Unicode ( ucs2 ).

Набор символов sjis не поддерживает преобразование этих символов расширения.

Имеются несколько правил преобразования из так называемого SHIFT JIS в Unicode, и некоторые символы преобразованы в Unicode по-другому, в зависимости от правила преобразования. MySQL поддерживает только одно из этих правил.

Набор символов MySQL cp932 разработан, чтобы решить эти проблемы.

Поскольку MySQL поддерживает преобразование набора символов, важно отделить IANA Shift_JIS от cp932 : это два различных набора символов, потому что они обеспечивают разные правила преобразования.

Набор символов cp932 отличается от sjis следующим:

cp932 поддерживает специальные и избранные символы NEC, а также расширенные символы от IBM.

Некоторые символы в cp932 имеют два различных кода, оба из которых преобразовываются в ту же самую Unicode-метку. При преобразовании из Unicode обратно в cp932 один из кодов должен быть выбран. Для этого используется правило, рекомендуемое Microsoft (подробности на http://support.microsoft.com/kb/170559/EN-US/).

Правило преобразования работает примерно так:

Если символ находится в JIS X 0208 и в специальных символах NEC, применяется код из JIS X 0208.

Если символ находится в специальных символах NEC и в расширенных символах IBM, применяется код из специальных символов NEC.

Если символ находится в избранных символах IBM и в расширенных символах IBM, применяется код из расширенных символов IBM.

Следующие ссылки имеют особый интерес. Они соответствуют кодированию для следующих наборов символов:

Специальные символы NEC:

Избранные NEC расширенные символы IBM:

Избранные символы IBM:

Преобразование в ucs2 :

Преобразование из ucs2 :

10.11. MySQL 5 FAQ: поддержка наборов символов CJK

Этот набор вопросов происходит из опыта поддержки MySQL в обработке запросов относительно проблем кириллицы и CJK (Chinese-Japanese-Korean).

Эта проблема обычно из-за установки в MySQL, который не соответствует параметрам настройки для прикладной программы или операционной системы. Имеются некоторые общие шаги для исправления этих типов проблем:

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

Используйте программу пользователя mysql (в Windows: mysql.exe ), чтобы выполнить эту задачу. Если mysql отображает все правильно, но Ваша прикладная программа этого не делает, то проблема, вероятно, из-за параметров настройки системы.

Чтобы выяснять, каковы Ваши параметры настройки, используйте инструкцию SHOW VARIABLES вывод которой должен походить на то, что показывается здесь:

Это типичные параметры настройки набора символов для международно-ориентируемого пользователя (обратите внимание на использование utf8 Unicode), связанного с сервером на западе ( latin1 является набором символов западной Европы и значением по умолчанию для MySQL).

Хотя Unicode (обычно вариант utf8 на Unix и ucs2 в Windows) предпочтителен для Latin, это часто не то, что Ваши утилиты операционной системы поддерживают лучше всего. Много пользователей Windows находят, что набор символов Microsoft, типа cp932 для Japanese Windows, подходит им лучше.

Также возможно, что имеются проблемы с установкой конфигурации API, используемой в вашей прикладной программе.

10.11.2: Какие китайские (GB) наборы символов понимает MySQL?

Для получения распечатки MySQL-символов gbk см. http://d.udm.net/bar/

10.11.3: Какие проблемы я должен знать при работе с китайским набором символов Big5?

10.11.4: Почему японские преобразования набора символов терпят неудачу?

Теперь рассмотрите эту часть таблицы:

10.11.6: Как MySQL представляют знак Yen ( ┬е )?

Проблема возникает потому, что некоторые версии японских наборов символов ( sjis и euc ) обрабатывают 5C как reverse solidus ( \ он же backslash), а другие обрабатывают это как знак йены ( ┬е ).

10.11.7: MySQL планирует делать отдельный набор символов, где 5C представляет знак йены?

Это одно из возможных решений для проблемы знака йены, однако, это не будет в MySQL 5.1 или 5.2.

10.11.8: Какие проблемы я должен знать при работе с корейскими наборами символов в MySQL?

В теории, хотя есть несколько версий набора символов euckr ( Extended Unix Code Korea), только одна проблема была отмечена.

Графическая корейская диаграмма MySQL здесь: http://d.udm.net/bar/

10.11.9: Почему я получаю сообщения об ошибке » Data truncated «?

Для иллюстрации мы создадим таблицу с одним столбцом Unicode ( ucs2 ) и другим Chinese ( gb2312 ):

Мы пробуем помещать редкий символ ц▒М в обоих столбцах:

Имеется предупреждение. Давайте посмотрим, что там случилось:

Имеются несколько вещей, которые надлежит понять здесь:

По общему признанию сообщение вводит в заблуждение. В этом случае не было никакого усечения: а произошла тривиальная замена символа на вопросительный знак. Авторы уже имели недовольство относительно этого сообщения (см. Глюк #9337 ). Но пока они придумывают кое-что получше, имейте в виду что сообщение 2165 может означать ряд вещей.

10.11.10: Почему мой внешний GUI-интерфейс или окно просмотра не отображает символы CJK правильно в моей прикладной программе, использующей Access, PHP или другой API?

Аналогичным способом, если Вы используете любой набор символов, другой, чем latin1 с Connector/NET, Вы должны определить набор символов в строке подключения. Если Вы используете PHP, опробуйте это:

10.11.11: Я обновился до MySQL 5.1. Как я могу возвращаться к поведению, аналогичному MySQL 4.0, относительно наборов символов?

Например, предположите, что Ваш любимый набор символов сервера latin1 (вряд ли это так в области CJK, но это значение по умолчанию). Предположите далее, что пользователь использует utf8 потому, что операционная система пользователя поддерживает. Теперь запустите сервер с latin1 как заданный по умолчанию набор символов:

Затем запустите пользователя с заданным по умолчанию набором символов utf8 :

Текущие параметры настройки могут быть выяснены, рассматривая вывод SHOW VARIABLES :

Запустите пользователя с utf8 еще раз как заданный по умолчанию набор символов, а затем отобразите текущие параметры настройки:

10.11.12: Почему некоторые LIKE и поиск FULLTEXT с символами CJK срываются?

Это одна причина, почему MySQL не может позволять кодирование несуществующих символов. Если это не строго относительно отклонения, то не имеется никакого способа узнавать, где символы заканчиваются.

Для поисков FULLTEXT мы должны знать, где слова начинаются и заканчиваются. С западными языками это редко проблема, потому что большинство (если не все) они используют пробел, чтобы идентифицировать конец слова. Однако, это не так с азиатской записью.

10.11.13: Какие наборы символов CJK доступны в MySQL?

10.11.14: Как я узнаю, является ли символ X доступным во всех наборах символов?

Большинство упрощеннных китайских и японских символов Kana появляются во всех CJK-наборах символов. Эта сохраненная процедура принимает символ UCS-2 Unicode, преобразует это во все другие наборы символов и отображает результаты в шестнадцатеричном формате.

10.11.15: Почему CJK-строки не сортируются правильно в Unicode? (I)

Теперь мы ищем 304B и 304C в таблице 4.0.0 allkeys и находим эти строки:

10.11.16: Почему CJK-строки не сортируются правильно в Unicode? (дополнение)

Если Вы используете Unicode ( ucs2 или utf8 ) и Вы знаете порядок сортировки Unicode, но MySQL все еще сортирует Вашу таблицу неправильно, то Вы должны сначала проверить набор символов таблицы:

Так как набор символов правильный, давайте посмотрим то, какую информацию таблица INFORMATION_SCHEMA.COLUMNS может обеспечивать относительно этого столбца:

10.11.17: Почему мои дополнительные символы отклонены MySQL?

Нет. Термин CJKV ( Chinese Japanese Korean Vietnamese) обращается к вьетнамским наборам символов, которые содержат Han (изначально китайские) символы. MySQL не имеет никакого плана, чтобы поддерживать старый вьетнамский вариант, использующий символы Han. MySQL поддерживает современный вьетнамский вариант с символами Western.

Глюк #4745 просьба о специализированном вьетнамском объединении, которое может быть добавлено в будущем, если имеется достаточная потребность в этом.

10.11.19: MySQL позволяет символам CJK использоваться в именах баз данных и таблиц?

Эта проблема отфиксирована в MySQL 5.1, автоматически переписывая имена соответствующих каталогов и файлов.

10.11.20: Где я могу находить переводы руководства по MySQL на китайский, корейский и японский языки?

Упрощенная китайская версия руководства для MySQL 5.1.12 может быть найдена на http://dev.mysql.com/doc/#chinese-5.1. Японская для MySQL 4.1 может быть получена с http://dev.mysql.com/doc/#japanese-4.1.

10.11.21: Где я могу получать справку по CJK и связанным проблемам в MySQL?

Следующие ресурсы доступны:

Перечень групп пользователей MySQL может быть найден на http://dev.mysql.com/user-groups/.

Вы можете входить в контакт с инженером сбыта в MySQL KK Japan:

Источник