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 les types de données character, tels que char et varchar, déterminent la page de codes et les caractères correspondants qui peuvent ê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 un serveur à des bases de données clientes, il est important que vous compreniez les besoins en termes de paramètres régionaux, ordre de tri et respect de la casse et des accents des données avec lesquelles vous travaillez. 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 assignez 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 d'ORDER BY, l'ordre de tri de votre jeu de résultats peut dépendre du classement appliqué à la base de données ou stipulé dans une clause COLLATE au niveau expression de la requête.

Pour exploiter au mieux la prise en charge des classements dans SQL Server, vous devez comprendre les termes qui sont définis dans cette rubrique et la relation qu'ils entretiennent avec les caractéristiques de vos données.

Dans cette rubrique

Termes de classement

Prise en charge d'Unicode

Caractères supplémentaires

Prise en charge du langage GB18030

Prise en charge des scripts complexes

Tâches associées

Contenu associé

Termes de classement

• Classement

• Paramètres régionaux

• Page de codes

• Ordre de tri

Classement

Un classement désigne les modèles binaires 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 des 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. Dans la mesure du possible, choisissez un classement normalisé pour votre organisation. De cette manière, vous n'avez pas à 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é de classement (Transact-SQL).

Les options associées à un classement sont le respect de la casse, le respect des accents, le respect du jeu de caractères Kana et le respect de la largeur. Pour spécifier ces options, vous devez les ajouter au nom du classement. Par exemple, le classement Japanese_Bushu_Kakusu_100_CS_AS_KS_WS respecte la casse, les accents, le jeu de caractères Kana et la largeur. Le tableau suivant décrit le comportement associé à ces options.

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 de données non-Unicode est implémentée via le 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 pour le tri du dictionnaire, et la page de codes utilisée pour stocker les données de type caractère non-Unicode. Les tris Unicode et non-Unicode sont compatibles avec les comparaisons de chaînes dans une version particulière de Windows. Les types de données sont ainsi cohérents dans SQL Server, ce qui permet aux développeurs de trier les chaînes dans leurs applications en appliquant les 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. Parce qu'ils sont relativement simples, les classements binaires aident à améliorer les performances de l'application. Pour les types de données non-Unicode, les comparaisons de données sont basées sur les points de code qui sont 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 appliqués à des 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 quand ils sont utilisés avec des données Unicode.

  Il existe deux types de classement binaire dans SQL Server ; les anciens classements BIN et les nouveaux classements BIN2. Dans un classement BIN2, tous les caractères sont triés selon leurs points de code. Dans un classement BIN, seul le premier caractère est trié selon le point de code et les autres caractères sont triés selon leurs valeurs d'octets. (La plateforme Intel étant une architecture avec primauté des octets de poids faible [Little endian], les caractères Unicode sont toujours stockés avec une permutation des octets.)

• Classements SQL Server
  Les classements (SQL_*) SQL Server fournissent la compatibilité d'ordre de tri avec les versions antérieures de SQL Server. Les règles de tri du dictionnaire pour les données non-Unicode ne sont pas compatibles avec les routines de tri fournies 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. Comme les classements SQL Server utilisent des règles de comparaison différentes pour les données Unicode et non-Unicode, vous pouvez obtenir des résultats différents pour des comparaisons traitant des mêmes données, selon le type de données sous-jacent. Pour plus d'informations, consultez Nom du classement SQL Server (Transact-SQL).

  [!REMARQUE]

  Lorsque vous mettez à niveau une instance anglaise SQL Server, vous pouvez spécifier les classements (SQL_*) SQL Server pour permettre la compatibilité avec les instances SQL Server existantes. Le classement par défaut d'une instance SQL Server étant défini au cours de la procédure d'installation, assurez-vous de spécifier soigneusement les paramètres de classement dans les cas suivants :

  • 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 durant 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 ne peuvent pas être sélectionnés pendant la procédure d'installation de SQL Server, car ils ne sont pas pris en charge en tant que classements au niveau du serveur.

  Lorsqu'un classement a été affecté au serveur, vous ne pouvez pas le modifier le classement, à moins d'exporter la totalité des objets et des données de la base de données, de reconstruire la base de données master et d'importer la totalité des objets et des données de la base de données. Au lieu de modifier le classement par défaut d'une instance SQL Server, vous pouvez spécifier le classement désiré au moment de la création d'une nouvelle base de données ou colonne de base de données.

• Classements au niveau de la base de données
  Lorsque vous créez ou modifiez une base de données, vous pouvez utiliser la clause COLLATE de l'instruction CREATE DATABASE ou ALTER DATABASE pour spécifier le classement par défaut de la base de données. 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, à moins de modifier le classement du serveur.

  Le classement de la base de données est utilisé pour toutes les métadonnées de la base de données. Il constitue le classement par défaut pour l'ensemble des colonnes de chaîne, des objets temporaires, des noms de variable et des autres chaînes utilisées dans la base de données. Lorsque vous modifiez le classement d'une base de données utilisateur, des conflits de classement peuvent se produire lorsque des requêtes dans la base de données accèdent à des tables temporaires. Les tables temporaires sont toujours stockées dans la base de données système tempdb, qui utilise le classement de l'instance. Les requêtes qui comparent les données caractères entre la base de données utilisateur et tempdb risquent d'échouer si les classements génèrent un conflit lors de l'évaluation des données 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é, le classement par défaut de la base de données est attribué à la colonne.

• 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 les classements au niveau de l'expression :

  SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;
  

Retour en haut de page

Paramètres régionaux

Les paramètres régionaux sont un ensemble d'informations associées à un emplacement ou à une culture. Il peut s'agir du nom et de l'identificateur de la langue parlée, du script utilisé pour écrire la langue et des 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).

Retour en haut de page

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 charset. 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.

Retour en haut de page

Ordre de tri

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

Retour en haut de page

Prise en charge d'Unicode

Unicode est un standard en matière de correspondance de points de code avec des caractères. Comme il est conçu pour couvrir tous les caractères de toutes les langues du monde, il n'y a pas besoin de pages de codes différentes pour gérer des jeux de caractères différents. Si vous stockez des données de caractères de plusieurs langues, utilisez toujours les types de données Unicode (nchar, nvarchar et ntext) à la place des types de données non-Unicode (char, varchar et text).

Des limitations significatives sont associées aux types de données non-Unicode. C'est parce qu'un ordinateur non-Unicode sera restreint quant à l'utilisation d'une page de codes unique. Vous pouvez bénéficier de gains de performances en utilisant Unicode parce qu'un moins grand nombre de conversions de page de codes est requis. Les classements unicode doivent être sélectionnés individuellement au niveau de la base de données, de la colonne ou de l'expression parce qu'ils ne sont pas pris en charge au niveau serveur.

Les pages de codes qu'utilise un client 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 établit un mappage à une page de codes du client.

Pour utiliser les classements UTF-16 disponibles dans SQL Server 2012, sélectionnez l'un des classements _SC de caractères supplémentaires (classements Windows uniquement) afin d'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. Vous devez normaliser le classement utilisé sur les systèmes de votre organisation et déployer des serveurs et clients Unicode partout où vous le pouvez.

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

• Les clients Unicode qui utilisent OLE DB et ODBC (Open Database Connectivity) 3.7 ou version ultérieure.

• Les clients non-Unicode qui utilisent DB-Library et ODBC 3.6 ou version antérieure.

Le tableau suivant présente des informations sur l'utilisation des données multilingues avec diverses combinaisons de serveurs Unicode et non-Unicode.

Retour en haut de page

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 le texte dans un format appelé UTF-16. Le Consortium Unicode alloue à chaque caractère un codepoint unique, qui est une valeur comprise entre 0x0000 et 0x10FFFF. Les caractères les plus fréquemment utilisés ont des valeurs de codepoint qui correspondent à un mot de 16 bits en mémoire et sur le disque, mais les caractères dont les valeurs de codepoint sont supérieures à 0xFFFF requièrent deux mots de 16 bits consécutifs. Ces caractères sont appelés des caractères supplémentaires et les deux mots de 16 bits consécutifs sont appelés des paires de substitution.

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 nouveaux classements de niveau _100 prennent en charge le tri linguistique avec les caractères supplémentaires.

• Les caractères supplémentaires ne sont pas utilisables dans les métadonnées, telles que les noms d'objets de base de données.

• Depuis 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. Exemple : Latin1_General_100_CI_AS_SC ou, si vous utilisez un classement japonais, Japanese_Bushu_Kakusu_100_CI_AS_SC.

  L'indicateur SC peut s'appliquer :

  • aux classements Windows version 90 ;

  • aux classements Windows version 100 ;

  L'indicateur SC ne peut pas s'appliquer :

  • aux classements Windows version 80 et sans version ;

  • aux classements binaires BIN ou BIN2 ;

  • aux classements SQL*.

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

Retour en haut de page

Prise en charge du langage 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 stockés dans le serveur, ils sont traités en tant que 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 les caractères GB18030. Si les données incluent des caractères supplémentaires (paires de substitution), vous pouvez utiliser les classements SC disponibles dans SQL Server 2012 pour améliorer la recherche et le tri.

Retour en haut de page

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 sont les 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ï.

• Les langues telles que le thaï nécessitent des dictionnaires internes pour la reconnaissance des mots, car ces derniers ne sont pas séparés.

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 Windows Form standard créés dans du code managé peuvent prendre en charge les scripts complexes.

Retour en haut de page

Tâches associées

Retour en haut de page

Contenu associé

SQL Server Best Practices Collation Change (en anglais)

« SQL Server Best Practices Migration to Unicode » (en anglais)

Site web du consortium Unicode

Voir aussi

Référence

sys.fn_helpcollations (Transact-SQL)

Concepts

Classements de base de données à relation contenant-contenu

Choisir une langue lors de la création d'un index de recherche en texte intégral