Parce que MS SQL Server supporte mal UTF-8 par rapport aux autres SGBDR.
MS SQL Server suit la convention, utilisée dans Windows lui-même, selon laquelle les chaînes "étroites" ( char
en C ++ CHAR
ou VARCHAR
en SQL) sont codées dans une "page de code" héritée. Le problème avec les pages de codes est qu’elles ont un nombre limité de caractères (la plupart sont des encodages sur un octet, ce qui limite le rapport à 256 caractères) et sont conçues autour d’une seule langue (ou d’un groupe de langues avec des alphabets similaires). Cela rend difficile le stockage de données multilingues. Par exemple, vous ne pouvez pas stocker des données en russe et en hébreu, car le russe utilise la page de codes 1251 et l'hébreu utilise la page de codes 1255 .
Unicode résout ce problème en utilisant un seul jeu de caractères codé géant pouvant contenir plus d'un million de caractères, suffisamment pour représenter toutes les langues du monde. Il existe plusieurs schémas de codage Unicode; Microsoft préfère utiliser UTF-16 , pour des raisons historiques . Etant donné que UTF-16 représente les chaînes sous la forme d'une séquence d'unités de code 16 bits au lieu des 8 bits traditionnels, un type de caractère séparé est nécessaire. En MSVC ++, c'est wchar_t
. Et en MS SQL, c'est NCHAR
ou NVARCHAR
. Le N
signifie « national » , qui semble en arrière pour moi parce que Unicode est sur le point entre -nationalization, mais c'est la terminologie ISO.
D'autres implémentations SQL vous permettent de stocker du texte UTF-8 dans une VARCHAR
colonne. UTF-8 est un codage de longueur variable (1 à 4 octets par caractère) optimisé pour le cas où vos données se situent principalement dans la plage Basic Basic (représentées par le même octet qu'un caractère par caractère ASCII), mais peuvent représenter. n'importe quel caractère Unicode. Ainsi, vous éviteriez le problème de "deux fois plus d'espace" mentionné par bwalk2895.
Malheureusement, MS SQL Server ne prend pas en charge UTF-8VARCHAR
. Vous devez donc utiliser UTF-16 à la place (et gaspiller de l'espace pour du texte ASCII), utiliser une page de code non Unicode (et perdre la possibilité de représenter des caractères étrangers), ou stockez UTF-8 dans une BINARY
colonne (et faites face à des inconvénients tels que les fonctions de chaîne SQL ne fonctionnant pas correctement ou devant afficher les données sous forme de vidage hexadécimal dans votre gestionnaire de base de données GUI).