Éviter les modifications de code avec Microsoft SQLServer et Unicode

Question

Comment obtenir que le serveur MSSQL accepte les données Unicode par défaut dans une colonne VARCHAR ou NVARCHAR?

Je sais que vous pouvez le faire en plaçant un N devant la chaîne à placer dans le champ mais, pour être tout à fait honnête, cela semble un peu archaïque en 2008 et en particulier avec SQL Server 2005.

Answer 1

La syntaxe N permet de spécifier un littéral de chaîne unicode dans SQL Server.

N'Unicode string'
'ANSI string'

Dans la mesure du possible, SQL Server convertira automatiquement les deux en utilisant le classement d'une colonne ou celui de la base de données.

Ainsi, si vos littéraux de chaîne ne contiennent pas réellement de caractères unicode, vous n'avez pas besoin de spécifier le préfixe N .

Mais si vos littéraux de chaîne do contiennent des caractères Unicode, le préfixe N est alors nécessaire.

Answer 2

S'il s'agit d'une application Web, votre serveur Web pourrait probablement utiliser UTF8 comme codage par défaut. Ainsi, toutes les données échangées avec le navigateur seraient au format UTF8 et pourront être insérées dans les champs VARCHAR. UTF8 est un bon moyen de faire en sorte que les applications qui ne connaissent pas Unicode s'en servent.

Answer 3

Ils ont vraiment besoin d'un moyen de désactiver le préfixe N ''. Le "cela est nécessaire pour la compatibilité ascendante" L'argument n'a aucun sens pour moi - assurez-vous que ce comportement est le comportement par défaut pour les anciennes applications, mais me permet d'activer les chaînes Unicode par défaut (c'est-à-dire, aucun préfixe N '' requis.) Je découvre qu'il me faut allez jouer avec de grandes zones de mon application pour vous adapter à Unicode sur SQL Server lorsque ce n'est PAS un problème dans Oracle et Postgresql. Allez, Microsoft!

Answer 4

Bien que vous puissiez simplement stocker le contenu UTF8 dans un champ VARCHAR de MSSQL Server tant que la traduction du jeu de caractères n'est pas effectuée, vous devez savoir que:

1. Aucun outil de gestion / de génération de rapports / de données en dehors de votre application ne sera en mesure de comprendre vos caractères non anglais.

2. Les traitements spécifiques à une langue, tels que le tri d'une liste de noms, peuvent ne pas être effectués dans l'ordre acceptable pour toutes les langues.

3. Doit faire attention à la troncature des données. Le fait de tronquer un caractère UTF8 sur plusieurs octets provoque généralement une corruption des données pour le personnage en question. Vous devriez toujours refuser l'entrée si elle dépasse la longueur du champ.

4. Il se peut que la désactivation de la traduction du jeu de caractères ne soit pas aussi facile que vous le pensiez..Même si vous le désactivez dans votre pilote client, il peut toujours être annulé s'il existe une différence de paramètres régionaux entre le client et le SGBDR. page de code utilisée qui entraîne instantanément la corruption des données.

5. Si vous pensez que c'est tout, vous devrez vous inquiéter de vous tromper vous-même.

En résumé, bien que vous puissiez être tenté de suivre cette voie, ce n’est pas une bonne idée. Le changement de code est requis lorsque vous utilisez plusieurs octets.