Assemblage / jeu de caractères SQL Server 2005/2008 UTF-8
Je ne trouve pas d'option (s) directement pour définir UTF-8 rellé Collations/Charsets dans SQL Server 2005/2008, comme il est possible de définir dans un autre moteur SQL, mais dans SQL Server 2005/2008, il n'y a que des classements latins et SQL.
Existe-t-il une option pour forcer/installer ces classements/jeux de caractères dans le moteur SQL Server (pour les deux versions) 2005/2008 sur le système d'exploitation Win2008
Non, il n'y en a pas. SQL Server ne prend pas en charge UTF-8.
Vous devez définir vos colonnes comme nvarchar/nchar si vous voulez des données unicode. Remarque, SQL Server en interne le stocke en tant que UCS-2.
Notez que cela a été demandé à MS on Connect et il y a ancien article de la base de connaissances . Et quelques infos sur ce blog aussi
Vous ne pouvez pas installer UTF-8 en tant que jeu de caractères car ce n'est pas un jeu de caractères, c'est un encodage.
Si vous souhaitez stocker du texte Unicode, vous utilisez le type de données nvarchar.
Si vous souhaitez stocker du texte encodé en UTF-8, vous le stockez en tant que données binaires (varbinary).
À partir de SQL Server 2019 (actuellement en version bêta/"Community Tech Preview"), il existe une prise en charge native d'UTF-8 via une nouvelle série de classements UTF-8. CEPENDANT, avoir la capacité d'utiliser UTF-8 pas signifie que vous devriez. L'utilisation de l'UTF-8 présente des inconvénients tels que:
- Seuls les 128 premiers points de code font 1 octet (c'est-à-dire le standard 7 bits ASCII set)
- Les presque 2000 points de code suivants font 2 octets, donc aucune économie d'espace sur UTF-16/
NVARCHAR - Les 63k points de code restants dans le BMP (c'est-à-dire la plage U + 0800 - U + FFFF) sont tous de 3 octets, donc 1 octet plus grand que le même dans UTF-16/
NVARCHAR. - Il suffit de le dire: les caractères supplémentaires font 4 octets dans les deux encodages, donc aucune différence d'espace
- Bien que vous puissiez économiser de l'espace en utilisant UTF-8, il y a de très bonnes chances que vous preniez un coup sur les performances pour le faire.
Cela se résume vraiment à ceci: UTF-8 est une conception de format de stockage pour activer les systèmes 8 bits (qui étaient généralement conçus autour de ASCII et ASCII Extended - Code Pages) pour utiliser Unicode sans casser quoi que ce soit ni nécessiter de modification des fichiers existants afin de continuer à fonctionner. UTF-8 est merveilleux pour les systèmes de fichiers et les réseaux, mais les données stockées à l'intérieur SQL Server n'est ni l'un ni l'autre. Le fait que les données se trouvent juste surtout (ou entièrement) dans la plage standard ASCII requiert moins d'espace que les mêmes données lorsque stocké en UTF-16/NVARCHAR est un effet secondaire. Bien sûr, c'est un effet secondaire qui peut s'avérer utile, mais cette décision doit être prise par quelqu'un qui comprend à la fois les données et les conséquences/inconvénients de cette décision. Ceci est pas une fonctionnalité à usage général.
En outre, le cas d'utilisation principal pour UTF-8 (dans SQL Server) est pour le code d'application utilisant déjà UTF-8, peut-être déjà avec un autre SGBDR qui le prend en charge, et il n'y a aucun désir ou capacité de mettre à jour le code d'application/schéma de base de données pour utiliser les types de données NVARCHAR (pour les tables, les variables, les paramètres, etc.), ou pour préfixer les littéraux de chaîne avec un "N" majuscule. L'objectif est le même que la raison de l'existence de l'UTF-8: permettre au code de l'application d'utiliser Unicode sans modifier la structure globale ou rendre les données existantes invalides. Si cela décrit votre situation, utilisez UTF-8, mais sachez qu'il y a encore quelques bugs/problèmes.
Si vous n'avez pas explicitement besoin de travailler avec Unicode sans utiliser NVARCHAR ou des littéraux de chaîne préfixés "N", alors le seul autre scénario où UTF-8 est un avantage est si vous avez BEAUCOUP de la plupart du temps standard ASCII données qui doivent autoriser les caractères Unicode, et vous utilisez NVARCHAR(MAX) (ce qui signifie que la compression des données ne fonctionnera pas), et la table est mise à jour fréquemment (donc l'index de clustered columnstore ne va probablement pas vraiment aider).
Pour plus de détails, veuillez consulter mon article:
Prise en charge native UTF-8 dans SQL Server 2019: Sauveur ou faux prophète?
Dans mon cas, j'ai dû afficher des caractères arabes et ma base de données de développement était en 2014, ici les choses fonctionnaient bien. Ici, dans la requête, je pouvais voir les caractères arabes et mon classement était SQL_Latin1_General_CP1256_CI_AS
Mais ma production était dans SQL Server 2008 et finalement il ne supportait pas le jeu de caractères UTF-8. Ici, je pouvais voir tout ??????????? car UTF-8 n'est pas pris en charge dans SQL 2008.
Ce que j'ai fait, c'est changer tout varchar en nvarchar et je pouvais voir correctement les caractères arabes. Je change également mon classement de base de données 2008 en SQL_Latin1_General_CP1256_CI_AS