Prise en charge d’Unicode et des classements
S’applique à : 
SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) Point de terminaison analytique SQL dans Microsoft Fabric Warehouse in Microsoft Fabric
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 données de type caractère, 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.
Qu’il s’agisse d’installer une nouvelle instance de SQL Server, de restaurer une sauvegarde de base de données ou de connecter un serveur à des bases de données clientes, vous devez bien comprendre les exigences en termes de paramètres régionaux, d’ordre de tri et de respect de la casse et des accents des données que vous utilisez. Pour lister les classements disponibles sur votre instance de SQL Server, consultez sys.fn_helpcollations (Transact-SQL).
Quand vous sélectionnez un classement pour votre serveur, base de données, colonne ou expression, vous assignez certaines caractéristiques à vos données. Ces caractéristiques affectent les résultats de nombreuses opérations dans la base de données. Par exemple, quand vous construisez une requête avec ORDER BY, l’ordre de tri de votre jeu de résultats peut dépendre du classement qui est appliqué à la base de données ou qui est stipulé dans une clause COLLATE au niveau de l’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 cet article et la relation qu’ils entretiennent avec les caractéristiques de vos données.
Termes de classement
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 que vous déplacez 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 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, le respect de la largeur et le respect du sélecteur de variante. SQL Server 2019 (15.x) introduit une option supplémentaire pour l’encodage UTF-8.
Vous pouvez spécifier ces options en les ajoutant au nom du classement. Par exemple, le classement Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 respecte la casse, les accents, le jeu de caractères Kana et la largeur, et il est encodé en UTF-8. Autre exemple : le classement Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS ne respecte pas la casse, ne respecte pas les accents, respecte le jeu de caractères Kana, respecte la largeur, respecte le sélecteur de variante et utilise un encodage non-Unicode.
Le comportement associé à ces différentes options est décrit dans le tableau suivant :
| Option | Description |
|---|---|
| Respecter la casse (_CS) | Fait la distinction entre les majuscules et les minuscules. Si cette option est sélectionnée, les minuscules sont triées avant leurs équivalents 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 équivalent à « ấ ». 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 ne respecte pas les caractères Kana. Dans ce cas, SQL Server considère que les caractères Hiragana et Katakana sont identiques dans les opérations de tri. L’omission de cette option est le seul moyen de spécifier le non-respect du jeu de caractères Kana. |
| 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 d’un même caractère sont identiques dans les opérations de tri. L'omission de cette option est le seul moyen de spécifier le non-respect de la largeur. |
| Respecter le sélecteur de variante (_VSS) | Fait la distinction entre différents sélecteurs de variante idéographiques dans les classements japonais Japanese_Bushu_Kakusu_140 et Japanese_XJIS_140, qui sont introduits dans SQL Server 2017 (14.x). Une séquence de variantes se compose d’un caractère de base et d’un sélecteur de variante. Si l’option _VSS n’est pas sélectionnée, le classement ne respecte pas le sélecteur de variante, qui n’est pas non plus pris en compte dans la comparaison. Autrement dit, SQL Server considère comme identiques pour les tris les caractères basés sur le même caractère de base avec différents sélecteurs de variante. Pour plus d’informations, consultez Unicode Ideographic Variation Database. Les classements qui respectent le sélecteur de variante (_VSS) ne sont pas pris en charge par les index de recherche en texte intégral, Les index de recherche en texte intégral prennent uniquement en charge les options Respecter les accents (_AS), Respecter le jeu de caractères Kana (_KS) et Respecter la largeur (_WS). Les moteurs XML et CLR de SQL Server ne prennent pas en charge les sélecteurs de variante (_VSS). |
| Binaire (_BIN)1 | Trie et compare les données dans les tables SQL Server en fonction des modèles de bits définis pour chaque caractère. L’ordre de tri binaire respecte la casse et les accents. Il s'agit aussi de l'ordre de tri le plus rapide. Pour plus d’informations, consultez la section Classements binaires de cet article. |
| Point de code binaire (_BIN2)1 | Trie et compare les données des tables SQL Server en fonction des points de code Unicode pour les données Unicode. Pour les données non-Unicode, le point de code binaire utilise des comparaisons identiques à celles utilisées pour les tris binaires. L’utilisation d’un ordre de tri de point de code binaire présente l’avantage de ne devoir retrier les données dans les applications qui comparent les données triées de SQL Server. Par conséquent, un ordre de tri de point de code binaire simplifie le développement des applications et permet d’améliorer les performances. Pour plus d’informations, consultez la section Classements binaires de cet article. |
| UTF-8 (_UTF8) | Permet le stockage des données encodées en UTF-8 dans SQL Server. Si cette option n’est pas sélectionnée, SQL Server utilise le format d’encodage non-Unicode par défaut pour les types de données applicables. Pour plus d’informations, consultez la section Prise en charge d’UTF-8 de cet article. |
1 Si Binaire ou Point de code binaire est sélectionné, les options Respecter la casse (_CS), Respecter les accents (_AS), Respecter les caractères Kana (_KS) et Respecter la largeur (_WS) ne sont pas disponibles.
Exemples d’options de classement
Chaque classement se présente comme une série de suffixes permettant de définir le respect de la casse, des accents, de la largeur ou des caractères Kana. Les exemples suivants décrivent le comportement de l’ordre de tri selon différentes combinaisons de suffixes.
| Suffixe de classement Windows | Description de l'ordre de tri |
|---|---|
| _BIN1 | Tri binaire |
| _BIN21, 2 | Ordre de tri de point de code binaire |
| _CI_AI2 | Non-respect de la casse, non-respect des accents, non-respect des caractères Kana, non-respect de la largeur |
| _CI_AI_KS2 | Non-respect de la casse, non-respect des accents, respect des caractères Kana, non-respect de la largeur |
| _CI_AI_KS_WS2 | Non-respect de la casse, non-respect des accents, respect des caractères Kana, respect de la largeur |
| _CI_AI_WS2 | Non-respect de la casse, non-respect des accents, non-respect des caractères Kana, respect de la largeur |
| _CI_AS2 | Non-respect de la casse, respect des accents, non-respect des caractères Kana, non-respect de la largeur |
| _CI_AS_KS2 | Non-respect de la casse, respect des accents, respect des caractères Kana, non-respect de la largeur |
| _CI_AS_KS_WS2 | Non-respect de la casse, respect des accents, respect des caractères Kana, respect de la largeur |
| _CI_AS_WS2 | Non-respect de la casse, respect des accents, non-respect des caractères Kana, respect de la largeur |
| _CS_AI2 | Respect de la casse, non-respect des accents, non-respect des caractères Kana, non-respect de la largeur |
| _CS_AI_KS2 | Respect de la casse, non-respect des accents, respect des caractères Kana, non-respect de la largeur |
| _CS_AI_KS_WS2 | Respect de la casse, non-respect des accents, respect des caractères Kana, respect de la largeur |
| _CS_AI_WS2 | Respect de la casse, non-respect des accents, non-respect des caractères Kana, respect de la largeur |
| _CS_AS2 | Respect de la casse, respect des accents, non-respect des caractères Kana, non-respect de la largeur |
| _CS_AS_KS2 | Respect de la casse, respect des accents, respect des caractères Kana, non-respect de la largeur |
| _CS_AS_KS_WS2 | Respect de la casse, respect des accents, respect des caractères Kana, respect de la largeur |
| _CS_AS_WS2 | Respect de la casse, respect des accents, non-respect des caractères Kana, respect de la largeur |
1 Si Binaire ou Point de code binaire est sélectionné, les options Respecter la casse (_CS), Respecter les accents (_AS), Respecter les caractères Kana (_KS) et Respecter la largeur (_WS) ne sont pas disponibles.
2 L’ajout de l’option UTF-8 (_UTF8) vous permet d’encoder les données Unicode avec UTF-8. Pour plus d’informations, consultez la section Prise en charge d’UTF-8 de cet article.
Ensembles de classements
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, vous pouvez implémenter une comparaison de données non-Unicode via le même algorithme que pour 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. Les règles spécifient également 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 à utiliser. 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 le classement binaire des types de données Unicode, les paramètres régionaux (la langue) ne sont pas pris en compte dans les tris de données. Par exemple, Latin1_General_BIN et Japanese_BIN donnent des résultats de tri identiques quand ils sont utilisés avec des données Unicode. Pour plus d’informations, consultez Nom de classement Windows (Transact-SQL).
Il existe deux types de classements binaires dans SQL Server :
Les classements BIN précédents, qui effectuaient une comparaison incomplète de point de code à point de code pour les données Unicode. Ces classements binaires hérités comparaient le premier caractère comme WCHAR, suivi d’une comparaison octet par octet. Dans un classement BIN, seul le premier caractère est trié selon le point de code. Les autres caractères sont triés en fonction de leurs valeurs d’octet.
Les classements BIN2 plus récents, qui implémentent une comparaison de point de code pure. Dans un classement BIN2, tous les caractères sont triés en fonction de leurs points de code. En raison de l’architecture little endian de la plateforme Intel, les caractères de code Unicode sont toujours stockés avec les octets inversé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 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 des mêmes données, selon le type de données sous-jacent.
Par exemple, si vous utilisez le classement SQL SQL_Latin1_General_CP1_CI_AS, la chaîne non-Unicode 'a-c' est inférieure à la chaîne 'ab' parce que le trait d'union (-) est classé comme un caractère distinct qui vient avant b. Toutefois, si vous convertissez ces chaînes en Unicode et que vous effectuez la même comparaison, la chaîne Unicode N'a-c' est considérée comme supérieure à N'ab', car les règles de tri Unicode utilisent un tri par mot qui ignore le trait d'union.
Pour plus d’informations, consultez Nom du classement SQL Server (Transact-SQL).
Lors de l’installation de SQL Server, le classement par défaut est déterminé par les paramètres régionaux du système d’exploitation. Vous pouvez modifier le classement au niveau du serveur pendant l’installation ou en modifiant les paramètres régionaux du système d’exploitation avant l’installation. Pour garantir la compatibilité ascendante, le classement par défaut est défini d’après la version disponible la plus ancienne associée à chaque ensemble de paramètres régionaux spécifiques. Par conséquent, il ne s’agit pas toujours du classement recommandé. Pour tirer pleinement parti des fonctionnalités de SQL Server, modifiez les paramètres d’installation par défaut de façon à utiliser les classements Windows. Par exemple, pour les paramètres régionaux du système d’exploitation « Anglais (États-Unis) » (page de codes 1252), le classement par défaut lors de l’installation est SQL_Latin1_General_CP1_CI_AS et il peut être remplacé par le classement Windows le plus proche Latin1_General_100_CI_AS_SC équivalent.
Notes
Quand vous mettez à niveau une instance en anglais de SQL Server, vous pouvez spécifier les classements SQL Server (SQL_*) pour 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.
Niveaux de classement
Les paramétrages des classements sont pris en charge aux niveaux suivants d'une instance SQL Server:
- Classements au niveau du serveur
- Classements au niveau de la base de données
- Classements au niveau de la colonne
- Classements au niveau de l’expression
Classements au niveau du serveur
Le classement par défaut du serveur est défini lors de l’installation de SQL Server, et il devient le classement par défaut des bases de données système et de toutes les bases de données utilisateur.
Le tableau suivant montre les désignations de classement par défaut, telles qu’elles sont déterminées par les paramètres régionaux du système d’exploitation, avec leurs identificateurs de code de langue (LCID) Windows et SQL :
| Paramètres régionaux Windows | LCID Windows | LCID SQL | Classement par défaut |
|---|---|---|---|
| Afrikaans (Afrique du Sud) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Albanais (Albanie) | 0x041c | 0x041c | Albanian_CI_AS |
| Alsacien (France) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amharique (Éthiopie) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arabe (Algérie) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arabe (Bahreïn) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arabe (Égypte) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arabe (Irak) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arabe (Jordanie) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arabe (Koweït) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arabe (Liban) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arabe (Libye) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arabe (Maroc) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arabe (Oman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arabe (Qatar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arabe (Arabie saoudite) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arabe (Syrie) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arabe (Tunisie) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arabe (E.A.U.) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arabe (Yémen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Arménien (Arménie) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assamais (Inde) | 0x044d | 0x044d | Non disponible au niveau du serveur |
| Azerbaïdjanais (Azerbaïdjan, cyrillique) | 0x082c | 0x082c | Déprécié, non disponible au niveau serveur |
| Azerbaïdjanais (Azerbaïdjan, latin) | 0x042c | 0x042c | Déprécié, non disponible au niveau serveur |
| Bachkir (Russie) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Basque (Basque) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Biélorusse (Bélarus) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bengali (Bangladesh) | 0x0845 | 0x0445 | Non disponible au niveau du serveur |
| Bengali (India) | 0x0445 | 0x0439 | Non disponible au niveau du serveur |
| Bosniaque (Bosnie-Herzégovine, cyrillique) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Bosniaque (Bosnie-Herzégovine, latin) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Breton (France) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgare (Bulgarie) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Catalan (Catalogne) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Chinois (Hong Kong R.A.S., RPC) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Chinese (Macao (R.A.S.)) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Chinese (Macao (R.A.S.)) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Chinois (RPC) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Chinois (RPC) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinese (Singapore) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Chinese (Singapore) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Chinois (Taïwan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Chinois (Taïwan) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Corse (France) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Croate (Bosnie-Herzégovine, latin) | 0x101a | 0x041a | Croatian_CI_AS |
| Croate (Croatie) | 0x041a | 0x041a | Croatian_CI_AS |
| Tchèque (République tchèque) | 0x0405 | 0x0405 | Czech_CI_AS |
| Danois (Danemark) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afghanistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Maldivien (Maldives) | 0x0465 | 0x0465 | Non disponible au niveau du serveur |
| Néerlandais (Belgique) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Néerlandais (Pays-Bas) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Australie) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Canada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Caraïbes) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Inde) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Irlande) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Jamaïque) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Malaisie) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Nouvelle-Zélande) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Philippines) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Singapour) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Afrique du Sud) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Trinidad-et-Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| Anglais (Royaume-Uni) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| Anglais (États-Unis) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| Anglais (Zimbabwe) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estonien (Estonie) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Féroïen (Îles Féroé) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Filipino (Philippines) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Finnois (Finlande) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Français (Belgique) | 0x080c | 0x040c | French_CI_AS |
| Français (Canada) | 0x0c0c | 0x040c | French_CI_AS |
| Français (France) | 0x040c | 0x040c | French_CI_AS |
| Français (Luxembourg) | 0x140c | 0x040c | French_CI_AS |
| Français (Monaco) | 0x180c | 0x040c | French_CI_AS |
| Français (Suisse) | 0x100c | 0x040c | French_CI_AS |
| Frison (Pays-Bas) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galicien | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Géorgien (Géorgie) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Géorgien (Géorgie) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Allemand - Annuaire téléphonique (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Allemand (Autriche) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Allemand (Allemagne) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Allemand (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Allemand (Luxembourg) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Allemand (Suisse) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Grec (Grèce) | 0x0408 | 0x0408 | Greek_CI_AS |
| Groenlandais (Groenland) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Goudjrati (Inde) | 0x0447 | 0x0439 | Non disponible au niveau du serveur |
| Haoussa (Nigeria, latin) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| Hébreu (Israël) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hindi (Inde) | 0x0439 | 0x0439 | Non disponible au niveau du serveur |
| Hongrois (Hongrie) | 0x040e | 0x040e | Hungarian_CI_AS |
| Hongrois - Technique | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| Islandais (Islande) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nigeria) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Indonésien (Indonésie) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Canada, latin) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (syllabique, Canada) | 0x045d | 0x045d | Latin1_General_CI_AI |
| Irlandais (Irlande) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| Italien (Italie) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| Italien (Suisse) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Japonais (Japon XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Japonais (Japon) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (Inde) | 0x044b | 0x0439 | Non disponible au niveau du serveur |
| Kazakh (Kazakhstan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Cambodge) | 0x0453 | 0x0453 | Non disponible au niveau du serveur |
| Quiché (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Rwanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (Inde) | 0x0457 | 0x0439 | Non disponible au niveau du serveur |
| Coréen (Corée - Dictionnaire) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kirghize (Kirghizistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (RDP Lao) | 0x0454 | 0x0454 | Non disponible au niveau du serveur |
| Letton (Lettonie) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Lituanien (Lituanie) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Bas-sorabe (Allemagne) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Luxembourgeois (Luxembourg) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Macédonien (Macédoine du Nord) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Malais (Brunéi Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Malais (Malaisie) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam (Inde) | 0x044c | 0x0439 | Non disponible au niveau du serveur |
| Maltais (Malte) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Nouvelle-Zélande) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapuche (Chili) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (Inde) | 0x044e | 0x0439 | Non disponible au niveau du serveur |
| Mohawk (Canada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Mongol (Mongolie) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Mongol (République populaire de Chine) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Népalais (Népal) | 0x0461 | 0x0461 | Non disponible au niveau du serveur |
| Norvégien (bokmål, Norvège) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Norvégien (Nynorsk, Norvège) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Occitan (France) | 0x0482 | 0x040c | French_CI_AS |
| Odia (Inde) | 0x0448 | 0x0439 | Non disponible au niveau du serveur |
| Pachtou (Afghanistan) | 0x0463 | 0x0463 | Non disponible au niveau du serveur |
| Persan (Iran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Polonais (Pologne) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portugais (Brésil) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portugais (Portugal) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Pendjabi (Inde) | 0x0446 | 0x0439 | Non disponible au niveau du serveur |
| Quechua (Bolivie) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Équateur) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Pérou) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Roumain (Roumanie) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Romanche (Suisse) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Russe (Russie) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sahka (Russie) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Same d'Inari (Finlande) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Sami (Lule, Norvège) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Same de Lule (Suède) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Same du nord (Finlande) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Same du nord (Norvège) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Same du nord (Suède) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Same de Skolt (Finlande) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Same du sud (Norvège) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Same du sud (Suède) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanskrit (Inde) | 0x044f | 0x0439 | Non disponible au niveau du serveur |
| Serbe (Bosnie-Herzégovine, cyrillique) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbe (Bosnie-Herzégovine, latin) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Serbe (Serbie, cyrillique) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbe (latin, Serbie) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sesotho sa Leboa/Sotho du Nord (Afrique du Sud) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| Setswana/Tswana (Afrique du Sud) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Cingalais (Sri Lanka) | 0x045b | 0x0439 | Non disponible au niveau du serveur |
| Slovaque (Slovaquie) | 0x041b | 0x041b | Slovak_CI_AS |
| Slovène (Slovénie) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| Espagnol (Argentine) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Bolivie) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Chili) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Colombie) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Costa Rica) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (République dominicaine) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Équateur) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Mexique) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Nicaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Pérou) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Porto Rico) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Espagne) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Espagne, traditionnel) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| Espagnol (États-Unis) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| Espagnol (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| Espagnol (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Swahili (Kenya) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| Suédois (Finlande) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| Suédois (Suède) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Syriaque (Syrie) | 0x045a | 0x045a | Non disponible au niveau du serveur |
| Tadjik (Tadjikistan) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Algérie, latin) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamoul (Inde) | 0x0449 | 0x0439 | Non disponible au niveau du serveur |
| Tatar (Russie) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Télougou (Inde) | 0x044a | 0x0439 | Non disponible au niveau du serveur |
| Thaï (Thaïlande) | 0x041e | 0x041e | Thai_CI_AS |
| Tibétain (RPC) | 0x0451 | 0x0451 | Non disponible au niveau du serveur |
| Turc (Turquie) | 0x041f | 0x041f | Turkish_CI_AS |
| Turkmène (Turkménistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Ouïgour (RPC) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Ukrainien (Ukraine) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Haut-sorabe (Allemagne) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Ourdou (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Ouzbek (Ouzbékistan, cyrillique) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Ouzbek (Ouzbékistan, latin) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamien (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Gallois (Royaume-Uni) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Sénégal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa (Afrique du Sud) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (RPC) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nigeria) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zoulou (Afrique du Sud) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
Une fois que vous avez affecté un classement au serveur, vous pouvez le modifier uniquement en exportant la totalité des objets et des données de la base de données, en reconstruisant la base de données master et en important 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é quand vous créez une nouvelle base de données ou colonne de base de données.
Pour demander le classement du serveur pour une instance SQL Server, utilisez la fonction SERVERPROPERTY :
SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));
Pour demander au serveur tous les classements disponibles, utilisez la fonction intégrée fn_helpcollations() suivante :
SELECT * FROM sys.fn_helpcollations();
Classements dans la base de données Azure SQL
Vous ne pouvez pas modifier ou définir le classement du serveur logique sur la base de données Azure SQL, mais vous pouvez configurer les classements de chaque base de données à la fois pour les données et pour le catalogue. Le classement du catalogue détermine le classement pour les métadonnées système, telles que les identificateurs d’objet. Les deux classements peuvent être spécifiés indépendamment lorsque vous créez la base de données dans le portail Azure, dans T-SQL avec CREATE DATABASE, dans PowerShell avec New-AzSqlDatabase.
Classements dans Azure SQL Managed Instance
Le classement au niveau du serveur dans Azure SQL Managed Instance peut être spécifié quand l’instance est créée et ne peut plus être modifiée.
Pour plus d’informations, consultez Définir ou modifier le classement du serveur.
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.
- Dans SQL Server et Azure SQL Managed Instance, 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.
- Dans la base de données Azure SQL, il n'y a pas de classement du serveur, de sorte que chaque base de données a un classement pour les données et un classement pour le catalogue. CATALOG_COLLATION 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. CATALOG_COLLATION est défini lors de la création et ne peut pas être modifié.
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 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).
Vous pouvez modifier le classement d’une base de données utilisateur avec une instruction ALTER DATABASE similaire à l’exemple de code :
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Important
Le fait de changer le classement au niveau de la base de données n’affecte pas les classements au niveau des expressions ou des colonnes. Elle n’affecte pas les données des colonnes existantes.
Vous pouvez récupérer le classement actuel d’une base de données à l’aide d’une instruction semblable à l’exemple de code suivante :
SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));
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 vous ne spécifiez pas de classement, le classement par défaut de la base de données est appliqué à la colonne.
Vous pouvez modifier le classement d’une colonne avec une instruction ALTER TABLE similaire à l’exemple de code :
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI;
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. Pour implémenter les classements au niveau de l’expression, utilisez une clause COLLATE telle que l’exemple de code suivant :
SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;
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).
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.
Ordre de tri
L'ordre de tri spécifie comment sont triées les valeurs de données. Il 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.
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, vous n’avez pas besoin de pages de codes différentes pour gérer des jeux de caractères différents.
Concepts de base d’Unicode
Le stockage de données en plusieurs langues dans une même base de données est délicat à gérer quand vous utilisez seulement des données de type caractère et des pages de codes. Il est également difficile de trouver une page de codes capable de stocker tous les caractères nécessaires spécifiques aux différentes langues. De plus, il est difficile de garantir que les caractères spéciaux sont lus ou mis à jour correctement par différents clients exécutant des pages de codes différentes. Les bases de données qui prennent en charge des clients internationaux doivent toujours utiliser les types de données Unicode au lieu de types de données non-Unicode.
Prenons par exemple une base de données de clients en Amérique du Nord qui doit prendre en charge trois langues principales :
- des noms et des adresses en espagnol pour le Mexique
- des noms et des adresses en français pour le Québec
- des noms et des adresses en anglais pour les autres régions du Canada et les États-Unis
Quand vous utilisez seulement des colonnes de caractères et des pages de codes, vous devez veiller à ce que la base de données soit installée avec une page de codes capable de gérer les caractères des trois langues. Vous devez aussi faire en sorte de garantir la traduction correcte des caractères d’une des langues quand ils sont lus par des clients exécutant une page de codes pour une autre langue.
Notes
Les pages de codes utilisées par 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.
Il est difficile de sélectionner une page de codes pour des types de données caractères qui va prendre en charge tous les caractères requis pour une audience internationale. Le moyen le plus simple de gérer les données de type caractère dans les bases de données internationales est de toujours utiliser un type de données qui prend en charge Unicode.
Types de données Unicode
Si vous stockez des données caractères qui reflètent plusieurs langues dans SQL Server (SQL Server 2005 (9.x) et versions ultérieures ), utilisez des types de données Unicode (nchar, nvarchar et ntext) au lieu de types de données non-Unicode (char, varchar et text).
Notes
Pour les types de données Unicode, le Moteur de base de données peut représenter jusqu'à 65 536 caractères à l’aide de UCS-2 ou la plage Unicode complète (1 114 112 caractères) si les caractères supplémentaires sont utilisés. Pour plus d’informations sur l’activation de caractères supplémentaires, consultez Caractères supplémentaires.
D’autre part, à compter de SQL Server 2019 (15.x), si un classement compatible UTF-8 (_UTF8) est utilisé, les types de données non Unicode (char et varchar) deviennent des types de données Unicode basés sur l’encodage UTF-8. SQL Server 2019 (15.x) ne change pas le comportement des types de données Unicode existants (nchar, nvarchar et ntext), qui continuent d’utiliser l’encodage UCS-2 ou UTF-16. Pour plus d’informations, consultez Différences de stockage entre UTF-8 et UTF-16.
Considérations relatives à Unicode
Des limitations significatives sont associées aux types de données non-Unicode. C’est parce qu’un ordinateur non-Unicode ne peut utiliser qu’une seule page de codes. Vous pouvez bénéficier de gains de performances en utilisant Unicode, car il requiert moins de conversions de page de codes. 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 du serveur.
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.
Conseil
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 (SQL Server 2012 (11.x) et versions ultérieures) afin d’améliorer la recherche et le tri de certains caractères Unicode (classements Windows uniquement), vous pouvez sélectionner un des classements (_SC) de caractères supplémentaires ou un des classements de la version 140.
Pour utiliser les classements UTF-8 disponibles dans SQL Server 2019 (15.x) et améliorer la recherche et le tri de certains caractères Unicode (classements Windows uniquement), vous devez sélectionner des classements compatibles avec l’encodage UTF-8 (_UTF8).
L’indicateur UTF8 peut être appliqué aux éléments suivants :
- Classements linguistiques qui prennent déjà en charge les caractères supplémentaires (_SC) ou le sélecteur de variante (_VSS)
- Classement binaire BIN2
L’indicateur UTF8 ne peut pas être appliqué aux éléments suivants :
- Classements linguistiques qui ne prennent pas en charge les caractères supplémentaires (_SC) ou le sélecteur de variante (_VSS)
- Classements binaires BIN
- Classements SQL_*
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 clients Unicode partout où vous le pouvez.
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 :
- Les clients Unicode qui utilisent OLE DB et ODBC (Open Database Connectivity) version 3.7 ou ultérieure.
- Les clients non-Unicode qui utilisent DB-Library et ODBC version 3.6 ou 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 :
| Serveur | Client | Avantages ou restrictions |
|---|---|---|
| Unicode | Unicode | Comme les données Unicode sont utilisées dans tout le système, ce scénario fournit les meilleures performances et la meilleure protection contre l’altération des données récupérées. C’est le cas avec ActiveX Data Objects (ADO), OLE DB et ODBC version 3.7 ou ultérieure. |
| Unicode | Non-Unicode | Dans ce scénario, et surtout avec les connexions entre un serveur exécutant un système d’exploitation récent et un client exécutant une version antérieure de SQL Server, ou 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 tentent d’établir un mappage à une page de codes correspondante sur le client non-Unicode afin de convertir les données. |
| Non-Unicode | Unicode | Cette configuration n’est pas idéale pour l’utilisation de données multilingues. Vous ne pouvez pas écrire des 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
Le Consortium Unicode alloue à chaque caractère un point de code unique, qui est une valeur comprise entre 000000 et 10FFFF. Les caractères les plus fréquemment utilisés ont des valeurs de point de code dans la plage de 000000 à 00FFFF (65 536 caractères) qui correspondent à un mot de 8 ou 16 bits en mémoire et sur le disque. Cette plage est généralement désignée en tant que Plan multilingue de base (BMP).
Mais le Consortium Unicode a établi des 16 « plans » de caractères supplémentaires, chacun ayant la même taille que le BMP. Cette définition accorde à Unicode le potentiel de représenter 1 114 112 caractères (autrement dit, 216 * 17 caractères) au sein de la plage de point de code de 000000 à 10FFFF. Les caractères dont la valeur de code de caractère supérieures à 00FFFF requièrent entre deux et quatre mots de 8 bits consécutifs (UTF-8) ou deux mots de 16 bits consécutifs (UTF-16). Ces caractères situés au-delà du BMP sont appelés caractères supplémentaires et les deux mots de 8 ou 16 bits consécutifs supplémentaires sont appelés paires de substitution. Pour plus d’informations sur les caractères supplémentaires, les substitutions et les paires de substitution, consultez la norme Unicode.
SQL Server fournit des types de données tels que nchar et nvarchar pour stocker les données Unicode dans la plage BMP (de 000000 à 00FFFF), ce que le moteur de base de données encode à l’aide d’UCS-2.
SQL Server 2012 (11.x) a introduit une nouvelle famille de classements de caractères supplémentaires (_SC) pouvant être utilisée avec les types de données nchar, nvarchar et sql_variant pour représenter la plage de caractères Unicode complète (de 000000 à 10FFFF). Par exemple : Latin1_General_100_CI_AS_SC ou, si vous utilisez un classement japonais, Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x) étend la prise en charge des caractères supplémentaires aux types de données char et varchar avec les nouveaux classements prenant en charge UTF-8 (_UTF8). Ces types de données sont également capables de représenter la plage de caractères Unicode complète.
Notes
À compter de SQL Server 2017 (14.x), tous les nouveaux classements prennent en charge automatiquement les caractères supplémentaires.
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 version 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.
L’indicateur SC peut s’appliquer aux éléments suivants :
- Classements version 90
- Classements version 100
L’indicateur SC ne peut pas s’appliquer aux éléments suivants :
- Classements Windows version 80 et sans version
- Classements binaires BIN ou BIN2
- Classements SQL*
- Classements version 140 (ces derniers n’ont pas besoin de l’indicateur SC, car ils prennent déjà en charge les caractères supplémentaires)
Le tableau suivant compare le comportement de quelques fonctions de chaîne et opérateurs de chaîne quand ils utilisent des caractères supplémentaires avec et sans classement sensible aux caractères supplémentaires :
| Fonction de chaîne ou opérateur | Avec un classement sensible aux caractères supplémentaires | Sans classement sensible aux caractères supplémentaires |
|---|---|---|
| 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. |
| LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF |
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 conduire à des résultats inattendus. |
| NCHAR | Retourne le caractère qui correspond à la valeur de point de code Unicode spécifiée dans la plage de 0 à 0x10FFFF. Si la valeur spécifiée figure dans la plage de 0 à 0xFFFF, un seul 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 de 0 à 0x10FFFF. | Retourne un point de code UCS-2 dans la plage de 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. |
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 version 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 pour améliorer la recherche et le tri.
Notes
Vérifiez que vos outils clients, comme SQL Server Management Studio, utilisent la police Dengxian pour afficher correctement les chaînes qui contiennent des caractères encodés en GB18030.
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 notamment 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ï.
- Des 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.
Classements japonais ajoutés dans SQL Server 2017 (14.x)
À compter de SQL Server 2017 (14.x), de nouvelles familles de classement du japonais sont prises en charge, avec les permutations de différentes options (_CS, _AS, _KS, _WS et _VSS), ainsi que _BIN et _BIN2.
Pour lister ces classements, vous pouvez interroger le Moteur de base de données SQL Server :
SELECT name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Tous les nouveaux classements disposent d’une prise en charge intégrée des caractères supplémentaires, de sorte qu’aucun des nouveaux classements 140 n’a (ni ne requiert) l’indicateur SC.
Ces classements sont pris en charge dans les index, les tables optimisées en mémoire, les index columnstore et les modules compilés en mode natif Moteur de base de données.
Prise en charge d’UTF-8
SQL Server 2019 (15.x) introduit le complet support du codage de caractères UTF-8 largement utilisé en tant qu’encodage d’importation ou d’exportation et en tant que classement au niveau des base de données et au niveau des colonnes pour les données de chaîne. UTF-8 est autorisé dans les types de données char et varchar, et il est activé quand vous créez ou modifiez le classement d’un objet en un classement avec un suffixe UTF8. La modification de LATIN1_GENERAL_100_CI_AS_SC en LATIN1_GENERAL_100_CI_AS_SC_UTF8 en est un exemple.
UTF-8 est disponible uniquement pour les classements Windows qui prennent en charge les caractères supplémentaires, comme introduit dans SQL Server 2012 (11.x). Les types de données nchar et nvarchar autorisent l’encodage UCS-2 ou UTF-16 uniquement et restent inchangés.
La base de données Azure SQL et Azure SQL Managed Instance prennent également en charge UTF-8 au niveau de la base de données et de la colonne, tandis que SQL Managed Instance le prend également en charge au niveau du serveur.
Différences de stockage entre UTF-8 et UTF-16
Le Consortium Unicode alloue à chaque caractère un point de code unique, qui est une valeur comprise entre 000000 et 10FFFF. Avec SQL Server 2019 (15.x), les encodages UTF-8 et UTF-16 sont disponibles pour représenter la plage complète :
- Avec l’encodage UTF-8, les caractères figurant dans la plage ASCII (de 000000 à 00007F) utilisent 1 octet, les points de code de 000080 à 0007FF nécessitent 2 octets, les points de code de 000800 à 00FFFF nécessitent 3 octets et les points de code de 0010000 à 0010FFFF nécessitent 4 octets.
- Avec l’encodage UTF-16, les points de code de 000000 à 00FFFF nécessitent 2 octets et les points de code de 0010000 à 0010FFFF nécessitent 4 octets.
La table suivante liste les octets de stockage d’encodage pour chaque plage de caractères et type d’encodage :
| Plage de codes (hexadécimal) | Plage de codes (décimal) | Octets de stockage1 avec UTF-8 | Octets de stockage1 avec UTF-16 |
|---|---|---|---|
| 000000–00007F | 0–127 | 1 | 2 |
| 000080–00009F 0000A0–0003FF 000400–0007FF |
128–159 160–1 023 1 024–2 047 |
2 | 2 |
| 000800–003FFF 004000–00FFFF |
2 048–16 383 16 384–65 535 |
3 | 2 |
| 010000–03FFFF2 040000–10FFFF2 |
65 536–262 1432 262 144–1 114 1112 |
4 | 4 |
1 Les octets de stockage font référence à la longueur d’octets encodée, et non à la taille de stockage sur disque des types de données. Pour plus d’informations sur les tailles de stockage sur disque, consultez nchar et nvarchar et char et varchar.
2 Plage de points de code pour des caractères supplémentaires.
Conseil
Il est courant de penser en CHAR(n) et en VARCHAR(n), ou en NCHAR(n) et en NVARCHAR(n), que le n définit le nombre de caractères. En effet, dans l’exemple d’une colonne CHAR(10), 10 caractères ASCII de la plage de 0 à 127 peuvent être stockés à l’aide d’un classement tel que Latin1_General_100_CI_AI, car chaque caractère de cette plage utilise uniquement 1 octet.
Toutefois, dans CHAR(n) et VARCHAR(n), le n définit la taille de la chaîne en octets (de 0 à 8 000), et dans NCHAR(n) et NVARCHAR(n), le n définit la taille de la chaîne en paires d’octets (de 0 à 4 000). n ne définit jamais des nombres de caractères pouvant être stockés.
Comme vous venez de le voir, le choix de l’encodage Unicode et du type de données appropriés peut fournir des gains de stockage significatifs ou augmenter votre encombrement de stockage actuel, en fonction du jeu de caractères utilisé. Par exemple, lorsque vous utilisez un classement Latin prenant en charge UTF-8, tel que Latin1_General_100_CI_AI_SC_UTF8, une colonne CHAR(10) stocke 10 octets et peut contenir 10 caractères ASCII dans la plage de 0 à 127. Toutefois, elle ne peut contenir que cinq caractères dans la plage de 128 à 2 047 et seulement trois caractères dans la plage de 2 048 à 65 535. En comparaison, comme une colonne NCHAR(10) stocke 10 paires d’octets (20 octets), elle peut contenir 10 caractères dans la plage de 0 à 65 535.
Avant de choisir s’il faut utiliser l’encodage UTF-8 ou UTF-16 pour une base de données ou une colonne, prenez en compte la distribution des données de chaîne qui seront stockées :
- Si elle est principalement dans la plage ASCII de 0 à 127 (comme l’anglais), chaque caractère nécessite 1 octet avec UTF-8 et 2 octets avec UTF-16. L’utilisation UFT-8 offre des avantages du stockage. Le fait de transformer un type de données de colonne existant comportant des caractères ASCII de la plage de 0 à 127 de
NCHAR(10)enCHAR(10)et d’utiliser un classement prenant en charge UTF-8 se traduit par une réduction de 50 % des besoins en stockage. Cette réduction correspond au fait queNCHAR(10)nécessite 20 octets pour le stockage, tandis queCHAR(10)nécessite 10 octets pour la même représentation de chaîne Unicode. - Au-dessus de la plage ASCII, presque tout l’alphabet latin et grec, cyrillique, copte, arménien, hébreu, arabe, syriaque, Tāna et n’ko nécessite 2 octets par caractère dans les encodages UTF-8 et UTF-16. Dans ces cas, il n’y a pas de différences significatives de stockage pour des types de données comparables (par exemple, entre char et nchar).
- S’il s’agit principalement d’un script d’Asie de l'Est (par exemple, coréen, chinois ou japonais), chaque caractère nécessite 3 octets en UTF-8 et 2 octets en UTF-16. L’utilisation UFT-16 offre des avantages du stockage.
- Les caractères figurant dans la plage de 010000 à 10FFFF nécessitent 4 octets en UTF-8 et UTF-16. Dans ces cas, il n’y a pas de différences de stockage pour des types de données comparables (par exemple entre char et nchar).
Pour d’autres considérations, consultez Écrire des instructions Transact-SQL internationales.
Convertir au format UTF-8
Dans la mesure où dans CHAR(n) et VARCHAR(n) ou dans NCHAR(n) et NVARCHAR(n), le n définit la taille de stockage des octets, et non le nombre de caractères qui peuvent être stockés, il est important de déterminer la taille du type de données à convertir pour éviter la troncation des données.
Par exemple, considérons une colonne définie en tant que NVARCHAR(100) , qui stocke 180 octets de caractères japonais. Dans cet exemple, les données de colonne sont encodées à l’aide de UCS-2 ou UTF-16, qui utilise 2 octets par caractère. La conversion du type de colonne en VARCHAR(200) n’est pas suffisante pour empêcher la troncation des données, car le nouveau type de données peut stocker uniquement 200 octets, mais les caractères japonais nécessitent 3 octets quand ils sont encodés en UTF-8. La colonne doit donc être définie en tant que VARCHAR(270) pour éviter toute perte de données par troncation de données.
Il est donc nécessaire de savoir à l’avance quelle est la taille en octets projetée pour la définition de colonne avant de convertir les données existantes en UTF-8, et d’ajuster la nouvelle taille de type de données de manière appropriée. Consultez le script Transact-SQL ou le notebook SQL dans les exemples de données sur GitHub , qui utilisent la fonction DATALENGTH et l’instruction COLLATE afin de déterminer les exigences de longueur de données appropriées pour les opérations de conversion UTF-8 dans une base de données existante.
Pour changer le classement des colonnes et le type de données dans une table existante, utilisez l’une des méthodes décrites dans Définir ou changer le classement des colonnes.
Pour changer le classement de la base de données, en permettant aux nouveaux objets d’hériter du classement de base de données par défaut, ou pour changer le classement du serveur, en permettant aux nouvelles bases de données d’hériter du classement système par défaut, consultez la section Tâches associées de cet article.
Tâches associées
| Tâche | Article |
|---|---|
| Explique comment définir ou modifier le classement de l'instance de SQL Server. Le changement du classement du serveur ne change pas le classement des bases de données existantes. | Définir ou modifier le classement du serveur |
| Explique comment définir ou modifier le classement d'une base de données utilisateur. Le changement du classement de base de données ne change pas le classement des colonnes de table existantes. | Définir ou modifier le classement de la 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 |
| Explique comment écrire des instructions Transact-SQL qui sont plus portables d’une langue à une autre ou qui prennent en charge plusieurs langues plus facilement | Rédiger des instructions Transact-SQL internationales |
| Explique comment modifier le langage des messages d'erreur et des préférences relatives à l'utilisation et à l'affichage de la date, de l'heure et des devises | Définir une langue de session |
Contenu connexe
Pour plus d’informations, consultez le contenu connexe suivante :
- SQL Server Best Practices Collation Change (Bonnes pratiques relatives au changement de classement dans SQL Server)
- Utiliser le format caractère Unicode pour importer ou exporter des données (SQL Server)
- Rédiger des instructions Transact-SQL internationales
- SQL Server Best Practices Migration to Unicode (plus de support)
- Consortium Unicode
- Norme Unicode
- Prise en charge d’UTF-8 dans OLE DB Driver pour SQL Server
- Nom du classement SQL Server (Transact-SQL)
- Nom de classement Windows (Transact-SQL)
- Introducing UTF-8 support for SQL Server
- COLLATE (Transact-SQL)
- Priorité de classement