Кодировки
В большинстве случаев SQL Server хранит данные Unicode (то есть те, которые встречаются в типах с префиксом XML
и N
) в UCS-2 / UTF-16 (хранилище - этото же самое, UTF-16 просто корректно обрабатывает дополнительные символы).Это не настраивается: нет возможности использовать UTF-8 или UTF-32 (см. Раздел ОБНОВЛЕНИЕ в нижней части: UTF-8, начиная с SQL Server2019) .То, могут ли встроенные функции правильно обрабатывать дополнительные символы, и правильно ли они отсортированы и сопоставлены, зависит от используемой сортировки.Старые сопоставления - имена, начинающиеся с SQL_
(например, SQL_Latin1_General_CP1_CI_AS
) xor без номера версии в имени (например, Latin1_General_CI_AS
) - приравнивают все дополнительные символы друг к другу (из-за отсутствия веса сортировки).Начиная с SQL Server 2005, они представили сопоставления серии 90
(с именами _90_
), которые могли бы по крайней мере выполнить двоичное сравнение с дополнительными символами, чтобы вы могли различать их, даже если они не сортировались вжелаемый заказ.Это также справедливо для сортировок серии 100
, представленных в SQL Server 2008. В SQL Server 2012 введены сопоставления с именами, заканчивающимися на _SC
, которые не только правильно сортируют дополнительные символы, но и позволяют встроенным функциям интерпретировать их должным образом.(то есть рассматривая суррогатную пару как единое целое).Начиная с SQL Server 2017, все новые параметры сортировки (серия 140
) неявно поддерживают дополнительные символы , поэтому новых сопоставлений с именами, заканчивающимися на _SC
.
, не существует, начиная с SQLСервер 2019, UTF-8 стал поддерживаемой кодировкой для данных CHAR
и VARCHAR
(столбцы, переменные и литералы), но не TEXT
(см. Раздел UPDATE в нижней части: UTF-8, начиная с SQL Server 2019) .
Данные не в Юникоде (то есть те, которые встречаются в типах CHAR
, VARCHAR
и TEXT
- но неиспользуйте TEXT
, используйте VARCHAR(MAX)
вместо) использует 8-битное кодирование (Extended ASCII, DBCS или EBCDIC).Конкретный набор символов / кодировка основывается на кодовой странице, которая, в свою очередь, основана на сопоставлении столбца, или сопоставлении текущей базы данных для литералов и переменных, или сопоставлении экземпляра для имен переменных / курсоров и GOTO
меток или то, что указано в предложении COLLATE
, если оно используется.
Чтобы увидеть, как локали соответствуют параметрам сортировки, проверьте:
Просмотр кодовой страницы, связанной с определенным набором параметров (это набор символов и влияет только наCHAR
/ VARCHAR
/ TEXT
data), выполните следующее:
SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'CodePage' ) AS [CodePage];
Чтобы увидеть LCID (т. Е. Языковой стандарт), связанный с определенным сопоставлением (это влияет на правила сортировки и сравнения),выполните следующее:
SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'LCID' ) AS [LCID];
Чтобы просмотреть список доступных параметров сортировки, а также связанные с ними LCID и кодовые страницы, выполните:
SELECT [name],
COLLATIONPROPERTY( [name], 'LCID' ) AS [LCID],
COLLATIONPROPERTY( [name], 'CodePage' ) AS [CodePage]
FROM sys.fn_helpcollations()
ORDER BY [name];
Значения по умолчанию
Перед просмотромв тПо умолчанию параметры сортировки сервера и базы данных следует понимать относительную важность этих значений по умолчанию.
Параметры сортировки по умолчанию для сервера (на самом деле) используются по умолчанию для вновь создаваемых баз данных (включая системные базы данных: master
).model
, msdb
и tempdb
).Но это не означает, что любая база данных (кроме 4-х системных БД) использует это сопоставление.Параметры сортировки по умолчанию для базы данных могут быть изменены в любое время (хотя существуют зависимости, которые могут помешать базе данных изменить параметры сортировки).Однако параметры сортировки по умолчанию на сервере изменить не так просто.Подробнее об изменении всех параметров сортировки см. Изменение параметров сортировки экземпляра, баз данных и всех столбцов во всех пользовательских базах данных: что может быть неправильным?
Сервер / экземплярЭлементы управления сортировкой:
- локальная переменная имена
CURSOR
имена GOTO
метки - метаданные уровня экземпляра
Сортировка по умолчанию для базы данных используется тремя способами:
- по умолчанию для вновь создаваемых строковых столбцов.Но это не означает, что любой строковый столбец использует это сопоставление.Сортировка столбца может быть изменена в любое время.Здесь знание базы данных по умолчанию является важным показателем того, какие строковые столбцы, скорее всего, установлены.
- в качестве параметров сортировки для операций, включающих строковые литералы, переменные и встроенные функции, которые не принимают строковые входы, нопроизводит вывод строки (то есть
IF (@InputParam = 'something')
).Здесь знание базы данных по умолчанию определенно важно, поскольку она определяет, как эти операции будут себя вести. - Метаданные уровня базы данных
Столбец Collation указывается либо в предложении COLLATE
во время CREATE TABLE
или ALTER TABLE {table_name} ALTER COLUMN
, или, если не указано, взято из базы данных по умолчанию.
Поскольку здесь есть несколько слоев, в которых можно указать параметры сортировки (база данных по умолчанию / столбцы / литералыи переменные), результирующая сортировка определяется как Приоритет сортировки .
. При этом в следующем запросе отображаются текущие настройки по умолчанию для операционной системы, экземпляра SQL Server и указаныБаза данных:
SELECT os_language_version,
---
SERVERPROPERTY('LCID') AS 'Instance-LCID',
SERVERPROPERTY('Collation') AS 'Instance-Collation',
SERVERPROPERTY('ComparisonStyle') AS 'Instance-ComparisonStyle',
SERVERPROPERTY('SqlSortOrder') AS 'Instance-SqlSortOrder',
SERVERPROPERTY('SqlSortOrderName') AS 'Instance-SqlSortOrderName',
SERVERPROPERTY('SqlCharSet') AS 'Instance-SqlCharSet',
SERVERPROPERTY('SqlCharSetName') AS 'Instance-SqlCharSetName',
---
DATABASEPROPERTYEX(N'{database_name}', 'LCID') AS 'Database-LCID',
DATABASEPROPERTYEX(N'{database_name}', 'Collation') AS 'Database-Collation',
DATABASEPROPERTYEX(N'{database_name}', 'ComparisonStyle') AS 'Database-ComparisonStyle',
DATABASEPROPERTYEX(N'{database_name}', 'SQLSortOrder') AS 'Database-SQLSortOrder'
FROM sys.dm_os_windows_info;
Установка по умолчанию
Другая интерпретация «по умолчанию» может означать, какая сортировка по умолчанию выбрана для сортировки на уровне экземпляра при установке.Это зависит от языка ОС, но (ужасно, ужасно) по умолчанию SQL_Latin1_General_CP1_CI_AS
.И в этом случае кодировка «по умолчанию» - это кодовая страница Windows 1252 для данных VARCHAR
и, как всегда, UTF-16 для данных NVARCHAR
.
ОБНОВЛЕНИЕ 2018-10-02
SQL Server 2019 представляет встроенную поддержку UTF-8 в типах данных VARCHAR
/ CHAR
(не TEXT
!).Это достигается с помощью набора новых параметров сортировки, имена которых заканчиваются на _UTF8
.Это интересная возможность, которая определенно поможет некоторым людям, но с ней есть некоторые «причуды», особенно когда UTF-8 не используется для всех столбцов и параметров сортировки базы данных по умолчанию, поэтому не делайтеНе используйте его только потому, что вы слышали, что UTF-8 волшебно лучше.UTF-8 был разработан исключительно для совместимости с ASCII: чтобы позволить системам только ASCII (то есть UNIX назад) поддерживать Unicode без изменения какого-либо существующего кода или файлов.То, что он экономит место для данных, используя в основном (или только) символы английского языка США (и некоторые знаки пунктуации), является побочным эффектом.Если не используются в основном (или только) символы английского языка США, данные могут иметь тот же размер, что и UTF-16, или даже больше, в зависимости от того, какие символы используются.Кроме того, в случае экономии места производительность может улучшиться, но может ухудшиться.
Подробный анализ этой новой функции см. В моем сообщении " Поддержка Native UTF-8в SQL Server 2019: Спаситель или Лжепророк?".