Cyrillic general ci as что за кодировка

А какая разница какой 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 по умолчанию точно неверен. К сожалению, такие нюансы редко видны на старте проекта при проектировании системы, но, надеюсь, прочитав статью, Вы вспомните об описанной ситуации и не наступите на подобные грабли сами.

Источник

Разница между collation Cyrillic_General и Cyrillic_General_100

Устанавливаю SQL Server 2016 Express Edition на Windows 2016 Server, хотел выбрать кириллическую collation, однако их находится две: Cyrillic_General и Cyrillic_General_100

В чём между ними разница? Сомневаюсь в выборе. Вижу, что почти все сопоставления имеют два варианта (со _100 и без), что это значит и для чего нужно?

2 ответа 2

Cyrillic_General и Cyrillic_General_100
В чём между ними разница?

Насколько я исследовал этот вопрос, символы русского алфавита (А-Я, а-я), а также символы латинского алфавита, цифры и знаки (с кодами 0x0020-0x007E) и в Cyrillic_General и в Cyrillic_General_100 обрабатываются одинаково. Однако есть разница для кириллических символов не используемых в русском языке.

Также в Cyrillic_General буквы Ѐ и ѐ не преобразуются корректно к противоположному регистру, тогда как в Cyrillic_General_100 преобразование регистра для них корректное:

Есть разница и для некоторых других кириллических символов (и для не кириллических тоже).

Обратите внимание также, что при установке задаётся collation инстанса. Для создаваемых в последствие баз данных всегда можно указать любой другой нужный collation (если не указать, то БД будет создана с collation инстанса). Поэтому, если вы не используете символы русского алфавита в названиях баз данных, логинов, серверных ролей и прочих instance-scope вещах, то, в принципе, можете выбрать даже и Latin1_General_100.

Источник

Имя параметров сортировки Windows (Transact-SQL)

Задает имя параметров сортировки Windows с помощью предложения COLLATE в SQL Server. Имя параметра сортировки Windows состоит из двух частей: обозначения параметров сортировки и стиля сравнения.

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

Синтаксис

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

Аргументы

CollationDesignator
Указывает базовые параметры сортировки, используемые параметрами сортировки Windows. Правила базовых параметров сортировки отвечают за следующее.

CaseSensitivity
CI указывает, что регистр символов не учитывается, CS определяет учет регистра.

AccentSensitivity
AI означает, что диакритические знаки пропускаются, AS показывает, что они учитываются.

KanatypeSensitive
Пропуск этого параметра означает, что тип японской азбуки не учитывается, KS означает, что тип японской азбуки учитывается.

WidthSensitivity
Пропуск этого параметра означает, что ширина символов не учитывается, WS означает, что ширина символов учитывается.

Область применения: Начиная с SQL Server 2017 (14.x);

Пропуск этого параметра означает, что знаки выбора варианта не учитываются, VSS означает, что знаки выбора варианта учитываются.

UTF8

Область применения: Начиная с SQL Server 2019 (15.x)

Указывает кодировку UTF-8, используемую для допустимых типов данных. Дополнительные сведения см. в статье Collation and Unicode Support.

BIN
Указывает подлежащий использованию двоичный порядок сортировки, применяющийся для обеспечения обратной совместимости.

BIN2
Определяет двоичный порядок сортировки, использующий семантику сравнения кодовых точек.

Комментарии

Первая инструкция выводит как прописную, так и строчную форму символа в предыдущей версии параметров сортировки (параметры сортировки не влияют на доступность символов при работе с данными в Юникоде). Однако вторая инструкция возвращает прописную букву для параметров сортировки Latin1_General_CI_AS, так как в них не определено соответствие со строчной буквой для этой кодовой точки.

При работе с некоторыми языками, может быть крайне необходимым избегать прошлых сортировок. Например, это является верным для Telegu.

В некоторых случаях сортировки Windows и сортировки службы SQL Server могут создать разные планы запросов для одного и того же запроса.

Примеры

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

Latin1_General_100_CI_AS

Параметры сортировки используют правила сортировки словаря Latin1 General и ставят в соответствие кодовую страницу 1252. Это параметры сортировки версии _100 без учета регистра (CI) и с учетом диакритических знаков (AS).

Estonian_CS_AS

Параметры сортировки используют правила сортировки словаря Estonian и сопоставлены с кодовой страницей 1257. Это параметры сортировки версии _80 (на что указывает отсутствие номера версии в имени) с учетом регистра (CI) и диакритических знаков (AS).

Japanese_Bushu_Kakusu_140_BIN2

Параметры сортировки используют правила сортировки двоичной кодовой точки и сопоставлены с кодовой страницей 932. Это правила сортировки версии _140; правила сортировки словаря Japanese Bushu Kakusu не учитываются.

Параметры сортировки Windows

Чтобы сформировать список параметров сортировки Windows, которые поддерживаются экземпляром SQL Server, выполните следующий запрос.

В следующей таблице приведены все параметры сортировки Windows, поддерживаемые в SQL Server.

1 Параметры сортировки Windows «Только для Юникода» можно применять только к данным на уровне столбца или уровне выражения. Они не могут использоваться в качестве параметров сортировки базы данных или сервера.

2 Как и при параметрах сортировки в китайском (Тайвань), в китайском (Макао) используются правила упрощенного китайского языка, но в отличие от китайского (Тайвань) используется кодовая страница 950.

Источник

Поддержка параметров сортировки и Юникода

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

Независимо от того, устанавливается ли новый экземпляр SQL Server, восстанавливается ли база данных из резервной копии или сервер соединяется с клиентскими базами данных, важно понимать требования к языковому стандарту, знать порядок сортировки и необходимость учета регистра или диакритических знаков в данных, с которыми вы работаете. Описание того, как получить список доступных параметров сортировки в экземпляре SQL Server, см. в статье sys.fn_helpcollations (Transact-SQL).

Для эффективного использования поддержки параметров сортировки в SQL Serverнеобходимо понимать термины, представленные в этой статье, и их связь с характеристиками данных.

Термины, связанные с параметрами сортировки

Параметры сортировки

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

Результат выполнения инструкцииTransact-SQL может различаться в зависимости от контекста различных баз данных, которые имеют свои параметры сортировки. По возможности используйте стандартные параметры сортировки для всей организации. Тем самым не придется указывать параметры сортировки для каждого символа или выражения Юникода. Если необходимо работать с объектами, имеющими различные параметры сортировки и кодовые страницы, создание запросов должно производиться с учетом очередности параметров сортировки. Дополнительные сведения см. в разделе Очередность параметров сортировки (Transact-SQL).

Параметры сортировки могут учитывать регистр, диакритические знаки, тип японской азбуки, ширину символов и знаки выбора варианта. В SQL Server 2019 (15.x) появился дополнительный параметр для кодирования UTF-8.

Эти параметры можно задать путем их добавления к имени параметров сортировки. Например, параметр Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 определяет параметры сортировки с учетом диакритических знаков, регистра, типа японской азбуки, ширины символов и кодировки UTF-8. Еще один пример: параметр Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS определяет параметры сортировки без учета регистра, без учета диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов, с учетом знаков выбора варианта и с использованием кодировки не в Юникоде.

В приведенной ниже таблице описывается режим работы, связанный с этими параметрами.

1 Если выбран порядок сортировки BIN или BIN2, параметры с учетом регистра (_CS), диакритических знаков (_AS), типа японской азбуки (_KS) и ширины символов (_WS) недоступны.

Примеры параметров сортировки

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

1 Если выбран порядок сортировки BIN или BIN2, параметры с учетом регистра (_CS), диакритических знаков (_AS), типа японской азбуки (_KS) и ширины символов (_WS) недоступны.

2 Добавление параметра UTF-8 (_UTF8) позволяет кодировать данные в Юникоде с использованием UTF-8. Дополнительные сведения см. в разделе Поддержка UTF-8 в этой статье.

Наборы параметров сортировки

SQL Server поддерживает следующие наборы параметров сортировки:

Параметры сортировки Windows

Параметры сортировки Windows определяют правила хранения символьных данных на основе соответствующего языкового стандарта системы Windows. Для параметров сортировки Windows сравнение данных в формате, отличном от Юникода, можно реализовать с помощью такого же алгоритма, как и для данных в Юникоде. Базовые правила параметров сортировки Windows задают алфавит или язык, используемый при сортировке по словарю. Кроме того, они определяют кодовую страницу, используемую для хранения символьных данных не в Юникоде. Сортировка в Юникоде и в других форматах совместима со строковым сравнением в соответствующей версии Windows. Тем самым обеспечивается согласованность обработки различных типов данных в SQL Server, а разработчики получают возможность сортировать строки в приложениях по тем же правилам, что и в SQL Server. Дополнительные сведения см. в статье Имя параметров сортировки Windows (Transact-SQL).

Параметры двоичной сортировки

При двоичных параметрах сортировки данные сортируются на основе последовательности закодированных значений, определяемых локалью и типом данных. Эти параметры учитывают регистр. Параметры двоичной сортировки в SQL Server определяют используемый языковой стандарт и кодовую страницу ANSI. При этом принудительно реализуется двоичный порядок сортировки. По причине своей относительной простоты параметры двоичной сортировки помогают повысить производительность приложений. Для типов данных не в Юникоде сравнение данных производится на основе кодовых точек, определенных в кодовой странице ANSI. Типы данных в Юникоде сравниваются на основе элементов кода Юникода. Для параметров двоичной сортировки на основе типов данных Юникода при сортировке данных языковой стандарт не учитывается. Например, параметры сортировки Latin_1_General_BIN и Japanese_BIN дают одинаковые результаты сортировки, если используются с данными в Юникоде. Дополнительные сведения см. в статье Имя параметров сортировки Windows (Transact-SQL).

В SQL Server имеются два типа параметров двоичной сортировки.

Прежние параметры двоичной сортировки BIN, которые выполняли неполное сравнение кодовых точек для данных в Юникоде. Эти параметры двоичной сортировки сравнивали первые символы как тип данных WCHAR, а затем следовало побитовое сравнение. При использовании параметров сортировки BIN только первый символ сортируется в соответствии с кодовой точкой. Остальные символы сортируются в соответствии с их значениями байта.

Новые параметры сортировки BIN2, которые выполняют сравнение исключительно кодовых точек. При использовании параметров сортировки BIN2 все символы сортируются в соответствии с их кодовыми точками. Так как платформа Intel не всегда является архитектурой по порядку следования байтов, символы кода Unicode всегда хранятся с перестановкой байтов.

Параметры сортировки SQL Server

Параметры сортировки SQL Server (SQL_*) имеют обратную совместимость с более ранними версиями SQL Server, с точки зрения порядка сортировки. Правила сортировки словаря для данных в формате, отличном от Юникода, не совместимы ни с какими подпрограммами сортировки операционных систем Windows. Однако сортировка данных в Юникоде совместима с правилами сортировки определенной версии Windows. Так как параметры сортировки SQL Server применяют для данных в Юникоде и других форматах разные правила сравнения, при сравнении одних и тех же данных получаются разные результаты, которые зависят от базового типа данных. Дополнительные сведения см. в статье Имя параметров сортировки SQL Server (Transact-SQL).

Во время установки SQL Server параметры сортировки по умолчанию определяются языковым стандартом операционной системы. Параметры сортировки уровня сервера можно изменить в процессе установки. Кроме того, их можно изменить, сменив языковой стандарт ОС перед установкой. В целях обратной совместимости для параметров сортировки по умолчанию устанавливается самая старая доступная версия, связанная с определенным языковым стандартом. В связи с этим данные параметры сортировки рекомендуется использовать не во всех случаях. Для использования всех возможностей SQL Server следует изменить параметры установки по умолчанию для параметров сортировки Windows. Например, для языкового стандарта ОС «Английский (США)» (кодовая страница 1252) параметры сортировки по умолчанию во время установки — SQL_Latin1_General_CP1_CI_AS. Их можно изменить на ближайший аналог в Windows Latin1_General_100_CI_AS_SC.

При обновлении англоязычной версии экземпляра SQL Server можно задать параметры сортировки SQL Server (SQL_*), чтобы обеспечить совместимость с существующими экземплярами SQL Server. Так как для экземпляра SQL Server параметры сортировки по умолчанию определяются во время установки, очень важно правильно настроить параметры сортировки в следующих случаях:

Уровни параметров сортировки

Настройка параметров сортировки поддерживается на следующих уровнях экземпляра SQL Server.

Параметры сортировки уровня сервера

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

В приведенной ниже таблице представлены параметры сортировки по умолчанию, определяемые языковым стандартом операционной системы (ОС), включая коды языков (LCID) в Windows и SQL.

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

Запрос всех доступных на сервере параметров сортировки выполняется с помощью следующей встроенной функции fn_helpcollations() :

Параметры сортировки уровня базы данных

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

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

Параметры сортировки пользовательской базы данных можно изменить с помощью инструкции ALTER DATABASE следующим образом:

Источник