Prise en charge d’Unicode et du classement

Les classements dans SQL Server fournissent les règles de tri et les propriétés de respect de la casse et des accents pour vos données. Les classements utilisés avec des types de données caractères, tels que char et varchar, déterminent la page de codes et les caractères correspondants pouvant être représentés pour ce type de données. Que vous installiez une nouvelle instance de SQL Server, restauriez une sauvegarde de base de données ou connectiez le serveur aux bases de données clientes, il est important de comprendre les exigences locales, l’ordre de tri, ainsi que la sensibilité à la casse et aux accents des données que vous allez utiliser. Pour répertorier les classements disponibles sur votre instance de SQL Server, consultez sys.fn_helpcollations (Transact-SQL).

Lorsque vous sélectionnez un classement pour votre serveur, base de données, colonne ou expression, vous affectez certaines caractéristiques à vos données qui affecteront les résultats de nombreuses opérations dans la base de données. Par exemple, lorsque vous construisez une requête à l’aide de ORDER BY, l’ordre de tri de votre jeu de résultats peut dépendre du classement appliqué à la base de données ou dicté dans une clause COLLATE au niveau de l’expression de la requête.

Pour mieux utiliser la prise en charge des classements dans SQL Server, vous devez comprendre les termes définis dans cette rubrique et la façon dont ils sont liés aux caractéristiques de vos données.

Classement

Un classement spécifie les modèles de bits qui représentent chaque caractère dans un jeu de données. Les classements déterminent également les règles de tri et de comparaison des données. SQL Server prend en charge le stockage d’objets ayant des classements différents dans une même base de données. Pour les colonnes non-Unicode, le paramètre de classement spécifie la page de codes pour les données et les caractères qui peuvent être représentés. Les données déplacées entre les colonnes non Unicode doivent être converties de la page de codes source vers la page de codes de destination.

Le résultat d'une instruction Transact-SQL peut varier lorsque cette dernière est exécutée dans un contexte réunissant plusieurs bases de données dont chacune a un paramètre de classement différent. Si c’est possible, utilisez un classement standardisé pour votre organisation. De cette façon, vous n’avez pas besoin de spécifier explicitement le classement dans chaque caractère ou expression Unicode. Si vous devez utiliser des objets qui ont des paramètres de classement et de page de codes différents, codez vos requêtes conformément aux règles de priorité des classements. Pour plus d’informations, consultez Priorité du classement (Transact-SQL).

Les options associées à un interclassement sont la sensibilité à la casse, la sensibilité aux accents, la sensibilité au Kana, la sensibilité à la largeur. Ces options sont spécifiées en les ajoutant au nom du classement. Par exemple, ce classement Japanese_Bushu_Kakusu_100_CS_AS_KS_WS est sensible à la casse, aux accents, aux caractères Kana et à la largeur. Le tableau suivant décrit le comportement associé à ces options.

Choix	Descriptif
Respecter la casse (_CS)	Fait la distinction entre les majuscules et les minuscules. Si cette option est sélectionnée, les lettres minuscules précèdent leurs versions majuscules. Si cette option n’est pas sélectionnée, le classement ne respecte pas la casse. Dans ce cas, SQL Server considère que les versions en majuscules et en minuscules des lettres sont identiques dans les opérations de tri. Vous pouvez explicitement sélectionner le non-respect de la casse en spécifiant _CI.
Respecter les accents (_AS)	Fait la distinction entre les caractères accentués et non accentués. Par exemple, 'a' n’est pas égal à 'ấ'. Si cette option n’est pas sélectionnée, le classement ne respecte pas les accents. Dans ce cas, SQL Server considère que la version accentuée et la version non accentuée d’une même lettre sont identiques dans les opérations de tri. Vous pouvez explicitement sélectionner le non-respect des accents en spécifiant _AI.
Respecter le jeu de caractères Kana (_KS)	Fait la distinction entre les deux types de caractères japonais Kana : Hiragana et Katakana. Si cette option n’est pas sélectionnée, le classement n’est pas sensible à Kana. Dans ce cas, SQL Server considère que les caractères Hiragana et Katakana sont identiques dans les opérations de tri. Omettre cette option est la seule méthode de spécification de Kana-insensitivity.
Respecter la largeur (_WS)	Fait la différence entre les caractères pleine largeur et demi-largeur. Si cette option n’est pas sélectionnée, SQL Server considère que la représentation pleine largeur et demi-largeur du même caractère doit être identique à des fins de tri. L'omission de cette option est le seul moyen de spécifier le non-respect de la largeur.

SQL Server prend en charge les ensembles de classement suivants :

classements Windows
Les classements Windows définissent les règles de stockage des données de type caractère selon les paramètres régionaux système Windows associés. Pour un classement Windows, la comparaison des données non Unicode est implémentée à l’aide du même algorithme que les données Unicode. Les règles de classement Windows de base spécifient l’alphabet ou la langue utilisée lorsque le tri du dictionnaire est appliqué et la page de codes utilisée pour stocker des données caractères non Unicode. Les tris Unicode et non-Unicode sont compatibles avec les comparaisons de chaînes dans une version particulière de Windows. Cela fournit une cohérence entre les types de données au sein de SQL Server, et permet également aux développeurs de trier des chaînes dans leurs applications à l’aide des mêmes règles que celles utilisées par SQL Server. Pour plus d’informations, consultez Nom de classement Windows (Transact-SQL).

Classements binaires
Les classements binaires trient les données en fonction de la séquence des valeurs codées qui sont définies par les paramètres régionaux et le type de données. Ils respectent la casse. Un classement binaire dans SQL Server définit les paramètres régionaux et la page de codes ANSI qui seront utilisés. Cela applique un ordre de tri binaire. Étant donné qu’ils sont relativement simples, les classements binaires permettent d’améliorer les performances des applications. Pour les types de données non Unicode, les comparaisons de données sont basées sur les points de code définis dans la page de codes ANSI. Pour les données de type Unicode, les comparaisons de données se basent sur les points de code Unicode. Pour les classements binaires sur les types de données Unicode, les paramètres régionaux ne sont pas pris en compte dans les tris de données. Par exemple, Latin_1_General_BIN et Japanese_BIN produisent des résultats de tri identiques lorsqu’ils sont utilisés sur des données Unicode.

Il existe deux types de classements binaires dans SQL Server ; les classements plus anciens BIN et les classements les plus récents BIN2 . Dans un BIN2 classement, tous les caractères sont triés en fonction de leurs points de code. Dans un BIN classement, seul le premier caractère est trié en fonction du point de code, et les caractères restants sont triés en fonction de leurs valeurs d’octet. (Étant donné que la plateforme Intel est une architecture un peu endienne, les caractères de code Unicode sont toujours stockés par octets permutés.)

classements SQL Server
Les classements de SQL Server (SQL_*) offrent la compatibilité des ordres de tri avec les versions antérieures de SQL Server. Les règles de tri de dictionnaire pour les données non Unicode ne sont pas compatibles avec toute routine de tri fournie par les systèmes d’exploitation Windows. Toutefois, le tri de données Unicode est compatible avec une version particulière de règles de tri Windows. Étant donné que les classements SQL Server utilisent différentes règles de comparaison pour les données non Unicode et Unicode, vous verrez des résultats différents pour les comparaisons des mêmes données, en fonction du type de données sous-jacent. Pour plus d’informations, consultez le nom du classement SQL Server (Transact-SQL).

Remarque

Lorsque vous mettez à niveau une instance en langue anglaise de SQL Server, les classements SQL Server (SQL_*) peuvent être spécifiés pour la compatibilité avec les instances existantes de SQL Server. Étant donné que le classement par défaut d’une instance de SQL Server est défini lors de l’installation, vérifiez que vous spécifiez soigneusement les paramètres de classement lorsque les valeurs suivantes sont remplies :

Votre code d'application dépend du comportement des classements SQL Server précédents.
Vous devez stocker des données de caractères de plusieurs langues.

Les paramétrages des classements sont pris en charge aux niveaux suivants d'une instance SQL Server:

Classements au niveau du serveur
Le classement du serveur par défaut est défini lors de l’installation de SQL Server et devient également le classement par défaut des bases de données système et de toutes les bases de données utilisateur. Notez que les classements Unicode uniquement ne peuvent pas être sélectionnés lors de l’installation de SQL Server, car ils ne sont pas pris en charge en tant que classements au niveau du serveur.

Une fois qu’un classement a été affecté au serveur, vous ne pouvez pas modifier le classement, à l’exception de l’exportation de tous les objets et données de base de données, de la reconstruction de la master base de données et de l’importation de tous les objets et données de base de données. Au lieu de modifier le classement par défaut d’une instance de SQL Server, vous pouvez spécifier le classement souhaité au moment où vous créez une base de données ou une colonne de base de données.

Classements au niveau de la base de données
Lorsqu’une base de données est créée ou modifiée, vous pouvez utiliser la clause COLLATE de l’instruction CREATE DATABASE ou ALTER DATABASE pour spécifier le classement de base de données par défaut. Si aucun classement n'est spécifié, le classement du serveur est affecté à la base de données.

Vous ne pouvez pas modifier le classement des bases de données système, sauf en modifiant le classement du serveur.

Le classement de base de données est utilisé pour toutes les métadonnées de la base de données, et est la valeur par défaut pour toutes les colonnes de chaîne, les objets temporaires, les noms de variables et toutes les autres chaînes utilisées dans la base de données. Quand vous modifiez le classement d'une base de données utilisateur, des conflits de classement risquent de se produire quand des requêtes de la base de données accèdent à des tables temporaires. Les tables temporaires sont toujours stockées dans la tempdb base de données système, qui utilisera le classement pour l’instance. Les requêtes qui comparent les données de caractères entre la base de données utilisateur et tempdb peuvent échouer si les classements provoquent un conflit lors de l’évaluation des données de caractères. Vous pouvez résoudre ce problème en spécifiant la clause COLLATE dans la requête. Pour plus d’informations, consultez COLLATE (Transact-SQL).

Classements au niveau des colonnes
Lorsque vous créez ou modifiez une table, vous pouvez spécifier des classements pour chaque colonne de chaîne de caractères à l’aide de la clause COLLATE. Si aucun classement n’est spécifié, la colonne est affectée au classement par défaut de la base de données.

Classements au niveau de l'expression
Les classements au niveau de l'expression sont définis lors de l'exécution d'une instruction et ils affectent la façon dont l'ensemble de résultats est retourné. Cela permet aux résultats de tri ORDER BY d’être spécifiques aux paramètres régionaux. Utilisez une clause COLLATE telle que la suivante pour implémenter des classements au niveau de l’expression :

SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;

Paramètres locaux

Les paramètres régionaux sont un ensemble d’informations associées à un emplacement ou à une culture. Cela peut inclure le nom et l’identificateur de la langue parlée, le script utilisé pour écrire la langue et les conventions culturelles. Les classements peuvent être associés à un ou plusieurs ensembles de paramètres régionaux. Pour plus d'informations, consultez Locale IDs Assigned by Microsoft (en anglais).

Page de codes

Une page de codes est le jeu ordonné de caractères d'un script donné dans lequel un index numérique (ou une valeur de point de code) est associé à chaque caractère. Une page de codes Windows est généralement appelée jeu de caractères ou ensemble decaractères. Les pages de codes permettent d'assurer la prise en charge des jeux de caractères et des dispositions du clavier utilisés par différents paramètres régionaux système Windows.

Ordre de tri

L'ordre de tri spécifie comment sont triées les valeurs de données. Cela affecte les résultats de la comparaison des données. Les données sont triées en utilisant les classements et peuvent être optimisées à l'aide des index.

Prise en charge Unicode

Unicode est un standard en matière de correspondance de points de code avec des caractères. Étant donné qu’il est conçu pour couvrir tous les caractères de toutes les langues du monde, il n’est pas nécessaire que différentes pages de codes gèrent différents ensembles de caractères. Si vous stockez des données de caractères qui reflètent plusieurs langages, utilisez toujours des types de données Unicode (nchar, nvarcharet ntext) au lieu des types de données non Unicode (char, varcharet text).

Des limitations significatives sont associées aux types de données non-Unicode. Cela est dû au fait qu’un ordinateur non Unicode sera limité à l’utilisation d’une page de codes unique. Vous pouvez rencontrer des gains de performances à l’aide d’Unicode, car moins de conversions de pages de code sont requises. Les classements Unicode doivent être sélectionnés individuellement au niveau de la base de données, de la colonne ou de l’expression, car ils ne sont pas pris en charge au niveau du serveur.

Les pages de code qu’un client utilise sont déterminées par les paramètres du système d’exploitation. Pour définir les pages de codes du client sur le système d'exploitation Windows, utilisez Paramètres régionaux dans le Panneau de configuration.

Lorsque vous déplacez des données d'un serveur vers un client, votre classement du serveur peut ne pas être reconnu par les pilotes de clients plus anciens. Cela peut se produire lorsque vous déplacez des données d'un serveur Unicode vers un client non-Unicode. La meilleure solution peut alors consister à mettre à niveau le système d'exploitation du client afin de mettre aussi à jour les classements du système sous-jacent. Si le client est équipé du logiciel client de base de données, vous pouvez envisager de lui appliquer une mise à jour du service.

Vous pouvez également essayer d'utiliser un autre classement pour les données du serveur. Choisissez un classement qui s'associe à une page de code sur le client.

Pour utiliser les classements UTF-16 disponibles dans SQL Server 2019 (15.x), vous pouvez sélectionner l’un des classements de caractères _SC supplémentaires (classements Windows uniquement) pour améliorer la recherche et le tri de certains caractères Unicode.

Pour déterminer les problèmes qui sont liés à l'utilisation des types de données Unicode ou non-Unicode, testez votre scénario pour mesurer les écarts de performances dans votre environnement. Il est recommandé de normaliser le classement utilisé sur les systèmes de votre organisation, et de déployer des serveurs et des clients Unicode dans la mesure du possible.

Dans de nombreuses situations, SQL Server interagit avec d’autres serveurs ou clients, et votre organisation peut utiliser plusieurs normes d’accès aux données entre les applications et les instances de serveur. Les clientsSQL Server sont l'un des deux types principaux :

Clients Unicode qui utilisent OLE DB et Open Database Connectivity (ODBC) version 3.7 ou ultérieure.
Clients non Unicode qui utilisent DB-Library et ODBC version 3.6 ou antérieure.

Le tableau suivant fournit des informations sur l’utilisation de données multilingues avec différentes combinaisons de serveurs Unicode et non Unicode.

Serveur	Client	Avantages ou limitations
Unicode	Unicode	Étant donné que les données Unicode seront utilisées dans tout le système, ce scénario offre les meilleures performances et la protection contre l’altération des données récupérées. Il s’agit de la situation avec ActiveX Data Objects (ADO), OLE DB et ODBC version 3.7 ou ultérieure.
Unicode	Non-Unicode	Dans ce scénario, en particulier avec les connexions entre un serveur exécutant un système d’exploitation plus récent et un client exécutant une version antérieure de SQL Server ou sur un système d’exploitation plus ancien, il peut y avoir des limitations ou des erreurs lorsque vous déplacez des données vers un ordinateur client. Les données Unicode sur le serveur essaieront de mapper à une page de codes correspondante sur le client non-Unicode pour convertir les données.
Non-Unicode	Unicode	Il ne s’agit pas d’une configuration idéale pour l’utilisation de données multilingues. Vous ne pouvez pas écrire de données Unicode sur le serveur non-Unicode. Des problèmes peuvent survenir lorsque les données sont envoyées à des serveurs qui sont en dehors de la page de codes du serveur.
Non-Unicode	Non-Unicode	Cette configuration est la plus limitée pour des données multilingues. Vous pouvez utiliser uniquement une seule page de codes.

Caractères supplémentaires

SQL Server fournit des types de données tels que nchar et nvarchar pour stocker des données Unicode. Ces types de données encodent du texte dans un format appelé UTF-16. Le Consortium Unicode alloue chaque caractère à un point de code unique, qui est une valeur de la plage 0x0000 à 0x10FFFF. Les caractères les plus fréquemment utilisés ont des valeurs de point de code qui s’adapteront à un mot 16 bits en mémoire et sur le disque, mais les caractères avec des valeurs de point de code supérieures à 0xFFFF nécessitent deux mots 16 bits consécutifs. Ces caractères sont appelés caractères supplémentaires, et les deux mots consécutifs de 16 bits sont appelés paires de subrogation.

Si vous utilisez des caractères supplémentaires :

Les caractères supplémentaires peuvent être utilisés dans des opérations de tri et de comparaison dans les versions de classement 90 ou versions supérieures.
Tous les classements de niveau _100 prennent en charge le tri linguistique avec des caractères supplémentaires.
Les caractères supplémentaires ne sont pas pris en charge pour une utilisation dans les métadonnées, comme dans les noms d’objets de base de données.
Introduite dans SQL Server 2012, une nouvelle famille de classements de caractères supplémentaires (SC) peut être utilisée avec les types de données nchar, nvarchar et sql_variant. Par exemple : Latin1_General_100_CI_AS_SCou si vous utilisez un classement japonais, Japanese_Bushu_Kakusu_100_CI_AS_SC.

L’indicateur SC peut s’appliquer aux éléments suivants :
- Version 90 des classements Windows
- Classements Windows version 100
Impossible d’appliquer l’indicateur SC à :
- Classements Windows version 80 et sans version
- Classements binaires BIN ou BIN2
- Classements SQL*

Le tableau suivant compare le comportement de certaines fonctions et opérateurs de chaîne lorsqu'elles utilisent des caractères supplémentaires avec et sans classement SC.

Fonction ou opérateur de chaîne	Avec une collation SC	Sans collation SC
CHARINDEX LEN PATINDEX	La paire de substitution UTF-16 est comptée comme un point de code unique.	La paire de substitution UTF-16 est comptée comme deux points de code.
GAUCHE REMPLACER INVERSE DROITE SOUS-CHAÎNE OBJETS	Ces fonctions traitent chaque paire de substitution comme un point de code unique et fonctionnent comme prévu.	Ces fonctions peuvent fractionner toutes les paires de substitution et entraîner des résultats inattendus.
NCHAR	Retourne le caractère correspondant à la valeur de point de code Unicode spécifiée dans la plage 0 à 0x10FFFF. Si la valeur spécifiée se trouve dans la plage 0 à 0xFFFF, un caractère est retourné. Pour les valeurs plus élevées, la paire de substitution correspondante est retournée.	Une valeur supérieure à 0xFFFF retourne NULL au lieu du substitut correspondant.
UNICODE	Retourne un point de code UTF-16 dans la plage 0 à 0x10FFFF.	Retourne un point de code UCS-2 dans la plage 0 à 0xFFFF.
Recherche de correspondance d’un seul caractère générique Caractère générique - Caractères à ne pas faire correspondre	Les caractères supplémentaires sont pris en charge pour toutes les opérations génériques.	Les caractères supplémentaires ne sont pas pris en charge pour ces opérations génériques. D'autres opérateurs génériques sont pris en charge.

Support du GB18030

GB18030 est une norme distincte utilisée en République populaire de Chine pour l’encodage des caractères chinois. Dans la norme GB18030, les caractères peuvent être encodés sur 1, 2 ou 4 octets de longueur. Pour prendre en charge les caractères encodés selon la norme GB18030,SQL Server les reconnaît lorsqu'ils entrent dans le serveur en provenance d'une application côté client, puis les convertit et les stocke en mode natif en tant que caractères Unicode. Une fois qu’ils sont stockés sur le serveur, ils sont traités comme des caractères Unicode dans toutes les opérations suivantes. Vous pouvez utiliser n'importe quel classement chinois, de préférence la version 100 la plus récente. Tous les classements de niveau _100 prennent en charge le tri linguistique avec GB18030 caractères. Si les données incluent des caractères supplémentaires (paires de substitution), vous pouvez utiliser les classements SC disponibles dans SQL Server 2019 (15.x) pour améliorer la recherche et le tri.

Prise en charge des scripts complexes

SQL Server peut prendre en charge l'entrée, le stockage, la modification et l'affichage de scripts complexes. Les scripts complexes incluent les éléments suivants :

Scripts qui associent l'utilisation de textes écrits de droite à gauche et de gauche à droite, par exemple les textes écrits en arabe et en anglais.
Scripts dont les caractères changent de forme en fonction de leur position ou lorsqu'ils sont associés à d'autres caractères, par exemple les caractères arabes, indiens et thaï.
Langues comme le thaï qui nécessitent des dictionnaires internes pour reconnaître les mots, car il n’y a pas d'espaces entre eux.

Les applications de base de données qui interagissent avec SQL Server doivent utiliser des contrôles qui prennent en charge les scripts complexes. Les contrôles de formulaire Windows standard créés dans le code managé prennent en charge les scripts complexes.

Tâches associées

Tâche	Sujet
Explique comment définir ou modifier le classement de l'instance de SQL Server.	Définir ou modifier le classement du serveur
Explique comment définir ou modifier le classement d'une base de données utilisateur.	Définir ou modifier le classement de base de données
Explique comment définir ou modifier le classement d'une colonne dans la base de données.	Définir ou modifier le classement des colonnes
Explique comment retourner des informations de classement au niveau du serveur, de la base de données ou de la colonne.	Afficher des informations de classement
Décrit comment écrire des instructions Transact-SQL qui les rendent plus portables d’une langue à une autre, ou de prendre en charge plusieurs langues plus facilement.	Rédiger des instructions Transact-SQL internationales
Explique comment modifier la langue des messages d'erreur et des paramètres relatifs à l'utilisation et l'affichage de la date, de l'heure et des devises.	Définir une langue de session