Assemblage / jeu de caractères SQL Server 2005/2008 UTF-8

16

Je ne trouve pas d'option (s) directement pour définir UTF-8rellated Collations/Charsetsdans 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

— mKorbel
source

13

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 sur Connect et qu'il existe un ancien article de la base de connaissances . Et quelques infos sur ce blog aussi

— gbn
source

6

De plus, si vous voulez faire une correspondance de texte sur un nvarchar avec des caractères étrangers, vous devez faire correspondre une chaîne formatée avec un N avant la chaîne (par exemple N'οἰκονόμον ').

— swasheck

Ce comportement a-t-il changé dans une version récente de SQL Server?

— Seiyria

@Seiyria: non, même comportement

— gbn

Quiconque trouve son chemin vers cette réponse, accédez à la page MS Connect et votez pour que MS prenne en charge UTF-8 sur SQL Server. Merci: D

— DarcyThomas

@DarcyThomas Cela devient une réalité dans SQL Server 2019, bien que ce ne soit toujours pas quelque chose que l'on devrait utiliser à moins d'en avoir un besoin explicite. Veuillez consulter ma réponse pour plus de détails.

— Solomon Rutzky

2

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 nvarchartype de données.

Si vous souhaitez stocker du texte encodé en UTF-8, vous le stockez en tant que données binaires ( varbinary).

— Guffa
source

1

À 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 possibilité d'utiliser UTF-8 ne signifie pas 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 l'ensemble ASCII 7 bits standard)
Les presque 2000 points de code suivants font 2 octets, donc aucune économie d'espace par rapport à UTF-16 / NVARCHAR
Les 63k points de code restants dans la BMP (c'est-à-dire la plage U + 0800 - U + FFFF) sont tous de 3 octets, donc 1 octet de plus que le même caractère 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 permettre aux systèmes 8 bits (qui étaient généralement conçus autour de l'ASCII et de l'ASCII étendu - Pages de code) d'utiliser Unicode sans casser quoi que ce soit ou nécessiter aucune modification de l'existant. fichiers afin de continuer à fonctionner. UTF-8 est merveilleux pour les systèmes de fichiers et les réseaux, mais les données stockées dans SQL Server ne le sont pas non plus. Le fait que les données qui se trouvent être principalement (ou entièrement) dans la plage ASCII standard nécessite moins d'espace que les mêmes données lorsqu'elles sont stockées en UTF-16 / NVARCHARest 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 une personne qui comprend à la fois les données et les conséquences / inconvénients de cette décision. C'estpas une fonctionnalité pour un 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 possibilité de mettre à jour le code d'application / schéma de base de données pour utiliser des NVARCHARtypes de données (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 NVARCHARou utiliser 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 données ASCII principalement standard qui doivent permettre Les caractères Unicode, et vous utilisez NVARCHAR(MAX)(ce qui signifie que la compression des données ne fonctionnera pas), et le tableau est mis à 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?

— Solomon Rutzky
source

0

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

— Halim
source