Кодировка символов по умолчанию SQL Server

По умолчанию - какова кодировка символов для базы данных в Microsoft SQL Server?

Как я могу увидеть текущую кодировку символов в SQL Server?

Ответ 1

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

SELECT SERVERPROPERTY('Collation')

Это сортировка сервера для экземпляра SQL Server, который вы используете.

Ответ 2

Кодировки

В большинстве случаев SQL Server хранит данные Unicode (то есть те, которые находятся в типах XML и N -prefixed) в UCS-2/UTF-16 (хранилище такое же, UTF-16 просто корректно обрабатывает дополнительные символы). Это не настраивается: нет возможности использовать ~~или UTF-8 или~~ UTF-32 ^{(см. Раздел ОБНОВЛЕНИЕ внизу re: UTF-8, начиная с SQL Server 2019)}. То, могут ли встроенные функции правильно обрабатывать дополнительные символы, и правильно ли они отсортированы и сопоставлены, зависит от используемой сортировки. Старые сопоставления - имена, начинающиеся с SQL_ (например, SQL_Latin1_General_CP1_CI_AS) или без номера версии в имени (например, Latin1_General_CI_AS) - приравнивают все дополнительные символы друг к другу (из-за отсутствия веса сортировки). Начиная с SQL Server 2005, они представили параметры сортировки 90 серии (с _90_), которые могли бы по крайней мере выполнить двоичное сравнение с дополнительными символами, чтобы вы могли различать их, даже если они сортировались не в нужном порядке. Это также справедливо для сортировок серии 100 представленных в SQL Server 2008. В SQL Server 2012 введены сопоставления с именами, заканчивающимися на _SC которые не только правильно сортируют дополнительные символы, но и позволяют встроенным функциям интерпретировать их должным образом (т. _SC суррогатная пара как единое целое). Начиная с SQL Server 2017, все новые сопоставления (серия 140) неявно поддерживают дополнительные символы, поэтому новых сопоставлений с именами, заканчивающимися на _SC.

Начиная с SQL Server 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), выполните следующее:

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];

Значения по умолчанию

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

msdb по умолчанию для сервера (Экземпляр, действительно) используется по умолчанию для вновь создаваемых баз данных (включая системные базы данных: master, model, msdb и tempdb). Но это не означает, что любая база данных (кроме 4-х системных БД) использует это сопоставление. Сортировка базы данных по умолчанию может быть изменена в любое время (хотя существуют зависимости, которые могут помешать базе данных изменить сопоставление базы данных). Однако параметры сортировки по умолчанию на сервере изменить не так просто. Подробнее об изменении всех параметров сортировки см. В разделе " Изменение параметров сортировки экземпляра, баз данных и всех столбцов во всех пользовательских базах данных: что может быть неправильным?"

Сервер /Instance Collation контролирует:

имена локальных переменных
Имена 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 для данных VARCHAR и, как всегда, UTF-16 для данных NVARCHAR.

ОБНОВЛЕНИЕ 2018-10-02

SQL Server 2019 представляет встроенную поддержку UTF-8 в VARCHAR данных VARCHAR/CHAR (не TEXT !). Это достигается с помощью набора новых параметров сортировки, имена которых заканчиваются на _UTF8. Это интересная возможность, которая определенно поможет некоторым людям, но есть некоторые "причуды" с этим, особенно когда UTF-8 не используется для всех столбцов и Сортировка базы данных по умолчанию, поэтому не используйте ее только потому, что вы слышал, что UTF-8 волшебно лучше. UTF-8 был разработан исключительно для совместимости с ASCII: чтобы позволить системам только ASCII (то есть UNIX назад) поддерживать Unicode без изменения какого-либо существующего кода или файлов. То, что он экономит место для данных, используя в основном (или только) символы английского языка США (и некоторые знаки пунктуации), является побочным эффектом. Если не используются в основном (или только) символы английского языка США, данные могут иметь тот же размер, что и UTF-16, или даже больше, в зависимости от того, какие символы используются. Кроме того, в случаях экономии места производительность может улучшиться, но может ухудшиться.

Подробный анализ этой новой функции см. В моем сообщении " Поддержка нативного UTF-8 в SQL Server 2019: Спаситель или Лжепророк? ".

Ответ 3

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

select data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name, count(*) count
from information_schema.columns
group by data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name;

Если он использует значение по умолчанию, имя_файла_имя должно быть iso_1 для типов данных char и varchar. Так как nchar и nvarchar хранят данные Unicode в формате UCS-2, для этих типов данных имя_имя_имя_имя_собывает UNICODE.

Ответ 4

SELECT DATABASEPROPERTYEX('DBName', 'Collation') SQLCollation;

Где DBName - ваше имя базы данных.

Ответ 5

Я думаю, что это заслуживает отдельного ответа: хотя внутренние данные Юникода хранятся как UTF-16 на Sql Server, это оттенок Little Endian, поэтому, если вы вызываете базу данных из внешней системы, вам, вероятно, нужно укажите UTF-16LE.