SQL Server codage de caractères par défaut

Encodages

SQL Server stocke les données Unicode (c'est-à-dire ce qui se trouve dans le XML et N-types préfixés) dans UCS-2 / UTF-16 (le stockage est le même, UTF-16 ne traite que les caractères supplémentaires correctement). Ceci n'est pas configurable: il n'y a pas d'option pour utiliser L'UTF-8 ou L'UTF-32. Que les fonctions intégrées puissent ou non traiter correctement les caractères supplémentaires, et que ceux-ci soient ou non triés et comparés correctement, dépend de la Collation utilisée. Les anciennes Collations mettent tous les caractères supplémentaires sur un pied d'égalité. À partir de SQL Server 2005, ils ont introduit le 90 Collations en série (celles avec _90_ dans le nom) qui pourrait au moins faire une comparaison binaire sur les caractères supplémentaires afin que vous puissiez les différencier, même s'ils ne trient pas dans l'ordre désiré. C'est aussi vrai pour les 100 Collations en série introduites dans SQL Server 2008. SQL Server 2012 a introduit des Collations avec des noms se terminant en _SC cela permet non seulement de trier correctement les caractères supplémentaires, mais aussi de permettre aux fonctions intégrées de les interpréter comme prévu (c'est-à-dire de traiter la paire de substituts comme une seule entité). À partir de SQL Server 2017, Toutes les nouvelles Collations (la 140 série) supporte implicitement les caractères supplémentaires, il n'y a donc pas de nouvelles Collations avec des noms se terminant par _SC.

données Non Unicode (c.-à-d. ce qui se trouve dans le CHAR,VARCHAR et TEXT types - mais ne pas utiliser TEXT, utilisez VARCHAR(MAX) à la place) utilise un encodage 8 bits (ASCII étendu, DBCS, ou EBCDIC). Le jeu de caractères / encodage spécifique est basé sur la page de Code, qui à son tour est basée sur la Collation d'une colonne, ou la Collation de la base de données actuelle pour les littérales et les variables, ou la Collation de L'Instance pour les noms de variables / curseur et GOTO étiquettes, ou de ce qui est spécifié dans COLLATE clause si une clause est utilisée.

pour voir comment les locales correspondent les classements, découvrez:

• Nom De Classement Windows
• SQL Server Collation Name

pour voir la page de Code associée à une Collation particulière (ceci est le jeu de caractères et affecte seulement CHAR/VARCHAR/TEXT données), exécutez la commande suivante:

SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'CodePage' ) AS [CodePage];

pour voir le LCID (c.-à-d. locale) associé à une Collation particulière (ceci affecte les règles de tri et de comparaison), lancez le suivantes:

SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'LCID' ) AS [LCID];

pour voir la liste des Collations disponibles, ainsi que leurs Lcids et Pages de Code associés, Lancez:

SELECT [name],
       COLLATIONPROPERTY( [name], 'LCID' ) AS [LCID],
       COLLATIONPROPERTY( [name], 'CodePage' ) AS [CodePage]
FROM sys.fn_helpcollations()
ORDER BY [name];

par Défaut

avant de regarder les Collations par défaut du serveur et de la base de données, il faut comprendre l'importance relative de ces collations par défaut.

Le Serveur (Exemple, vraiment) Classement par défaut est utilisé comme valeur par défaut pour les nouvelles Bases de données (y compris le système de Bases de données: master,model, msdb et tempdb). Mais cela ne signifie pas qu'une base de données (autre que les 4 Systèmes DBs) utilise cette Collation. La compilation par défaut de la base de données peut être modifiée à tout moment. La compilation par défaut du serveur, cependant, n'est pas si facile à changer. Le serveur / Instance contrôle la compilation:

• noms des variables locales
• noms des curseur
• étiquettes GOTO

la compilation par défaut de la base de données est utilisée dans deux façons:

• comme valeur par défaut pour les nouvelles colonnes de chaînes de caractères. Mais cela ne signifie pas que n'importe quelle colonne de chaîne utilise cette Collation. Le Classement d'une colonne peut être modifié à tout moment. Ici, connaître la valeur par défaut de la base de données est important comme indication de ce à quoi les colonnes de chaînes de caractères sont le plus susceptibles d'être affectées.
• comme la compilation pour les opérations impliquant des littérales de chaîne, des variables et des fonctions intégrées qui ne prennent pas les entrées de chaîne mais produisent une sortie de chaîne (i.e. IF (@InputParam = 'something')). Ici, connaître la valeur par défaut de la base de données est certainement important car il régit le comportement de ces opérations.

la colonne Collation est spécifiée dans le COLLATE clause au moment de la CREATE TABLE ou un ALTER TABLE {table_name} ALTER COLUMN, ou si non spécifié, tiré de la base de données par défaut.

Puisqu'il y a plusieurs couches ici où une Collation peut être spécifiée (base de données par défaut / colonnes / littérales & variables), la Collation résultante est déterminée par Priorité De Classement.

tout cela étant dit, la requête suivante affiche les paramètres par défaut / courants pour L'OS, L'Instance SQL Server et la base de données spécifiée:

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;

UPDATE 2018-10-02

bien que ce ne soit pas encore une option viable, SQL Server 2019 introduit le support natif pour UTF-8 dans VARCHAR/CHAR les types de données. Il y a actuellement trop de bogues avec elle pour qu'elle puisse être utilisée, mais si ils sont fixes, alors c'est une option pour scénarios. Veuillez voir mon post "support natif UTF-8 dans SQL Server 2019: Sauveur ou faux prophète?", pour une analyse détaillée de cette nouvelle fonctionnalité.

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

où DBName est votre nom de base de données.

le codage de caractères par défaut pour une base de données SQL Server est iso_1, qui est ISO 8859-1. Notez que le codage des caractères dépend du type de données d'une colonne. Vous pouvez avoir une idée des encodages de caractères utilisés pour les colonnes dans une base de données ainsi que les collations en utilisant ce 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;

S'il utilise la valeur par défaut, le caractère _set_name devrait être iso_1 pour les types de données char et varchar. Étant donné que nchar et nvarchar stockent des données Unicode au format UCS-2, le character _set_name pour ces types de données est UNICODE.

je pense que ceci est digne d'une réponse séparée: bien que les données unicode internes soient stockées en tant qu'UTF-16 dans Sql Server c'est la petite saveur Endian, donc si vous appelez la base de données à partir d'un système externe, vous devez probablement spécifier UTF-16LE.