2012-06-08 5 views
3

Je stocke du code XML dans une colonne XML dans SQL Server. SQL Server stocke les données en interne dans UTF-16. Par conséquent, le fichier XML stocké doit être en UTF-16.Stocker des données UTF8 dans la colonne UTF16

Le XML que j'ai est en utf-8, il a cette déclaration sur le dessus:

<?xml version="1.0" encoding="UTF-8" ?> 

Lorsque je tente d'insérer xml avec la déclaration UTF-8 je reçois une exception en disant quelque chose sur le codage. Je peux facilement résoudre ce problème de deux façons:

  • en supprimant la déclaration ou

  • en changeant la déclaration

:

<?xml version="1.0" encoding="UTF-16" ?> 

Problème

Je ne sais pas si c'est «sûr» ou correct de simplement enlever ou remplacer la déclaration. Vais-je perdre des données ou le XML sera-t-il corrompu? Ou dois-je convertir la chaîne en C# de utf-8 en utf-16?

+0

C'est toujours une bonne idée de citer des exceptions que vous obtenez et que vous ne comprenez pas actuellement. –

+0

Si vous stockez les fichiers sous forme de texte, stockez-les en tant que texte (c'est-à-dire, traitez-les en tant que tels, ce qui signifie appliquer un codage universel). Bien sûr, cela vous obligerait à supprimer la déclaration de codage en ligne. Je voudrais juste les stocker comme des blobs, mais qui se débarrasse de telles considérations. – Joey

+0

SQL Server stocke les données en interne sous la forme UCS-2, pas UTF-16. Cela n'a d'importance que si vous utilisez des paires de substitution UTF-16. –

Répondre

3

C# chaînes de magasins dans UCS-2, une version plus ancienne de la norme UTF-16. Ainsi, lorsque vous lisez une chaîne UTF-8 en C#, C# la convertit en UCS-2. C'est la variante UCS-2 que vous transmettez à SQL Server.

Vous pouvez modifier la déclaration xml en encoding="UTF-16" ou la supprimer complètement. Il y a quelques différences entre UCS-2 et UTF-16; Je serais intéressant de savoir comment cela affecte C# et SQL Server!

+0

Les différences ont peu d'impact pratique. UCS-2 ne peut représenter que la partie 16 bits de l'Unicode 21bit (appelée BMP). Mais si un caractère non-BMP apparaît dans les données, ce qui est très rare avec la plupart des langages, ils sont représentés avec deux "substituts" chacun et passent de toute façon. Vous pourriez obtenir des valeurs inexactes de "DATALENGTH" mais vous ne le remarquerez probablement jamais. –

+0

@JirkaHanika: Alors que UTF-16 ajoute un moyen supplémentaire de représenter les caractères non-BMP, il n'invalide pas l'ancienne façon? – Andomar

+0

Ce n'est pas le cas. Mais SQL Server continuera simplement à le traiter comme un codage à largeur fixe, traitant un caractère non-BMP comme deux "caractères". Par exemple, si vous avez une colonne 'nvarchar (1)', vous n'y mettrez pas du tout un caractère non-BMP. –

0

SQL Server utilise en interne UCS-2 pour stocker les données XML, mais cela n'a rien à voir avec le formulaire dans lequel vous transmettez les données à SQL Server.

Si par exemple vous l'insérez à l'aide d'un littéral varchar, définissez plutôt un littéral nvarchar et déclarez le codage UTF-16. Exemple:

DECLARE @VAR XML 
INSERT INTO MyTable (MyXmlColumn) 
    VALUES (N'<?xml version="1.0" encoding="UTF-16" ?><doc></doc>') 
+0

L'OP a mentionné un client C#, donc il n'utilise probablement pas les littéraux SQL – Andomar

Questions connexes