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

Применимо к: даSQL Server (все поддерживаемые версии) ДаБаза данных SQL Azure ДаУправляемый экземпляр SQL Azure даAzure Synapse Analytics даПараллельное хранилище данных

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

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

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

Для эффективного использования поддержки параметров сортировки в 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 определяет параметры сортировки без учета регистра, без учета диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов, с учетом знаков выбора варианта и с использованием кодировки не в Юникоде.

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

Параметр Описание
С учетом регистра (_CS) Различаются буквы верхнего и нижнего регистров. При выборе этого параметра буквы нижнего регистра при сортировке ставятся перед соответствующими буквами верхнего регистра. Если этот параметр не выбран, параметры сортировки не учитывают регистр. То есть при сортировке SQL Server считает буквы верхнего и нижнего регистров и делает их идентичными друг другу. Можно явно выбрать нечувствительность к регистру, указав параметр _CI.
С учетом диакритических знаков (_AS) Различаются символы с диакритическими знаками и без них. Например, "a" отлично от "ấ". Если этот параметр не выбран, параметры сортировки не учитывают диакритические знаки. То есть при сортировке SQL Server рассматривает варианты букв с диакритическими знаками и без них как идентичные. Можно явно выбрать нечувствительность к диакритическим знакам, указав параметр _АI.
С учетом типа японской азбуки (_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) не поддерживаются в полнотекстовых индексах. Полнотекстовые индексы поддерживают только параметры с учетом диакритических знаков (_AS), типа японской азбуки (_KS) и ширины символов (_WS). Подсистемы CLR и XML в SQL Server не поддерживают знаки выбора варианта (_VSS).
Двоичный (_BIN) 1 Данные в SQL Server сортируются и сравниваются на основе битовых шаблонов, определенных для каждого символа. Двоичный порядок сортировки учитывает регистр и диакритические знаки. Двоичный порядок сортировки является самым быстрым. Дополнительные сведения см. в разделе Параметры двоичной сортировки в этой статье.
Элемент двоичного кода (_BIN2) 1 Данные в SQL Server сортируются и сравниваются на основе элементов Юникода для данных в Юникоде. Для типов данных не в Юникоде при выборе BIN2 сравнение производится так же, как и двоичная сортировка.

Преимуществом использования порядка сортировки BIN2 является то, что приложениям, сравнивающим отсортированные данные SQL Server, не требуется никакой повторной сортировки данных. В результате сортировка BIN2 упрощает разработку приложения и увеличивает ожидаемую производительность. Дополнительные сведения см. в разделе Параметры двоичной сортировки в этой статье.
UTF-8 (_UTF8) Позволяет хранить данные в кодировке UTF-8 в SQL Server. Если этот параметр не выбран, SQL Server использует формат кодировки по умолчанию (не в Юникоде) для подходящих типов данных. Дополнительные сведения см. в разделе Поддержка UTF-8 в этой статье.

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

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

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

Суффикс параметров сортировки Windows Описание порядка сортировки
_BIN1 Двоичная сортировка
_BIN21, 2 Порядок сортировки элементов двоичного кода
_CI_AI2 Без учета регистра, без учета диакритических знаков, без учета типа японской азбуки, без учета ширины символов
_CI_AI_KS2 Без учета регистра, без учета диакритических знаков, с учетом типа японской азбуки, без учета ширины символов
_CI_AI_KS_WS2 Без учета регистра, без учета диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов
_CI_AI_WS2 Без учета регистра, без учета диакритических знаков, без учета типа японской азбуки, с учетом ширины символов
_CI_AS2 Без учета регистра, с учетом диакритических знаков, без учета типа японской азбуки, без учета ширины символов
_CI_AS_KS2 Без учета регистра, с учетом диакритических знаков, с учетом типа японской азбуки, без учета ширины символов
_CI_AS_KS_WS2 Без учета регистра, с учетом диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов
_CI_AS_WS2 Без учета регистра, с учетом диакритических знаков, без учета типа японской азбуки, с учетом ширины символов
_CS_AI2 С учетом регистра, без учета диакритических знаков, без учета типа японской азбуки, без учета ширины символов
_CS_AI_KS2 С учетом регистра, без учета диакритических знаков, с учетом типа японской азбуки, без учета ширины символов
_CS_AI_KS_WS2 С учетом регистра, без учета диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов
_CS_AI_WS2 С учетом регистра, без учета диакритических знаков, без учета типа японской азбуки, с учетом ширины символов
_CS_AS2 С учетом регистра, с учетом диакритических знаков, без учета типа японской азбуки, без учета ширины символов
_CS_AS_KS2 С учетом регистра, с учетом диакритических знаков, с учетом типа японской азбуки, без учета ширины символов
_CS_AS_KS_WS2 С учетом регистра, с учетом диакритических знаков, с учетом типа японской азбуки, с учетом ширины символов
_CS_AS_WS2 С учетом регистра, с учетом диакритических знаков, без учета типа японской азбуки, с учетом ширины символов

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.

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

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

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

Локаль Windows Код языка в Windows Код языка SQL Параметры сортировки по умолчанию
Африкаанс (Южная Африка) 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 Недоступен на уровне сервера
Bengali (India) 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 (Catalan) 0x0403 0x0409 Latin1_General_CI_AS
Китайский (Гонконг, КНР) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Chinese (Macao SAR) 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
Chinese (Singapore) 0x1004 0x0804 Chinese_PRC_CI_AS
Chinese (Singapore) 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
Галисийский 0x0456 0x0409 Latin1_General_CI_AS
Грузинский (Грузия) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
Грузинский (Грузия) 0x0437 0x0419 Latin1_General_CI_AS
Немецкий (сортировка телефонной книги) 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
Японский (Япония) 0x0411 0x0411 Japanese_CI_AS
Японский (Япония) 0x040411 0x40411 Latin1_General_CI_AI
Каннада (Индия) 0x044b 0x0439 Недоступен на уровне сервера
Казахский (Казахстан) 0x043f 0x043f Kazakh_90_CI_AS
Кхмерский (Камбоджа) 0x0453 0x0453 Недоступен на уровне сервера
Киче (Гватемала) 0x0486 0x0c0a Modern_Spanish_CI_AS
Киньяруанда (Руанда) 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
Мапудунгун (Чили) 0x047a 0x047a Latin1_General_CI_AI
Маратхи (Индия) 0x044e 0x0439 Недоступен на уровне сервера
Могавк (Канада) 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
Тибетский (КНР) 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
Носу (КНР) 0x0478 0x0409 Latin1_General_CI_AS
Йоруба (Нигерия) 0x046a 0x0409 Latin1_General_CI_AS
Зулу/исиЗулу (Южная Африка) 0x0435 0x0409 Latin1_General_CI_AS

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

Запрос параметров сортировки сервера для экземпляра SQL Server выполняется с помощью функции SERVERPROPERTY.

SELECT CONVERT(varchar, SERVERPROPERTY('collation'));

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

SELECT * FROM sys.fn_helpcollations();

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

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

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

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

Примечание

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

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

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Важно!

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

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

SELECT CONVERT (VARCHAR(50), 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;    

Локаль

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Для хранения символьных данных на нескольких языках в SQL Server (SQL Server 2005 (9.x) и выше) используйте типы данных в Юникоде (nchar, nvarchar и ntext). Не используйте другие типы данных (char, varchar и text).

Примечание

Для типов данных в Юникоде Компонент Database Engine может представить до 65 535 символов с помощью UCS-2 или полный диапазон Юникода (1 114 111 символов), если используются дополнительные символы. Дополнительные сведения о включении дополнительных символов см. в разделе Дополнительные символы.

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

Замечания о Юникоде

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

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

Совет

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

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

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

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

    • Лингвистические параметры сортировки, которые уже поддерживают дополнительные символы (_SC), или с учетом знаков выбора варианта (_VSS).
    • Параметры двоичной сортировки BIN21
  • Флаг UTF8 не может применяться к следующим параметрам сортировки:

    • Лингвистические параметры сортировки, которые не поддерживают дополнительные символы (_SC), или с учетом знаков выбора варианта (_VSS).
    • Параметры двоичной сортировки BIN и BIN22
    • Параметры сортировки SQL_*

1 Начиная с SQL Server 2019 (15.x) CTP 2.3. SQL Server 2019 (15.x) В CTP 3.0 параметры сортировки UTF8_BIN2 заменены на Latin1_General_100_BIN2_UTF8.
2 Начиная с SQL Server 2019 (15.x) CTP 2.3.

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

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

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

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

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

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

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

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

SQL Server предоставляет типы данных, такие как nchar и nvarchar, для хранения данных Юникода в диапазоне BMP (000000–00FFFF), который Компонент Database Engine кодирует с помощью 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). Эти типы данных также способны представлять полный диапазон символов Юникода.

Примечание

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

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

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

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

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

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

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

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

В следующей таблице сравнивается поведение некоторых строковых функций и строковых операторов при использовании дополнительных символов с параметрами сортировки, поддерживающими дополнительные символы (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 до 0x0xFFFF.
Шаблон — совпадение одного символа

Шаблон — несовпадающие символы
Дополнительные символы поддерживаются для всех операций с символами-шаблонами. Дополнительные символы не поддерживаются для этих операций с символами-шаблонами. Поддерживаются другие операторы символов-шаблонов.

Поддержка GB18030

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

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

Примечание

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

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

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

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

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

Параметры сортировки для японского языка, добавленные в SQL Server 2017 (14.x);

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

Чтобы получить список этих параметров сортировки, можно выполнить запрос Компонент SQL Server Database Engine:

SELECT Name, Description FROM fn_helpcollations()  
WHERE Name LIKE 'Japanese_Bushu_Kakusu_140%' OR Name LIKE 'Japanese_XJIS_140%'

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

Эти параметры сортировки поддерживаются в индексах Компонент Database Engine, оптимизированных для памяти таблицах, индексах columnstore и модулях, скомпилированных в собственном коде.

Поддержка 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 на уровне баз данных и столбцов, а Управляемый экземпляр также поддерживает эту кодировку на уровне серверов.

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

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

  • В кодировке UTF-8 символам в диапазоне ASCII (000000–00007F) требуется 1 байт, кодовым точкам с 000080 по 0007FF необходимо 2 байта, кодовым точкам с 000800 по 00FFFF — 3 байта, а кодовым точкам 0010000–0010FFFF — 4 байта.
  • В кодировке UTF-16 кодовым точкам 000000–00FFFF необходимо 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–1023
1024–2047
2 2
000800–003FFF
004000–00FFFF
2048–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

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

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

Совет

Часто считают, что в типах данных CHAR(n) и VARCHAR(n) или NCHAR(n) и NVARCHAR(n) число n указывает на количество символов. Причина в том, что, например, в столбце CHAR(10) могут храниться 10 символов ASCII в диапазоне 0–127 при использовании таких параметров сортировки, как Latin1_General_100_CI_AI, так как каждый символ в этом диапазоне занимает 1 байт.

Однако число n в CHAR(n) и VARCHAR(n) — это размер строки в байтах (0–8000), а в NCHAR(n) и NVARCHAR(n) число n — это размер строки в парах байтов (0–4000). n никогда не определяет количество хранимых символов.

Как следует из таблицы, правильный выбор кодировки Юникода и типа данных позволяет существенно сократить объем хранимых данных, а неправильный может увеличить занимаемый объем хранилища в зависимости от используемой кодировки. Например, при использовании параметров сортировки Latin с поддержкой UTF-8, такой как Latin1_General_100_CI_AI_SC_UTF8, в столбце CHAR(10) могут храниться 10 байтов и помещаются 10 символов ASCII в диапазоне 0–127. Однако в нем помещаются только 5 символов в диапазоне 128–2047 или 3 символа в диапазоне 2048–65 535. Для сравнения, так как в столбце NCHAR(10) хранятся 10 пар байтов (20 байтов), в нем помещаются 10 символов в диапазоне 0–65 535.

При выборе кодировки 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 (n) и VARCHAR (n) или NCHAR (n) и NVARCHAR (n) n определяет размер хранилища в байтах, а не число сохраняемых символов, важно определить размер типа данных, в который необходимо выполнить преобразование, чтобы избежать усечения данных.

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

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

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

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

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

Дополнительные сведения см. в следующих связанных ресурсах:

См. также раздел

Параметры сортировки автономной базы данных
Выбор языка при создании полнотекстового индекса
sys.fn_helpcollations (Transact-SQL)
Однобайтовые и многобайтовые кодировки