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

  • Статья

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

Параметры сортировки в 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) Различает различные селекторы вариантов ideographic в японских параметрах сортировки Japanese_Bushu_Kakusu_140 и Japanese_XJIS_140, которые представлены в SQL Server 2017 (14.x). Последовательность вариантов состоит из базового символа и селектора вариантов. Если этот параметр _VSS не выбран, параметры сортировки не учитывается, а селектор вариантов не учитывается в сравнении. То есть при сортировке SQL Server считает символы, основанные на одном базовом символе, но с разными знаками выбора вариантов, равнозначными. Дополнительные сведения см. в статье Unicode Ideographic Variation Database (База данных идеографических вариантов Юникода).

Параметры сортировки с учетом вариантов (_VSS) не поддерживаются в полнотекстовых индексах поиска. Полнотекстовые индексы поддерживают только параметры с учетом диакритических знаков (_AS), типа японской азбуки (_KS) и ширины символов (_WS). Подсистемы SQL Server XML и CLR не поддерживают (_VSS) селекторы вариантов.
Binary (_BIN)1 Сортирует и сравнивает данные в таблицах SQL Server на основе битовых шаблонов, определенных для каждого символа. Двоичный порядок сортировки учитывает регистр и диакритические знаки. Двоичный порядок сортировки является самым быстрым. Дополнительные сведения см. в разделе Параметры двоичной сортировки в этой статье.
Двоичная кодовая точка (_BIN2)1 Сортирует и сравнивает данные в таблицах SQL Server на основе точек кода Юникода для данных Юникода. Для типов данных не в Юникоде при выборе BIN2 сравнение производится так же, как и двоичная сортировка.

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

1 Если выбрана точка двоичного или двоичного кода, параметры с учетом регистра (_CS), с учетом акцентов (_AS), kana-sensitive (_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 С учетом регистра, с учетом диакритических знаков, без учета типа японской азбуки, с учетом ширины символов

1 Если выбрана точка двоичного или двоичного кода, параметры с учетом регистра (_CS), с учетом акцентов (_AS), kana-sensitive (_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. Типы данных в Юникоде сравниваются на основе элементов кода Юникода. Для параметров двоичной сортировки на основе типов данных Юникода при сортировке данных языковой стандарт не учитывается. Например, Latin1_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_Latin1_General_CP1_CI_AS сортировки SQL, строка'a-c', не являющаяся юникодом, меньше строки'ab', так как дефис (-) сортируется как отдельный символ, который приходится раньшеb. Однако если вы преобразуете эти строки в Юникод и выполняете то же сравнение, строка N'a-c' Юникода считается большей N'ab', так как правила сортировки Юникода используют сортировку слов, которая игнорирует дефис.

Дополнительные сведения см. в статье Имя параметров сортировки 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
Chinese (Macao SAR) 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(nvarchar(128), SERVERPROPERTY('collation'));

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

SELECT * FROM sys.fn_helpcollations();

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

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

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

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

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

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

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

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

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

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

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

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Внимание

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

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

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;

Локаль

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

Примечание.

For Unicode data types, the Database Engine can represent up to 65,536 characters using UCS-2, or the full Unicode range (‭1,114,112‬ characters) if supplementary characters are used. Дополнительные сведения о включении дополнительных символов см. в разделе Дополнительные символы.

Кроме того, начиная с 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.

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

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

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

Совет

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

Чтобы использовать параметры сортировки 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 или более ранних.

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

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

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

Консорциум Юникода назначает каждому символу уникальную кодовую точку, лежащую в диапазоне от 000000 до 10FFFF. Наиболее часто используемые символы имеют значения кодовых точек в диапазоне от 000000 до 00FFFF (65 536 символов), умещающиеся в 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 (00000–00FFFF), которые ядро СУБД кодирует с помощью UCS-2.

В SQL Server 2012 (11.x) появилось новое семейство дополнительных параметров сортировки символов (_SC), которые можно использовать с nchar, nvarchar и sql_variant типы данных для представления полного диапазона символов Юникода (00000–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 2017 (14.x), все новые параметры сортировки автоматически поддерживают дополнительные символы.

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

  • Дополнительные символы могут применяться в операциях сортировки и сравнения только в параметрах сортировки с версией 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, _WS_KSи) и _BIN2_VSS._BIN

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

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

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

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

Различия в хранении между 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. Но он может содержать только пять символов в диапазоне 128–2047 и только три символа в диапазоне 2048–65535. Для сравнения, так как в столбце 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 байт, но японские символы требуют 3 байта при кодировании в UTF-8. Поэтому столбец должен быть определен как VARCHAR(270) во избежание потери данных в результате усечения.

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

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

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

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

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

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

См. также