Поддержка параметров сортировки и Юникода
Область применения:
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.
При выборе параметров сортировки для сервера, базы данных, столбца или выражения данным присваиваются определенные характеристики. Они влияют на многие операции в базе данных. Например, при создании запроса с помощью ORDER BYпорядок сортировки результирующего набора может зависеть от коллации, примененной к базе данных, или определенных в предложении COLLATE на уровне выражения запроса.
Чтобы лучше использовать поддержку сортировки в SQL Server, следует понимать термины, определенные в этой статье, и как они связаны с характеристиками данных.
Термины сортировки
Параметры сортировки
Параметры сортировки задают битовые шаблоны, представляющие каждый символ в наборе данных. Параметры сортировки определяют правила, используемые при сортировке и сравнении данных. SQL Server поддерживает хранение объектов с различными параметрами сортировки в одной базе данных. Для столбцов в кодировке, отличающейся от Юникода, настройка параметров сортировки определяет кодовую страницу данных и соответствующую возможность представления символов. Данные, которые перемещаются между столбцами в форматах, отличных от Юникода, необходимо преобразовывать из исходной кодовой страницы в целевую.
Результаты инструкции Transact-SQL могут различаться при выполнении инструкции в контексте разных баз данных, имеющих разные параметры сортировки. По возможности используйте стандартные параметры сортировки для всей организации. Тем самым не придется указывать параметры сортировки для каждого символа или выражения Юникода. Если необходимо работать с объектами, имеющими различные параметры сортировки и кодовые страницы, создание запросов должно производиться с учетом очередности параметров сортировки. Дополнительные сведения см. в разделе приоритет сортировки.
Параметры сортировки могут учитывать регистр, диакритические знаки, тип японской азбуки, ширину символов и знаки выбора варианта. В SQL Server 2019 (15.x) представлен дополнительный параметр кодирования UTF-8 .
Эти параметры можно задать путем их добавления к имени параметров сортировки. Например, сортировка Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 чувствительна к регистру, к акцентам, к кана, к ширине и использует кодировку UTF-8. В качестве другого примера параметры сортировки Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS являются нечувствительными к регистру, нечувствительными к символам, kana-sensitive, width-selector-sensitive, и он использует устаревшую кодовую страницу для varchar.
В приведенной ниже таблице описывается режим работы, связанный с этими параметрами.
| Вариант | Описание |
|---|---|
| С учетом регистра (_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). Подсистемы интеграции XML и среды CLR в SQL Server не поддерживают селекторы вариаций (_VSS). |
| Двоичный (_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 .
Параметры двоичной сортировки
При двоичных параметрах сортировки данные сортируются на основе последовательности закодированных значений, определяемых локалью и типом данных. Эти параметры учитывают регистр. Двоичная сортировка в SQL Server определяет используемый языковой стандарт и кодовую страницу ANSI. При этом принудительно реализуется двоичный порядок сортировки. По причине своей относительной простоты параметры двоичной сортировки помогают повысить производительность приложений. Для типов данных не в Юникоде сравнение данных производится на основе кодовых точек, определенных в кодовой странице ANSI. Типы данных в Юникоде сравниваются на основе элементов кода Юникода. Для параметров двоичной сортировки на основе типов данных Юникода при сортировке данных языковой стандарт не учитывается. Например, Latin1_General_BIN и Japanese_BIN дают идентичные результаты сортировки при использовании в данных Юникода. Дополнительные сведения см. в имени сортировки Windows .
В SQL Server существует два типа двоичных параметров сортировки:
Устаревшие сопоставления
BIN, которые выполняли неполное посимвольное сравнение для данных Юникода. Устаревшие двоичные параметры сортировки сравнивают первый символ как WCHAR, за которым следует сравнение байтов по байтам. При использовании параметров сортировки BIN только первый символ сортируется в соответствии с кодовой точкой. Остальные символы сортируются в соответствии с их значениями байта.Новые сортировки
BIN2, реализующие чистое сравнение кодовых точек. При использовании параметров сортировки BIN2 все символы сортируются в соответствии с их кодовыми точками. Так как платформа Intel не всегда является архитектурой по порядку следования байтов, символы кода Unicode всегда хранятся с перестановкой байтов.
Параметры сортировки SQL Server
Параметры сортировки SQL Server (SQL_*) обеспечивают совместимость порядка сортировки с более ранними версиями SQL Server. Правила сортировки словаря для данных в формате, отличном от Юникода, не совместимы ни с какими подпрограммами сортировки операционных систем Windows. Однако сортировка данных в Юникоде совместима с правилами сортировки определенной версии Windows. Так как параметры сортировки SQL Server используют разные правила сравнения для данных, отличных от Юникода и Юникода, в зависимости от базового типа данных отображаются разные результаты для сравнения одних и того же данных.
Например, если вы используете сортировку SQL SQL_Latin1_General_CP1_CI_AS, неюникодовая строка 'a-c' меньше строки 'ab', так как дефис (-) отсортирован как отдельный символ, который расположен перед b. Однако если вы преобразуете эти строки в Юникод и выполняете то же сравнение, строка N'a-c' Юникода считается большей N'ab', так как правила сортировки Юникода используют сортировку слов, которая игнорирует дефис.
Для получения дополнительной информации см. Имя сортировки SQL Server.
Во время установки SQL Server параметр сортировки установки по умолчанию определяется языковым стандартом операционной системы (ОС). Параметры сортировки уровня сервера можно изменить в процессе установки. Кроме того, их можно изменить, сменив языковой стандарт ОС перед установкой. В целях обратной совместимости для параметров сортировки по умолчанию устанавливается самая старая доступная версия, связанная с определенным языковым стандартом. В связи с этим данные параметры сортировки рекомендуется использовать не во всех случаях. Чтобы воспользоваться всеми преимуществами функций SQL Server, измените параметры установки по умолчанию, чтобы использовать параметры сортировки Windows. Например, для языкового стандарта ОС "Английский (США)" (кодовая страница 1252) параметры сортировки по умолчанию во время установки — это SQL_Latin1_General_CP1_CI_AS, который можно заменить на ближайший аналог сортировки Windows — Latin1_General_100_CI_AS_SC.
При обновлении экземпляра SQL Server на английском языке можно указать параметры сортировки SQL Server (SQL_*) для совместимости с существующими экземплярами SQL Server. Так как параметры сортировки по умолчанию для экземпляра SQL Server определены во время установки, убедитесь, что параметры сортировки указаны тщательно, если указаны следующие условия:
- Код приложения зависит от поведения предыдущих параметров сортировки SQL Server.
- Необходимо хранить символьные данные, в которых используется несколько языков.
Уровни параметров сортировки
Параметры сортировки поддерживаются на следующих уровнях экземпляра SQL Server:
- Параметры сортировки уровня сервера
- Параметры сортировки уровня базы данных
- Параметры сортировки уровня столбцов
- Параметры сортировки уровня выражений
Параметры сортировки уровня сервера
Параметры сортировки сервера по умолчанию определяются во время установки SQL Server, а параметры сортировки по умолчанию — системные базы данных и все пользовательские базы данных.
В приведенной ниже таблице представлены параметры сортировки по умолчанию, определяемые языковым стандартом операционной системы (ОС), включая коды языков (LCID) в Windows и SQL.
| Локаль Windows | Код языка в Windows | Код языка 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.
Параметры сортировки пользовательской базы данных можно изменить с помощью 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
Кроме того, начиная с 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. Это определение позволяет Юникоду представлять 1114 112 символов (т. е. 216 * 17 символов) в диапазоне точек кода 000000 – 10FFFF. Символы с значением точки кода, превышающим 00FFFF, требуют двух-четырех последовательных 8-разрядных слов (UTF-8) или двух последовательных 16-разрядных слов (UTF-16). Эти символы, находящиеся вне BMP, называются дополнительными символами, а дополнительные последовательные 8-разрядные или 16-разрядные слова — суррогатной парой. Дополнительные сведения о дополнительных символах, суррогатах и суррогатных парах см . в стандарте Юникода.
SQL Server предоставляет такие типы данных, как nchar и nvarchar для хранения данных Юникода в диапазоне BMP (000000 – 00FFFF), который СУБД кодирует с использованием кодировки UCS-2.
В SQL Server 2012 (11.x) было введено новое семейство дополнительных символьных параметров сортировки (_SC), которые можно использовать с типами данных nchar, nvarcharи sql_variant для представления полного диапазона символов Юникода (000000 – 10FFFF). Например, Latin1_General_100_CI_AS_SC или, если вы используете японскую сортировку, Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x) расширяет дополнительную поддержку символов для типов данных char и varchar с новыми включенными параметрами сортировки UTF-8 (_UTF8). Эти типы данных также способны представлять полный диапазон символов Юникода.
Примечание.
Начиная с 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 – 0xFFFF. |
|
Шаблон — совпадение одного символа Шаблон — несовпадающие символы |
Дополнительные символы поддерживаются для всех операций с символами-шаблонами. | Дополнительные символы не поддерживаются для этих операций с символами-шаблонами. Поддерживаются другие операторы символов-шаблонов. |
поддержка 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
Начиная с SQL Server 2017 (14.x), поддерживаются новые семейства параметров сортировки на японском языке, а также различные варианты (_CS, _AS, _KS_WSи) и _VSS_BIN._BIN2
Чтобы получить список этих параметров сортировки, можно выполнить запрос к ядру СУБД SQL Server:
SELECT name,
description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Все новые сопоставления имеют встроенную поддержку дополнительных символов, поэтому ни одно из новых сопоставлений 140 не имеет (и не нуждается в) флаге SC.
Эти параметры сортировки поддерживаются в индексах ядра СУБД, оптимизированных для памяти таблицах, индексах columnstore и модулях, скомпилированных в собственном коде.
Поддержка UTF-8
SQL Server 2019 (15.x) предоставляет полную поддержку широко используемой кодировки символов UTF-8 в качестве кодировки импорта или экспорта, а также в качестве параметров сортировки на уровне базы данных или столбцов для строковых данных. Кодировка символов UTF-8 допускается в типах данных char и varchar. Она активируется при создании параметров сортировки с суффиксом UTF8 или изменении существующих параметров на таковые. Одним из примеров является изменение Latin1_General_100_CI_AS_SC на Latin1_General_100_CI_AS_SC_UTF8.
UTF-8 доступен только для параметров сортировки Windows, поддерживающих дополнительные символы, как представлено в SQL Server 2012 (11.x). Типы данных nchar и nvarchar допускают только кодировку UCS-2 или UTF-16 и остаются неизменными.
База данных SQL Azure и Управляемый экземпляр SQL Azure также поддерживают UTF-8 на уровне базы данных и столбцов, а Управляемый экземпляр SQL также поддерживает это на уровне сервера.
Различия в хранении между UTF-8 и UTF-16
Консорциум Юникода выделяет каждому символу уникальную кодовую точку, которая является значением в диапазоне 000000 – 10FFFF. При использовании SQL Server 2019 (15.x) доступны кодировки UTF-8 и UTF-16 для представления полного диапазона:
- При кодировке UTF-8 символы в диапазоне ASCII (000000 – 00007F) требуют 1 байта, кодовые точки 00080 – 0007FF требуют 2 байта, кодовые точки 000800 – 00FFFF требуют 3 байта, а точек кода 0001000 – 0010FFFF требуется 4 байта.
- При кодировке UTF-16 кодовые точки 000000 – 000FF требуют 2 байта, а кодовые точки 0010000 – 0010FFFF требуют 4 байта.
В таблице ниже приведены байты хранения кодировки для каждого диапазона символов и типа кодировки.
| Диапазон кодов (шестнадцатеричный) | Диапазон кодов (десятичный) | Байты хранения 1 с использованием кодировки UTF-8 | Байты хранения 1 с кодировкой UTF-16 |
|---|---|---|---|
| 000000 – 00007F | 0 - 127 | 1 | 2 |
| 000080 – 00009F 0000A0 – 0003FF 000400 – 0007FF |
128 - 159 160 - 1,023 1,024 - 2,047 |
2 | 2 |
| 000800 – 003FFF 004000 – 00FFFF |
2,048 - 16,383 16,384 - 65,535 |
3 | 2 |
| 010000 - 03FFFF 2 040000 – 10FFFF 2 |
65 536 - 262 143 2 262 144 - 1 114 111 2 |
4 | 4 |
1байт хранилища ссылаются на длину закодированного байта, а не размер хранилища типа данных на диске. Дополнительные сведения об объеме хранения на диске см. в статьях о nchar и nvarchar и char и varchar.
2 Диапазон кодовых точек для дополнительных символов.
Совет
Это общее восприятие, в char и varchar или в nchar и nvarchar, что n определяет количество символов. Это связано с тем, что в примере столбца char(10) 10 символов ASCII в диапазоне 0 – 127 можно хранить с помощью сортировки, например Latin1_General_100_CI_AI, так как каждый символ в этом диапазоне использует только 1 байт. Однако в char и varcharn определяет размер строки в байтах (0 – 8000), а в nchar и nvarcharn определяет размер строки в байтовых пар (0 – 4000).
n никогда не определяет количество хранимых символов.
Выбор подходящей кодировки Юникода и типа данных может привести к значительной экономии пространства или увеличению текущего объема хранилища в зависимости от используемого набора символов. Например, при использовании латинской сортировки с поддержкой UTF-8, такой как Latin1_General_100_CI_AI_SC_UTF8, столбец char(10) хранит 10 байтов и может содержать 10 символов ASCII в диапазоне от 0 до 127. Но он может содержать только пять символов в диапазоне 128 – 2047 и только три символа в диапазоне 2048 – 65535. По сравнению с тем, что столбец nchar(10) хранит 10 байтовых пар (20 байтов), он может содержать 10 символов в диапазоне 0 – 65535.
Прежде чем решить, следует ли использовать кодировку UTF-8 или UTF-16 для базы данных или столбца, рассмотрите распределение строковых данных, которые будут храниться:
- Если диапазон в основном ASCII 0–127 (например, английский язык), каждый символ требует 1 байт с UTF-8 и 2 байта с UTF-16. Использование UTF-8 сокращает объем хранения. Изменение существующего типа данных столбца с символами ASCII в диапазоне 0 – 127 с nchar(10) на char(10)и использование включенной сортировки UTF-8 преобразуется в 50 процентов сокращения требований к хранилищу. Это сокращение связано с тем, что nchar(10) требует 20 байт для хранения, по сравнению с char(10), что требует 10 байт для того же представления строки Юникода.
- Над диапазоном ASCII почти все латинские скрипты, а также греческий, кириллический, коптский, армянский, иврит, арабский, Сирик, Тана и Н'Ко, требуют 2 байта на символ в UTF-8 и UTF-16. В этих случаях нет существенных различий в хранилище для сопоставимых типов данных (например, между использованием char или nchar).
- Если будут использоваться преимущественно восточноазиатские языки (например, корейский, китайский и японский), каждому символу потребуется 3 байта в UTF-8 и 2 байта в UTF-16. В этом случае использование UTF-16 позволяет сократить объем хранения.
- Символы в диапазоне 010000 – 10FFFF требуют 4 байта в UTF-8 и UTF-16. В этих случаях нет различий в хранилище для сопоставимых типов данных (например, между использованием char или nchar).
Сведения о других факторах, которые необходимо учитывать, см. в статье Написание инструкций Transact-SQL, адаптированных к международному использованию.
Преобразование в UTF-8
Так как в char и varchar или в nchar и nvarchar, n определяет размер хранилища байтов, а не количество символов, которые можно сохранить, важно определить размер типа данных, в который необходимо преобразовать. Символы, превышающие размер, должны быть усечены.
Например, рассмотрим столбец, определенный как nvarchar(100), который хранит 180 байт японских символов. В этом примере данные столбца в настоящее время кодируются с помощью UCS-2 или UTF-16, где используется 2 байта на символ. Преобразование типа столбца в varchar(200) недостаточно для предотвращения усечения данных, так как новый тип данных может хранить только 200 байт, но японские символы требуют 3 байта при кодировании в UTF-8. Столбец должен быть определен как varchar(270), чтобы избежать потери данных путем усечения данных.
Поэтому перед преобразованием существующих данных в UTF-8 необходимо заранее знать, какой размер проецируемого байта соответствует определению столбца, а затем соответствующим образом настроить размер нового типа данных. Ознакомьтесь со скриптом Transact-SQL или записной книжкой SQL в примерах данных GitHub, которые используют функцию DATALENGTH и инструкцию COLLATE, чтобы определить соответствующие требования к длине данных для операций преобразования UTF-8 в существующей базе данных.
Чтобы изменить параметры сортировки столбца и тип данных в существующей таблице, используйте один из методов, описанных в разделе Задание или изменение параметров сортировки столбца.
Для изменения параметров сортировки базы данных, позволяющих новым объектам наследовать параметры сортировки базы данных по умолчанию или изменять параметры сортировки сервера, чтобы новые базы данных по умолчанию наследовали системные параметры сортировки, см. раздел Связанные задачи этой статьи.
Связанные задачи
| Задача | Статья |
|---|---|
| Описание задания или изменения параметров сортировки экземпляра SQL Server. Изменение параметров сортировки сервера не изменяет параметры сортировки существующих баз данных. | Задать или изменить параметры сортировки сервера |
| Описание задания или изменения параметров сортировки пользовательской базы данных. Изменение параметров сортировки базы данных не изменяет параметры сортировки существующих столбцов таблицы. | Задать или изменить параметры сортировки базы данных |
| Описывает, как задать или изменить параметры сортировки столбца в базе данных. | Задание или изменение параметров сортировки столбца |
| Описывает, как возвращать сведения о сортировке на уровне сервера, базы данных или столбца. | Просмотр сведений о параметрах сортировки |
| Определяет, как писать операторы Transact-SQL, которые легче адаптируются для разных языков или легче поддерживают несколько языков. | Написание инструкций Transact-SQL, адаптированных к международному использованию |
| Описывает, как изменить язык сообщений об ошибках и настроек для использования и отображения данных даты, времени и валюты. | Задание языка сеанса |
Связанный контент
- Рекомендованные изменения параметров сортировки SQL Server
- Использовать формат символов Юникода для импорта или экспорта данных (SQL Server)
- Написание инструкций Transact-SQL, адаптированных к международному использованию
- Рекомендации SQL Server по лучшим практикам миграции на Юникод
- Консорциум Юникод
- Стандарт Юникод
- Поддержка UTF-8 в OLE DB Driver for SQL Server
- Имя параметров сортировки SQL Server (Transact-SQL)
- имя сортировки Windows (Transact-SQL)
- Общие сведения о поддержке UTF-8 в SQL Server
- COLLATE (Transact-SQL)
- приоритет сортировки
- Встроенные параметры сортировки базы данных
- Выбор языка при создании полнотекстового индекса
- sys.fn_helpcollations (Transact-SQL)
- Однобайтовые и многобайтовые кодировки