Поддержка сопоставления и Unicode

Применимо к:SQL ServerБаза данных Azure SQLУправляемый экземпляр Azure SQLAzure Synapse AnalyticsСистема платформы аналитики (PDW)Конечная точка SQL аналитики в Microsoft FabricХранилище в Microsoft FabricБаза данных SQL в Microsoft Fabric

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

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

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

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

Термины сравнения

• Collation
  • Наборы параметров сортировки
  • Уровни сортировки
• Locale
• Кодовая страница
• Порядок сортировки

Collation

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

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

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

Эти параметры можно задать путем их добавления к имени параметров сортировки. Например, сортировка Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 чувствительна к регистру, к акцентам, к кана, к ширине и использует кодировку UTF-8. В качестве другого примера параметры сортировки Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS являются нечувствительными к регистру, нечувствительными к символам, kana-sensitive, width-selector-sensitive, и он использует устаревшую кодовую страницу для varchar.

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

Option	Description
Учет регистра (_CS)	Различаются буквы верхнего и нижнего регистров. При выборе этого параметра буквы нижнего регистра при сортировке ставятся перед соответствующими буквами верхнего регистра. Если этот параметр не выбран, сортировка не учитывает регистр. То есть при сортировке SQL Server считает буквы верхнего и нижнего регистров идентичными друг другу. Вы можете явно выбрать нечувствительность к регистру, указав _CI.
С учетом акцента (_AS)	Различает символы с диакритическими знаками и без них. Например, a не равно á. Если этот параметр не выбран, параметры сортировки не учитывают диакритические знаки. То есть, при сортировке SQL Server считает буквы с диакритическими знаками и без них идентичными друг другу. Вы можете явно выбрать нечувствительность акцента, указав _AI.
Чувствительность к кана (_KS)	Различает два типа японских знаков каны: хирагану и катакану. Если этот параметр не выбран, сопоставление не учитывает различия между символами каны. То есть, при сортировке SQL Server рассматривает символы хирагана и катакана как идентичные. Если не указывать этот параметр, это будет единственным способом задать игнорирование различий в кане.
Чувствительный к ширине (_WS)	Различает символы полной и половинной ширины. Если этот параметр не выбран, SQL Server считает представление полной ширины и половины ширины одного и того же символа идентичным для целей сортировки. Пропуск этого параметра является единственным способом указания нечувствительности к ширине символов.
Селектор чувствительности к вариантам (_VSS)	Различает идеографические варианты выборчиков в японских параметрах сортировки Japanese_Bushu_Kakusu_140 и Japanese_XJIS_140, которые введены в SQL Server 2017 (14.x). Последовательность вариантов состоит из базового символа и селектора вариантов. Если этот _VSS параметр не выбран, сортировка является нечувствительной к селектору варианта, и селектор варианта не учитывается при сравнении. То есть при сортировке SQL Server считает символы, основанные на одном базовом символе, но с разными знаками выбора вариантов, равнозначными. Дополнительные сведения см. в статье Unicode Ideographic Variation Database (База данных идеографических вариантов Юникода). Колляции с учетом вариационных селекторов (_VSS) не поддерживаются в полнотекстовых индексах поиска. Индексы полнотекстового поиска поддерживают только параметры Accent-Sensitive (_AS), Kana-sensitive (_KS) и Width-sensitive (_WS). Движки интеграции SQL Server XML и Common Language Runtime (CLR) не поддерживают (_VSS) селекторы вариантов.
Двоичное (_BIN) 1	Сортирует и сравнивает данные в таблицах SQL Server на основе битовых шаблонов, определенных для каждого символа. Двоичный порядок сортировки учитывает регистр и диакритические знаки. Двоичный порядок сортировки является самым быстрым. Дополнительные сведения см. в разделе Параметры двоичной сортировки в этой статье.
Двоичная кодовая точка (_BIN2) 1	Сортирует и сравнивает данные в таблицах SQL Server на основе кодовых точек Юникода для данных в формате Юникод. Для данных, не использующих Юникод, в сортировке Binary-code point используются сравнения, идентичные сравнениям при двоичной сортировке. Преимущество использования порядка сортировки по двоичным кодовым точкам заключается в том, что в приложениях, сравнивающих отсортированные данные SQL Server, не требуется повторная сортировка данных. В результате порядок сортировки по двоичным кодовым точкам упрощает разработку приложений и может обеспечить повышение производительности. Дополнительные сведения см. в разделе Параметры двоичной сортировки в этой статье.
UTF-8 (_UTF8)	Позволяет хранить данные в кодировке UTF-8 в SQL Server. Если этот параметр не выбран, SQL Server использует формат кодирования, отличный от Юникода по умолчанию, для применимых типов данных. Дополнительные сведения см. в разделе Поддержка UTF-8 в этой статье.

¹ Если выбран двоичный код или точка двоичного кода, параметры с учетом регистра (_CS), с учетом акцента (_AS), с учетом каны (_KS), а также параметры с учетом ширины (_WS) недоступны.

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

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

Суффикс сортировки Windows	Описание порядка сортировки
_BIN 1	Двоичная сортировка
_BIN2 1, 2	Порядок сортировки по двоичным кодовым точкам
_CI_AI 2	Без учета регистра, диакритических знаков, каны и ширины символов
_CI_AI_KS 2	Без учета регистра, без учета диакритических знаков, с учетом каны, без учета ширины символов
_CI_AI_KS_WS 2	Без учета регистра, без учета диакритики, с учетом каны, с учетом ширины символов
_CI_AI_WS 2	Без учета регистра, без учета знаков ударения, без учета каны, с учетом ширины символов
_CI_AS 2	Без учета регистра, с учетом диакритических знаков, без учета каны, без учета ширины
_CI_AS_KS 2	Без учета регистра, с учетом диакритических знаков, с учетом каны, без учета ширины символов
_CI_AS_KS_WS 2	Без учета регистра, с учетом диакритических знаков, с учетом каны, с учетом ширины символов
_CI_AS_WS 2	Без учета регистра, с учетом диакритических знаков, без учета каны, с учетом ширины знаков
_CS_AI 2	С учетом регистра, без учета акцентов, без учета каны, без учета ширины символов
_CS_AI_KS 2	С учетом регистра, без учета диакритических знаков, с учетом каны, без учета ширины символов
_CS_AI_KS_WS 2	С учётом регистра, без учёта диакритических знаков, с учётом каны, с учётом ширины символов
_CS_AI_WS 2	С учетом регистра, без учета знаков ударения, без учета каны, с учетом ширины символов
_CS_AS 2	С учетом регистра, с учетом знаков ударения, без учета каны, без учета ширины
_CS_AS_KS 2	С учетом регистра, с учетом диакритики, с учетом каны, без учета ширины символов
_CS_AS_KS_WS 2	С учетом регистра, диакритики, каны и ширины символов
_CS_AS_WS 2	С учетом регистра, с учетом диакритических знаков, без учета каны, с учетом ширины

¹ Если выбран двоичный код или точка двоичного кода, параметры с учетом регистра (_CS), с учетом акцента (_AS), с учетом каны (_KS), а также параметры с учетом ширины (_WS) недоступны.

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

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

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

• Параметры сортировки Windows
• Двоичные сопоставления
• Сопоставления SQL Server

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

Параметры сортировки Windows определяют правила хранения символьных данных, основанные на связанной локали системы Windows. При использовании параметров сортировки Windows можно реализовать сравнение данных не в Unicode с использованием того же алгоритма, что и для данных Unicode. Базовые правила параметров сортировки Windows задают алфавит или язык, используемый при сортировке по словарю. Кроме того, они определяют кодовую страницу, используемую для хранения символьных данных не в Юникоде. Сортировка в Юникоде и не в Юникоде совместима со сравнением строк в определённой версии Windows. Это обеспечивает согласованность между типами данных в SQL Server и позволяет разработчикам сортировать строки в своих приложениях, используя те же правила, которые используются SQL Server. Дополнительные сведения см. в имени сортировки Windows .

Двоичные сопоставления

При двоичных параметрах сортировки данные сортируются на основе последовательности закодированных значений, определяемых локалью и типом данных. Они чувствительны к регистру. Двоичная сортировка в SQL Server определяет используемый языковой стандарт и кодовую страницу ANSI. При этом принудительно реализуется двоичный порядок сортировки. Поскольку двоичные правила сортировки относительно просты, они способствуют повышению производительности приложений. Для типов данных не в Юникоде сравнение данных производится на основе кодовых точек, определенных в кодовой странице ANSI. Типы данных в Юникоде сравниваются на основе элементов кода Юникода. Для двоичных параметров сортировки типов данных Unicode языковые параметры не учитываются при сортировке данных. Например, Latin1_General_BIN и Japanese_BIN дают идентичные результаты сортировки при использовании в данных Юникода. Дополнительные сведения см. в имени сортировки Windows .

В SQL Server существует два типа двоичных параметров сортировки:

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

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

Сопоставления SQL Server

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

Например, если вы используете сортировку SQL SQL_Latin1_General_CP1_CI_AS, неюникодовая строка 'a-c' меньше строки 'ab', так как дефис (-) отсортирован как отдельный символ, который расположен перед b. Однако если вы преобразуете эти строки в Юникод и выполняете то же сравнение, строка N'a-c' Юникода считается большей N'ab', так как правила сортировки Юникода используют сортировку слов, которая игнорирует дефис.

Для получения дополнительной информации см. Имя сортировки SQL Server.

Во время установки 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:

• Сортировки на уровне сервера
• Колляции на уровне базы данных
• Сопоставления на уровне столбцов
• Колляции на уровне выражений

Колляции на уровне сервера

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

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

Локаль Windows	Windows LCID	SQL LCID	Сортировка по умолчанию
Африкаанс (Южная Африка)	0x0436	0x0409	Latin1_General_CI_AS
Албанский (Албания)	0x041c	0x041c	Albanian_CI_AS
Альсатян (Франция)	0x0484	0x0409	Latin1_General_CI_AS
Амхарик (Эфиопия)	0x045e	0x0409	Latin1_General_CI_AS
Арабский (Алжир)	0x1401	0x0401	Arabic_CI_AS
Арабский (Бахрейн)	0x3c01	0x0401	Arabic_CI_AS
Арабский (Египет)	0x0c01	0x0401	Arabic_CI_AS
Арабский (Ирак)	0x0801	0x0401	Arabic_CI_AS
Арабский (Иордания)	0x2c01	0x0401	Arabic_CI_AS
Арабский (Кувейт)	0x3401	0x0401	Arabic_CI_AS
Арабский (Ливан)	0x3001	0x0401	Arabic_CI_AS
Арабский (Ливия)	0x1001	0x0401	Arabic_CI_AS
Арабский (Марокко)	0x1801	0x0401	Arabic_CI_AS
Арабский (Оман)	0x2001	0x0401	Arabic_CI_AS
Арабский (Катар)	0x4001	0x0401	Arabic_CI_AS
Арабский (Саудовская Аравия)	0x0401	0x0401	Arabic_CI_AS
Арабский (Сирия)	0x2801	0x0401	Arabic_CI_AS
Арабский (Тунис)	0x1c01	0x0401	Arabic_CI_AS
Арабский (США)	0x3801	0x0401	Arabic_CI_AS
Арабский (Йемен)	0x2401	0x0401	Arabic_CI_AS
Армянский (Армения)	0x042b	0x0419	Latin1_General_CI_AS
Ассамский (Индия)	0x044d	0x044d	Недоступен на уровне сервера
Азербайджанский (Азербайджан, кириллица)	0x082c	0x082c	Является нерекомендуемым и недоступен на уровне сервера
Азербайджанский (Азербайджан, латиница)	0x042c	0x042c	Является нерекомендуемым и недоступен на уровне сервера
Башкир (Россия)	0x046d	0x046d	Latin1_General_CI_AI
Баскский (язык)	0x042d	0x0409	Latin1_General_CI_AS
Белорусский (Беларусь)	0x0423	0x0419	Cyrillic_General_CI_AS
Бенгальский (Бангладеш)	0x0845	0x0445	Недоступен на уровне сервера
Бенгали (Индия)	0x0445	0x0439	Недоступен на уровне сервера
Боснийский (Босния и Герцеговина, кириллица)	0x201a	0x201a	Latin1_General_CI_AI
Боснийский (Босния и Герцеговина, латиница)	0x141a	0x141a	Latin1_General_CI_AI
Бретон (Франция)	0x047e	0x047e	Latin1_General_CI_AI
Болгарский (Болгария)	0x0402	0x0419	Cyrillic_General_CI_AS
каталанский язык (Catalan)	0x0403	0x0409	Latin1_General_CI_AS
Китайский (Гонконг, КНР)	0x0c04	0x0404	Chinese_Taiwan_Stroke_CI_AS
Китайский (Макао, специальный административный район)	0x1404	0x1404	Latin1_General_CI_AI
Китайский (Макао, специальный административный район)	0x21404	0x21404	Latin1_General_CI_AI
Китайский (КНР)	0x0804	0x0804	Chinese_PRC_CI_AS
Китайский (КНР)	0x20804	0x20804	Chinese_PRC_Stroke_CI_AS
Китайский (Сингапур)	0x1004	0x0804	Chinese_PRC_CI_AS
Китайский (Сингапур)	0x21004	0x20804	Chinese_PRC_Stroke_CI_AS
китайский (Тайвань)	0x30404	0x30404	Chinese_Taiwan_Bopomofo_CI_AS
китайский (Тайвань)	0x0404	0x0404	Chinese_Taiwan_Stroke_CI_AS
Корсикан (Франция)	0x0483	0x0483	Latin1_General_CI_AI
Хорватский (Босния и Герцеговина, латиница)	0x101a	0x041a	Croatian_CI_AS
Хорватский (Хорватия)	0x041a	0x041a	Croatian_CI_AS
Чешский (Чешская Республика)	0x0405	0x0405	Czech_CI_AS
Датский (Дания)	0x0406	0x0406	Danish_Norwegian_CI_AS
Дари (Афганистан)	0x048c	0x048c	Latin1_General_CI_AI
Диви (Мальдивы)	0x0465	0x0465	Недоступен на уровне сервера
Нидерландский (Бельгия)	0x0813	0x0409	Latin1_General_CI_AS
голландский язык (Нидерланды)	0x0413	0x0409	Latin1_General_CI_AS
Английский (Австралия)	0x0c09	0x0409	Latin1_General_CI_AS
Английский (Белиз)	0x2809	0x0409	Latin1_General_CI_AS
Английский (Канада)	0x1009	0x0409	Latin1_General_CI_AS
Английский (Карибское море)	0x2409	0x0409	Latin1_General_CI_AS
Английский (Индия)	0x4009	0x0409	Latin1_General_CI_AS
Английский (Ирландия)	0x1809	0x0409	Latin1_General_CI_AS
Английский (Ямайка)	0x2009	0x0409	Latin1_General_CI_AS
Английский (Малайзия)	0x4409	0x0409	Latin1_General_CI_AS
Английский (Новая Зеландия)	0x1409	0x0409	Latin1_General_CI_AS
Английский (Филиппины)	0x3409	0x0409	Latin1_General_CI_AS
Английский (Сингапур)	0x4809	0x0409	Latin1_General_CI_AS
Английский (Южная Африка)	0x1c09	0x0409	Latin1_General_CI_AS
Английский (Тринидад и Тобаго)	0x2c09	0x0409	Latin1_General_CI_AS
Английский (Великобритания)	0x0809	0x0409	Latin1_General_CI_AS
Английский (Соединенные Штаты)	0x0409	0x0409	SQL_Latin1_General_CP1_CI_AS
Английский (Зимбабве)	0x3009	0x0409	Latin1_General_CI_AS
Эстонский (Эстония)	0x0425	0x0425	Estonian_CI_AS
Фарерский (Фарерские о-ва)	0x0438	0x0409	Latin1_General_CI_AS
Филиппинский (Филиппины)	0x0464	0x0409	Latin1_General_CI_AS
Финский (Финляндия)	0x040b	0x040b	Finnish_Swedish_CI_AS
Французский (Бельгия)	0x080c	0x040c	French_CI_AS
Французский (Канада)	0x0c0c	0x040c	French_CI_AS
французский (Франция)	0x040c	0x040c	French_CI_AS
Французский (Люксембург)	0x140c	0x040c	French_CI_AS
Французский (Монако)	0x180c	0x040c	French_CI_AS
Французский (Швейцария)	0x100c	0x040c	French_CI_AS
Фрисиан (Нидерланды)	0x0462	0x0462	Latin1_General_CI_AI
Galician	0x0456	0x0409	Latin1_General_CI_AS
Грузинский (Грузия)	0x10437	0x10437	Georgian_Modern_Sort_CI_AS
Грузинский (Грузия)	0x0437	0x0419	Latin1_General_CI_AS
Немецкий — сортировка телефонной книги (DIN)	0x10407	0x10407	German_PhoneBook_CI_AS
Немецкий (Австрия)	0x0c07	0x0409	Latin1_General_CI_AS
Немецкий (Германия)	0x0407	0x0409	Latin1_General_CI_AS
Немецкий (Лихтенштейн)	0x1407	0x0409	Latin1_General_CI_AS
Немецкий (Люксембург)	0x1007	0x0409	Latin1_General_CI_AS
Немецкий (Швейцария)	0x0807	0x0409	Latin1_General_CI_AS
Греческий (Греция)	0x0408	0x0408	Greek_CI_AS
Гренландский (Гренландия)	0x046f	0x0406	Danish_Norwegian_CI_AS
Гуджарати (Индия)	0x0447	0x0439	Недоступен на уровне сервера
Хауса (Нигерия, латиница)	0x0468	0x0409	Latin1_General_CI_AS
Иврит (Израиль)	0x040d	0x040d	Hebrew_CI_AS
Хинди (Индия)	0x0439	0x0439	Недоступен на уровне сервера
Венгерский (Венгрия)	0x040e	0x040e	Hungarian_CI_AS
Техническая венгерская сортировка	0x1040e	0x1040e	Hungarian_Technical_CI_AS
Исландский (Исландия)	0x040f	0x040f	Icelandic_CI_AS
Игбо (Нигерия)	0x0470	0x0409	Latin1_General_CI_AS
Индонезийский (Индонезия)	0x0421	0x0409	Latin1_General_CI_AS
Инуктитут (Канада, латиница)	0x085d	0x0409	Latin1_General_CI_AS
Инуктитут (слоговое письмо, Канада)	0x045d	0x045d	Latin1_General_CI_AI
Ирландский (Ирландия)	0x083c	0x0409	Latin1_General_CI_AS
итальянский (Италия)	0x0410	0x0409	Latin1_General_CI_AS
Итальянский (Швейцария)	0x0810	0x0409	Latin1_General_CI_AS
Японский (Япония, XJIS)	0x0411	0x0411	Japanese_CI_AS
Японский (Япония)	0x040411	0x40411	Latin1_General_CI_AI
Каннада (Индия)	0x044b	0x0439	Недоступен на уровне сервера
Казахский (Казахстан)	0x043f	0x043f	Kazakh_90_CI_AS
Кхмерский (Камбоджа)	0x0453	0x0453	Недоступен на уровне сервера
K'iche (Гватемала)	0x0486	0x0c0a	Modern_Spanish_CI_AS
Kinyarwanda (Руанда)	0x0487	0x0409	Latin1_General_CI_AS
Конкани (Индия)	0x0457	0x0439	Недоступен на уровне сервера
Корейский (Корея, словарная сортировка)	0x0412	0x0412	Korean_Wansung_CI_AS
Киргиз (Кыргызстан)	0x0440	0x0419	Cyrillic_General_CI_AS
Лаосский язык (Лаосская Народно-Демократическая Республика)	0x0454	0x0454	Недоступен на уровне сервера
Латышский (Латвия)	0x0426	0x0426	Latvian_CI_AS
Литовский (Литва)	0x0427	0x0427	Lithuanian_CI_AS
Нижний Сорбский (Германия)	0x082e	0x0409	Latin1_General_CI_AS
Люксембургский язык (Люксембург)	0x046e	0x0409	Latin1_General_CI_AS
Македонский (Северная Македония)	0x042f	0x042f	Macedonian_FYROM_90_CI_AS
малайский язык (Бруней-Даруссалам)	0x083e	0x0409	Latin1_General_CI_AS
Малайский (Малайзия)	0x043e	0x0409	Latin1_General_CI_AS
Малайялам (Индия)	0x044c	0x0439	Недоступен на уровне сервера
Мальтийский (Мальта)	0x043a	0x043a	Latin1_General_CI_AI
Маорийский (Новая Зеландия)	0x0481	0x0481	Latin1_General_CI_AI
Mapudungun (Чили)	0x047a	0x047a	Latin1_General_CI_AI
Маратхи (Индия)	0x044e	0x0439	Недоступен на уровне сервера
Mohawk (Канада)	0x047c	0x047c	Latin1_General_CI_AI
монгольский язык (Монголия)	0x0450	0x0419	Cyrillic_General_CI_AS
Монгольский (КНР)	0x0850	0x0419	Cyrillic_General_CI_AS
непальский (Непал)	0x0461	0x0461	Недоступен на уровне сервера
Норвежский (букмол, Норвегия)	0x0414	0x0414	Latin1_General_CI_AI
Норвежский (нюнорск, Норвегия)	0x0814	0x0414	Latin1_General_CI_AI
окситанский (Франция)	0x0482	0x040c	French_CI_AS
Ория (Индия)	0x0448	0x0439	Недоступен на уровне сервера
Пушту (Афганистан)	0x0463	0x0463	Недоступен на уровне сервера
Персидский (Иран)	0x0429	0x0429	Latin1_General_CI_AI
Польский (Польша)	0x0415	0x0415	Polish_CI_AS
португальский (Бразилия)	0x0416	0x0409	Latin1_General_CI_AS
Португальский (Португалия)	0x0816	0x0409	Latin1_General_CI_AS
Панджаби (Индия)	0x0446	0x0439	Недоступен на уровне сервера
Кечуа (Боливия)	0x046b	0x0409	Latin1_General_CI_AS
Кечуа (Эквадор)	0x086b	0x0409	Latin1_General_CI_AS
Кечуа (Перу)	0x0c6b	0x0409	Latin1_General_CI_AS
Румынский (Румыния)	0x0418	0x0418	Romanian_CI_AS
Романш (Швейцария)	0x0417	0x0417	Latin1_General_CI_AI
Русский (Россия)	0x0419	0x0419	Cyrillic_General_CI_AS
Сахка (Россия)	0x0485	0x0485	Latin1_General_CI_AI
Саамский (Инари, Финляндия)	0x243b	0x083b	Latin1_General_CI_AI
Саамский (Луле, Норвегия)	0x103b	0x043b	Latin1_General_CI_AI
саамский язык (Лулео, Швеция)	0x143b	0x083b	Latin1_General_CI_AI
Саамский (Северный, Финляндия)	0x0c3b	0x083b	Latin1_General_CI_AI
Саамский (Северный, Норвегия)	0x043b	0x043b	Latin1_General_CI_AI
Саамский (Северный, Швеция)	0x083b	0x083b	Latin1_General_CI_AI
Саамский (Скольт, Финляндия)	0x203b	0x083b	Latin1_General_CI_AI
Саамский (Южный, Норвегия)	0x183b	0x043b	Latin1_General_CI_AI
Саамский (Южный, Швеция)	0x1c3b	0x083b	Latin1_General_CI_AI
Санскрит (Индия)	0x044f	0x0439	Недоступен на уровне сервера
Сербский (Босния и Герцеговина, кириллица)	0x1c1a	0x0c1a	Latin1_General_CI_AI
Сербский (Босния и Герцеговина, латиница)	0x181a	0x081a	Latin1_General_CI_AI
Сербский (Сербия, кириллица)	0x0c1a	0x0c1a	Latin1_General_CI_AI
Сербский (Сербия, латиница)	0x081a	0x081a	Latin1_General_CI_AI
Сесуто са Лебоа/Северный Суто (Южная Африка)	0x046c	0x0409	Latin1_General_CI_AS
Сетсвана/Тсвана (Южная Африка)	0x0432	0x0409	Latin1_General_CI_AS
Синхала (Шри-Ланка)	0x045b	0x0439	Недоступен на уровне сервера
Словацкий (Словакия)	0x041b	0x041b	Slovak_CI_AS
Словен (Словения)	0x0424	0x0424	Slovenian_CI_AS
Испанский (Аргентина)	0x2c0a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Боливия)	0x400a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Чили)	0x340a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Колумбия)	0x240a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Коста-Рика)	0x140a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Доминиканская Республика)	0x1c0a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Эквадор)	0x300a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Эль-Сальвадор)	0x440a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Гватемала)	0x100a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Гондурас)	0x480a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Мексика)	0x080a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Никарагуа)	0x4c0a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Панама)	0x180a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Парагвай)	0x3c0a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Перу)	0x280a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Пуэрто-Рико)	0x500a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Испания)	0x0c0a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Испания, традиционная сортировка)	0x040a	0x040a	Traditional_Spanish_CI_AS
Испанский (США)	0x540a	0x0409	Latin1_General_CI_AS
Испанский (Уругвай)	0x380a	0x0c0a	Modern_Spanish_CI_AS
Испанский (Венесуэла)	0x200a	0x0c0a	Modern_Spanish_CI_AS
Суахили (Кения)	0x0441	0x0409	Latin1_General_CI_AS
Шведский (Финляндия)	0x081d	0x040b	Finnish_Swedish_CI_AS
шведский (Швеция)	0x041d	0x040b	Finnish_Swedish_CI_AS
Сирийский (Сирия)	0x045a	0x045a	Недоступен на уровне сервера
Таджикский (Таджикистан)	0x0428	0x0419	Cyrillic_General_CI_AS
Тамазихт (Алжир, латиница)	0x085f	0x085f	Latin1_General_CI_AI
Тамильский (Индия)	0x0449	0x0439	Недоступен на уровне сервера
Татарский (Россия)	0x0444	0x0444	Cyrillic_General_CI_AS
Телугу (Индия)	0x044a	0x0439	Недоступен на уровне сервера
Тайский (Таиланд)	0x041e	0x041e	Thai_CI_AS
Тибетский (PRC)	0x0451	0x0451	Недоступен на уровне сервера
Турецкий (Турция)	0x041f	0x041f	Turkish_CI_AS
Туркменистан (Туркменистан)	0x0442	0x0442	Latin1_General_CI_AI
Уйгур (Китайская Народная Республика)	0x0480	0x0480	Latin1_General_CI_AI
Украинский (Украина)	0x0422	0x0422	Ukrainian_CI_AS
Верхний Сорбский (Германия)	0x042e	0x042e	Latin1_General_CI_AI
Урду (Пакистан)	0x0420	0x0420	Latin1_General_CI_AI
Узбекский (Узбекистан, кириллица)	0x0843	0x0419	Cyrillic_General_CI_AS
Узбекский (Узбекистан, латиница)	0x0443	0x0443	Uzbek_Latin_90_CI_AS
Вьетнамский (Вьетнам)	0x042a	0x042a	Vietnamese_CI_AS
Валлийский (Великобритания)	0x0452	0x0452	Latin1_General_CI_AI
Волоф (Сенегал)	0x0488	0x040c	French_CI_AS
Коса/исиКоса (Южная Африка)	0x0434	0x0409	Latin1_General_CI_AS
Yi (PRC)	0x0478	0x0409	Latin1_General_CI_AS
Yoruba (Нигерия)	0x046a	0x0409	Latin1_General_CI_AS
Зулу/исиЗулу (Южная Африка)	0x0435	0x0409	Latin1_General_CI_AS

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

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

SELECT CONVERT (NVARCHAR (128), SERVERPROPERTY('collation'));

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

SELECT *
FROM sys.fn_helpcollations();

Колляции на уровне базы данных

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

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

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

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

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

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Important

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

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

SELECT CONVERT (NVARCHAR (128), DATABASEPROPERTYEX('database_name', 'collation'));

Настройки сопоставления на уровне столбцов

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

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

ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR (10) COLLATE Greek_CS_AI;

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

Параметры сортировки уровня выражения задаются при выполнении инструкции, и они влияют на способ возврата результирующего набора. Это позволяет результатам сортировки ORDER BY зависеть от локали. Чтобы реализовать правила сортировки на уровне выражений, используйте предложение COLLATE, как в следующем примере кода:

SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;

Locale

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

Кодовая страница

Кодовая страница — это упорядоченный набор символов данного скрипта, в котором числовой индекс или значение кодовой точки связано с каждым символом. Кодовую страницу Windows обычно называют набором символов или кодировкой. Кодовые страницы обеспечивают поддержку кодировок и раскладок клавиатуры, применяемых в различных локалях системы Windows.

Порядок сортировки

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

Поддержка Юникода

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

Основы Юникода

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

Например, рассмотрим базу данных заказчиков в Северной Америке, в которой будут храниться данные на трех основных языках:

• испанские имена и адреса для Мексики;
• французские имена и адреса для Квебека;
• английские имена и адреса для остальной части Канады и Соединенных Штатов.

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

Note

Кодовая страница, используемая клиентом, определяется параметрами операционной системы (ОС). Чтобы установить кодовую страницу клиента в операционной системе Windows, используйте раздел Язык и региональные стандарты на панели управления.

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

Типы данных в Юникоде

При хранении символьных данных, которые отражают несколько языков, используйте типы данных Юникода (nchar, nvarchar и ntext) вместо типов данных, отличных от Юникода (char, varchar и text).

Note

Для типов данных Юникода ядро СУБД может представлять до 65 536 символов с помощью UCS-2 или полного диапазона Юникода (114 112 символов), если используются дополнительные символы. Дополнительные сведения о включении дополнительных символов см. в разделе Дополнительные символы.

Кроме того, начиная с SQL Server 2019 (15.x), если используется параметры сортировки (_UTF8) с поддержкой UTF-8, ранее типы данных, отличные от Юникода (char и varchar), становятся типами данных Юникода с помощью кодировки UTF-8. SQL Server 2019 (15.x) не изменяет поведение существующих типов данных Юникода (nchar, nvarchar и ntext), которые продолжают использовать кодировку UCS-2 или UTF-16. Дополнительные сведения см. в разделе Различия в хранении UTF-8 и UTF-16.

Рекомендации по Юникоду

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

При переносе данных из сервера на клиент старые клиентские драйверы могут не распознать параметры сортировки сервера. Это может произойти при передаче данных с сервера с поддержкой Юникода на клиент без поддержки Юникода. Лучшим вариантом может быть обновление операционной системы клиента, чтобы обновить параметры сортировки базовой системы. Если на клиенте установлена клиентская программа базы данных, можно попробовать применить обновление службы к клиентской программе базы данных.

Tip

Можно также попробовать использовать другие параметры сортировки для данных на сервере. Выберите параметры сортировки, соответствующие кодовой странице в клиенте. Чтобы использовать параметры сортировки UTF-16, доступные в SQL Server (SQL Server 2012 (11.x) и более поздних версиях) для улучшения поиска и сортировки некоторых символов Юникода (только для параметров сортировки Windows), можно выбрать один из дополнительных символов сортировки (_SC) или один из 140 параметров сортировки.

Чтобы использовать параметры сортировки UTF-8, доступные в SQL Server 2019 (15.x), а также для улучшения поиска и сортировки некоторых символов Юникода (только для сортировки Windows), необходимо выбрать параметры сортировки с поддержкой кодировки UTF-8 (_UTF8).

• Флаг UTF8 может применяться к:

  • Лингвистические параметры сортировки, которые уже поддерживают дополнительные символы (_SC) или учет чувствительности к селекторам вариантов (_VSS)
  • BIN2 двоичная сортировка

• Флаг UTF8 не может быть применён к:

  • Языковые правила сортировки, не поддерживающие дополнительные символы (_SC) или чувствительность к селекторам вариантов (_VSS)
  • Двоичные колляции BIN
  • Колляции SQL_*

Чтобы получить представление о трудностях, связанных с применением типов данных в Юникоде или не в Юникоде, протестируйте свой сценарий, измерив разницу производительности для этих двух вариантов в вашей среде. Рекомендуется стандартизировать системные параметры сортировки, которые используются в организации, а там, где это возможно, — развертывать серверы и клиенты с поддержкой Юникода.

Во многих ситуациях SQL Server взаимодействует с другими серверами или клиентами, и ваша организация может использовать несколько стандартов доступа к данным между приложениями и экземплярами сервера. Клиенты SQL Server являются одним из двух основных типов:

• клиенты с поддержкой Юникода, применяющие OLE DB и ODBC версии 3.7 или более поздних;
• клиенты без поддержки Юникода, применяющие DB-Library и ODBC версий 3.6 или более ранних.

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

Server	Client	Преимущества или ограничения
Unicode	Unicode	Так как данные в Юникоде широко используются в системе, этот сценарий обеспечивает наилучшую производительность и защиту полученных данных от повреждения. Это случай применения объектов данных ActiveX (ADO), OLE DB, а также ODBC версии 3.7 или более поздней.
Unicode	Non-Unicode	В этом сценарии, особенно при подключении между сервером, работающим под управлением более новой операционной системы, и клиентом, работающим с более ранней версией SQL Server или более старой операционной системой, могут быть ограничения или ошибки при перемещении данных на клиентский компьютер. Данные Юникод на сервере пытаются сопоставиться с соответствующей кодовой страницей на клиенте, не поддерживающем Юникод, для преобразования данных.
Non-Unicode	Unicode	Это не лучшая конфигурация для работы с данными на нескольких языках. Невозможно записать данные в Юникоде на сервер, работающий не в Юникоде. Проблемы, скорее всего, возникнут при отправке данных на серверы, если данные не входят в кодовую страницу сервера.
Non-Unicode	Non-Unicode	В этом сценарии очень много ограничений для применения данных на нескольких языках. Можно использовать только одну кодовую страницу.

Дополнительные символы

Консорциум Юникода выделяет каждому символу уникальную кодовую точку, которая является значением в диапазоне 000000 – 10FFFF. Наиболее часто используемые символы имеют значения точек кода в диапазоне 000000 – 00FFFF (65 536 символов), которые помещаются в 8-разрядное или 16-разрядное слово в памяти и на диске. Этот диапазон обычно обозначается как основное многоязычное поле (BMP).

При этом Консорциум Юникода установил 16 дополнительных "полей" символов, каждое с таким же размером, как у BMP. Это определение позволяет Юникоду представлять 1114 112 символов (т. е. 2¹⁶ * 17 символов) в диапазоне точек кода 000000 – 10FFFF. Символы с значением точки кода, превышающим 00FFFF, требуют двух-четырех последовательных 8-разрядных слов (UTF-8) или двух последовательных 16-разрядных слов (UTF-16). Эти символы, находящиеся вне BMP, называются дополнительными символами, а дополнительные последовательные 8-разрядные или 16-разрядные слова — суррогатной парой. Дополнительные сведения о дополнительных символах, суррогатах и суррогатных парах см . в стандарте Юникода.

SQL Server предоставляет такие типы данных, как nchar и nvarchar для хранения данных Юникода в диапазоне BMP (000000 – 00FFFF), который СУБД кодирует с использованием кодировки UCS-2.

В SQL Server 2012 (11.x) было представлено новое семейство правил сортировки для дополнительных символов (_SC), которые можно использовать с типами данных nchar, nvarchar и sql_variant для представления полного диапазона символов Юникода (000000 – 10FFFF). Например, Latin1_General_100_CI_AS_SC или, если вы используете японскую сортировку, Japanese_Bushu_Kakusu_100_CI_AS_SC.

SQL Server 2019 (15.x) расширяет дополнительную поддержку символов для типов данных char и varchar с новыми включенными параметрами сортировки UTF-8 (_UTF8). Эти типы данных также способны представлять полный диапазон символов Юникода.

Note

Начиная с SQL Server 2017 (14.x), все новые параметры сортировки автоматически поддерживают дополнительные символы.

Если используются дополнительные символы:

• Дополнительные символы можно использовать в операциях упорядочения и сравнения в версиях параметров сортировки 90 и выше.

• Все новые параметры сортировки версии 100 поддерживают лингвистическую сортировку с обработкой дополнительных символов.

• Дополнительные символы не поддерживаются в метаданных (например, в именах объектов баз данных).

• Флаг SC может применяться к следующим:

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

• Флаг SC не может быть применён к:

  • Неверсионные правила сортировки Windows версии 80
  • Двоичные правила сортировки BIN или BIN2
  • Правила сортировки SQL*
  • Параметры сортировки версии 140 (им не требуется флаг SC, так как они уже поддерживают дополнительные символы)

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

Строковая функция или оператор	С правилами сортировки SCA	Без правил сортировки SCA
CHARINDEX LEN PATINDEX	Суррогатная пара UTF-16 считается одной кодовой точкой.	Суррогатная пара UTF-16 считается двумя кодовыми точками.
LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF	Эти функции обрабатывают каждую суррогатную пару как одну кодовую точку и работают ожидаемым образом.	Эти функции могут разбивать любые суррогатные пары, что приводит к неожиданным результатам.
NCHAR	Возвращает символ, соответствующий указанному значению точки кода Юникода в диапазоне 0 – 0x10FFFF. Если указанное значение находится в диапазоне 0 – 0xFFFF, возвращается один символ. Для более высоких значений возвращается соответствующий суррогат.	Значение выше 0xFFFF возвращает NULL вместо соответствующего суррогата.
UNICODE	Возвращает точку кода UTF-16 в диапазоне 0 – 0x10FFFF.	Возвращает кодовую точку UCS-2 в диапазоне 0 – 0xFFFF.
Подстановочный знак — соответствует одному символу Подстановочный знак — символы, которые не должны совпадать	Поддерживаются дополнительные символы во всех операциях с подстановочными знаками.	Дополнительные символы не поддерживаются в этих операциях с подстановочными знаками. Поддерживаются другие операторы символов-шаблонов.

поддержка GB18030

GB18030 — это отдельный стандарт, который применяется в Китайской Народной Республике для кодирования китайских иероглифов. В кодировке GB18030 введенные данные могут иметь длину 1, 2 или 4 байт. SQL Server обеспечивает поддержку символов, закодированных в GB18030, распознав их при входе на сервер из клиентского приложения и преобразовав и сохраняя их в собственном коде как символы Юникода. После сохранения на сервере эти символы при выполнении всех последующих операций рассматриваются как символы Юникода.

Можно использовать любые параметры сортировки для китайского языка. Желательно использовать последнюю версию (100). Все правила сортировки версии 100 поддерживают лингвистическую сортировку для символов GB18030. Если данные содержат дополнительные символы (суррогатные пары), можно использовать параметры сортировки SC, доступные в SQL Server для улучшения поиска и сортировки.

Note

Убедитесь, что клиентские инструменты, такие как SQL Server Management Studio, используют шрифт Dengxian для правильного отображения строк, содержащих символы, закодированные GB18030.

Поддержка сложных скриптов

SQL Server может поддерживать входные данные, хранение, изменение и отображение сложных скриптов. Ниже приведены типы сложных скриптов:

• Письменности, включающие текст как справа налево, так и слева направо, например сочетание арабского и английского текста.
• Скрипты, в которых форма символов изменяется в зависимости от их положения или где сочетаются разные символы (например, в арабском, хинди, тайском).
• Для таких языков, как тайский, требуются внутренние словари для распознавания слов, так как между словами нет пробелов.

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

Сортировки для японского языка добавлены в SQL Server 2017

Начиная с SQL Server 2017 (14.x), поддерживаются новые семейства японских параметров сортировки, с комбинациями различных параметров (_CS, _AS, _KS, _WS и _VSS), а также _BIN и _BIN2.

Чтобы получить список этих параметров сортировки, можно выполнить запрос к ядру СУБД SQL Server:

SELECT name,
       description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;

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

Эти параметры сортировки поддерживаются в индексах компонента ядро СУБД, таблицах, оптимизированных для памяти, индексах columnstore и изначально компилируемых модулях.

Правила сортировки в База данных SQL Azure

Невозможно изменить или задать параметры сортировки логического сервера в Базе данных SQL Azure, но можно настроить параметры сортировки каждой базы данных как для данных, так и для каталога. Параметры сортировки каталога определяют параметры сортировки для системных метаданных, таких как идентификаторы объектов. Обе сортировки можно указать независимо друг от друга при создании базы данных на портале Azure, в T-SQL с помощью CREATE DATABASE, в PowerShell с помощью New-AzSqlDatabase.

Параметры сортировки в Управляемом экземпляре SQL Azure

Параметры сортировки на уровне сервера в Управляемом экземпляре SQL Azure можно указать при создании экземпляра и его невозможно изменить позже.

Дополнительные сведения см. в разделе Установка или изменение параметров сортировки сервера.

Сопоставление в Microsoft Fabric

В хранилище данных Microsoft Fabric разрешены только параметры сортировки: Latin1_General_100_BIN2_UTF8 и Latin1_General_100_CI_AS_KS_WS_SC_UTF8.

В базе данных SQL в Microsoft Fabric сортировка по умолчанию — SQL_Latin1_General_CP1_CI_AS, и в настоящее время её нельзя изменить. Поддерживаются настройки сортировок для отдельных столбцов.

Поддержка UTF-8

SQL Server 2019 (15.x) предоставляет полную поддержку широко используемой кодировки символов UTF-8 в качестве кодировки импорта или экспорта, а также в качестве параметров сортировки на уровне базы данных или столбцов для строковых данных. Кодировка символов UTF-8 допускается в типах данных char и varchar. Она активируется при создании параметров сортировки с суффиксом UTF8 или изменении существующих параметров на таковые. Одним из примеров является изменение Latin1_General_100_CI_AS_SC на Latin1_General_100_CI_AS_SC_UTF8.

UTF-8 доступен только для параметров сортировки Windows, поддерживающих дополнительные символы, как представлено в SQL Server 2012 (11.x). Типы данных nchar и nvarchar допускают только кодировку UCS-2 или UTF-16 и остаются неизменными.

База данных SQL Azure и Управляемый экземпляр SQL Azure также поддерживают UTF-8 на уровне базы данных и столбцов, а Управляемый экземпляр SQL также поддерживает это на уровне сервера.

Различия в хранении между UTF-8 и UTF-16

Консорциум Юникода выделяет каждому символу уникальную кодовую точку, которая является значением в диапазоне 000000 – 10FFFF. При использовании SQL Server 2019 (15.x) доступны кодировки UTF-8 и UTF-16 для представления полного диапазона:

• При кодировке UTF-8 символы в диапазоне ASCII (000000 – 00007F) требуют 1 байта, кодовые точки 00080 – 0007FF требуют 2 байта, кодовые точки 000800 – 00FFFF требуют 3 байта, а точек кода 0001000 – 0010FFFF требуется 4 байта.
• При кодировке UTF-16 кодовые точки 000000 – 000FF требуют 2 байта, а кодовые точки 0010000 – 0010FFFF требуют 4 байта.

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

Диапазон кодов (шестнадцатеричный)	Диапазон кодов (десятичный)	Байты хранения 1 с использованием кодировки UTF-8	Байты хранения 1 с кодировкой UTF-16
000000 – 00007F	0 - 127	1	2
000080 – 00009F 0000A0 – 0003FF 000400 – 0007FF	128 - 159 160 - 1,023 1,024 - 2,047	2	2
000800 – 003FFF 004000 – 00FFFF	2,048 - 16,383 16,384 - 65,535	3	2
010000 – 03FFFF 2 040000 – 10FFFF 2	65 536 - 262 143 2 262 144 - 1 114 111 2	4	4

¹Байты хранения означают длину в байтах в закодированном виде, а не размер типа данных при хранении на диске. Дополнительные сведения об объеме хранения на диске см. в статьях о nchar и nvarchar и char и varchar.

² Диапазон кодовых точек для дополнительных символов.

Tip

Это общее восприятие, в char и varchar или в nchar и nvarchar, что n определяет количество символов. Это связано с тем, что в примере столбца char(10) 10 символов ASCII в диапазоне 0 – 127 можно хранить с помощью сортировки, например Latin1_General_100_CI_AI, так как каждый символ в этом диапазоне использует только 1 байт. Однако в char и varcharn определяет размер строки в байтах (0 – 8000), а в nchar и nvarcharn определяет размер строки в байтовых пар (0 – 4000). n никогда не определяет количество хранимых символов.

Выбор подходящей кодировки Юникода и типа данных может привести к значительной экономии пространства или увеличению текущего объема хранилища в зависимости от используемого набора символов. Например, при использовании латинской сортировки с поддержкой UTF-8, такой как Latin1_General_100_CI_AI_SC_UTF8, столбец char(10) хранит 10 байтов и может содержать 10 символов ASCII в диапазоне от 0 до 127. Но он может содержать только пять символов в диапазоне 128 – 2047 и только три символа в диапазоне 2048 – 65535. По сравнению с тем, что столбец nchar(10) хранит 10 байтовых пар (20 байтов), он может содержать 10 символов в диапазоне 0 – 65535.

Прежде чем решить, следует ли использовать кодировку UTF-8 или UTF-16 для базы данных или столбца, рассмотрите распределение строковых данных, которые будут храниться:

• Если диапазон в основном ASCII 0–127 (например, английский язык), каждый символ требует 1 байт с UTF-8 и 2 байта с UTF-16. Использование UTF-8 дает преимущества в плане хранения данных. Изменение существующего типа данных столбца с символами ASCII в диапазоне 0 – 127 с nchar(10) на char(10)и использование включенной сортировки UTF-8 преобразуется в 50 процентов сокращения требований к хранилищу. Это сокращение связано с тем, что nchar(10) требует 20 байт для хранения, по сравнению с char(10), что требует 10 байт для того же представления строки Юникода.
• За пределами диапазона ASCII почти все письменности на основе латиницы, а также греческое, кириллическое, коптское, армянское, еврейское, арабское, сирийское письмо, таана и нко, требуют 2 байта на символ как в UTF-8, так и в UTF-16. В этих случаях нет существенных различий в хранилище для сопоставимых типов данных (например, между использованием char или nchar).
• Если будут использоваться преимущественно восточноазиатские языки (например, корейский, китайский и японский), каждому символу потребуется 3 байта в UTF-8 и 2 байта в UTF-16. Использование UTF-16 дает преимущества в плане хранения.
• Символы в диапазоне 010000 – 10FFFF требуют 4 байта в UTF-8 и UTF-16. В этих случаях нет различий в хранилище для сопоставимых типов данных (например, между использованием char или nchar).

Сведения о других факторах, которые необходимо учитывать, см. в статье Написание инструкций Transact-SQL, адаптированных к международному использованию.

Преобразование в UTF-8

Так как в char и varchar или в nchar и nvarchar, n определяет размер хранилища байтов, а не количество символов, которые можно сохранить, важно определить размер типа данных, в который необходимо преобразовать. Символы, превышающие размер, должны быть усечены.

Например, рассмотрим столбец, определенный как nvarchar(100), который хранит 180 байт японских символов. В этом примере данные столбца в настоящее время кодируются с помощью UCS-2 или UTF-16, где используется 2 байта на символ. Преобразование типа столбца в varchar(200) недостаточно для предотвращения усечения данных, так как новый тип данных может хранить только 200 байт, но японские символы требуют 3 байта при кодировании в UTF-8. Столбец должен быть определен как varchar(270), чтобы избежать потери данных путем усечения данных.

Поэтому перед преобразованием существующих данных в UTF-8 необходимо заранее знать, какой размер проецируемого байта соответствует определению столбца, а затем соответствующим образом настроить размер нового типа данных. Ознакомьтесь со скриптом Transact-SQL или SQL-блокнотом в репозитории Data Samples GitHub, в которых используются функция DATALENGTH и оператор COLLATE, чтобы определить необходимые требования к длине данных для операций преобразования в UTF-8 в существующей базе данных.

Чтобы изменить параметры сортировки столбца и тип данных в существующей таблице, используйте один из методов, описанных в разделе Задание или изменение параметров сортировки столбца.

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

Связанные задачи

Task	Article
Описание задания или изменения параметров сортировки экземпляра SQL Server. Изменение параметров сортировки сервера не изменяет параметры сортировки существующих баз данных.	Задать или изменить параметры сортировки сервера
Описание задания или изменения параметров сортировки пользовательской базы данных. Изменение параметров сортировки базы данных не изменяет параметры сортировки существующих столбцов таблицы.	Задать или изменить параметры сортировки базы данных
Описывает, как задать или изменить параметры сортировки столбца в базе данных.	Установка или изменение правил сортировки столбца
Описывает, как возвращать сведения о сортировке на уровне сервера, базы данных или столбца.	Просмотр сведений о параметрах сортировки
Определяет, как писать операторы Transact-SQL, которые легче адаптируются для разных языков или легче поддерживают несколько языков.	Написание инструкций Transact-SQL, адаптированных к международному использованию
Описывает, как изменить язык сообщений об ошибках и настроек для использования и отображения данных даты, времени и валюты.	Задание языка сеанса

Связанный контент

• Рекомендации по изменению параметров сортировки в SQL Server
• Использование формата символов Юникода для импорта или экспорта данных (SQL Server)
• Написание инструкций Transact-SQL, адаптированных к международному использованию
• Рекомендации SQL Server по лучшим практикам миграции на Юникод
• Консорциум Юникода
• Стандарт Юникода
• Поддержка UTF-8 в OLE DB Driver for SQL Server
• Имя параметра сортировки SQL Server (Transact-SQL)
• имя сортировки Windows (Transact-SQL)
• Общие сведения о поддержке UTF-8 в SQL Server
• COLLATE (Transact-SQL)
• Приоритет сортировки
• Встроенные параметры сортировки базы данных
• Выбор языка при создании полнотекстового индекса
• sys.fn_helpcollations (Transact-SQL)
• Однобайтовые и многобайтовые кодировки