Чтобы расширить @ ответ Мартина:
Способ установки «набора символов» в SQL Server зависит от типа данных, который вы используете. Если вы используете:
NVARCHAR, NCHAR и NTEXT (NTEXT устарело и не должно использоваться с SQL Server 2005) - все они используют набор символов Unicode, и это нельзя изменить. Все эти типы данных кодируются как UTF-16 LE (Little Endian) - ndash; 16-битная кодировка, каждый из которых содержит 2 или 4 байта - & ndash; и это тоже нельзя изменить. Для этих типов данных используемое сопоставление влияет только на локаль (как определено LCID сопоставления), которая определяет набор правил, используемых для сортировки и сравнения.
XML, как и типы с префиксом N, использует набор символов Unicode и кодируется как UTF-16 LE (Little Endian), и ни один из них не может быть изменен. Но в отличие от других типов строковых данных, нет сопоставления, связанного с данными XML, поскольку их невозможно отсортировать или сравнить (по крайней мере, без предварительного преобразования их в NVARCHAR(MAX) [предпочтительный] или VARCHAR(MAX)).
VARCHAR, CHAR и TEXT (TEXT устарело и не должно использоваться с SQL Server 2005) - все это 8-битные кодировки с каждым «символом», равным 1 или 2 байта. Набор символов определяется кодовой страницей, связанной с каждым сопоставлением. Правила сортировки и сравнения зависят от типа используемой сортировки:
- Параметры SQL Server. Все они имеют имена, начинающиеся с
SQL_, и устарели с SQL Server 2000, хотя (к сожалению) все еще широко используются сегодня. Они используют простые правила, обозначенные как «порядок сортировки SQL Server», как указано в поле description, возвращаемом sys.fn_helpcollations().
- Windows Collations: все они имеют имена, которые не начинаются с
SQL_. Эти параметры сортировки позволяют строковым данным, не относящимся к Unicode, использовать правила сортировки и сравнения Unicode, указанные в LCID для параметров сортировки.
При этом, чтобы выяснить, какой набор символов (для CHAR, VARCHAR и TEXT - т.е. не-Unicode - данные) используется, выполните следующий запрос и обратите пристальное внимание на поле CodePage. Поле LCID указывает локаль, используемую для правил сортировки и сравнения для N с префиксом & ndash; то есть Unicode & ndash; типы, а также не-Unicode типы , если с использованием Windows Collation:
SELECT *,
COLLATIONPROPERTY(col.[name], 'CodePage') AS [CodePage],
COLLATIONPROPERTY(col.[name], 'LCID') AS [LCID]
FROM sys.fn_helpcollations() col
ORDER BY col.[name];
Идентификаторы кодовой страницы можно перевести в нечто более значимое через страницу MSDN для Идентификаторы кодовой страницы .
Относительно комментария О.П. к ответу @ Мартина:
К сожалению, они выбрали вводящий в заблуждение / неполный термин «сопоставление», которое явно относится к порядку сортировки: определение сопоставления.
Несмотря на то, что Microsoft могла бы добиться большего успеха при выборе имени, к сожалению, существует общая, общеотраслевая путаница в отношении таких терминов, как «кодировка», «набор символов», «сопоставление» и т. Д. Использование Microsoft ( или неправильное использование) "Сличения" просто способствовало массовой путанице. Но эта путаница также очевидна в MySQL, как показано в этом вопросе, учитывая, что «utf8» определенно не набор символов; -).
UTF-8 является одной из нескольких кодировок для набора символов Unicode.UTF-16 и UTF-32 являются двумя другими кодировками.Все три из этих кодировок представляют один и тот же набор символов Unicode, просто по-разному.Глядя на список наборов символов MySQL - 11.1.10 Поддерживаемые наборы символов и сопоставления - наборы символов "ucs2", "utf8", "utf8mb4", "utf16", "utf16le", "utf32"на самом деле не наборы символов, а различные представления набора символов Unicode.Но, учитывая совпадение понятий «набор символов» и «кодировка», было бы трудно не иметь такой путаницы.Страница 11.1.10.1 наборов символов Unicode указывает, что кодировки "utf8mb4", "utf16", "utf16le" и "utf32" являются полными наборами символов Unicode, тогда как "ucs2" и "utf8" являются подмножествамииз набора символов Unicode, а именно первые 65 536 кодовых точек (или Базовая многоязычная плоскость (BMP)).
Для получения дополнительной информации о сопоставлении между различными СУБД см. мой ответ на следующий вопрос о DBA.StackExchange:
Имеется ли в какой-либо СУБД сортировка с учетом регистра и без акцента?
ОБНОВЛЕНИЕ 2018-10-02
Хотя этот вариант пока не подходит, в SQL Server 2019 появилась встроенная поддержка UTF-8 в типах данных VARCHAR / CHAR.В настоящее время в нем слишком много ошибок, чтобы его можно было использовать, но если они исправлены, то это вариант для некоторых сценариев.Пожалуйста, смотрите мой пост " Собственная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк? ", для подробного анализа этой новой функции.