SQL Server codage de caractères par défaut

Par défaut - qu'est-ce que l'encodage des caractères pour une base de données dans Microsoft SQL Server?

Comment puis-je voir le codage des caractères dans SQL Server?

  • Voulez-vous dire paramètre de classement?
  • Comme je me souviens, dans MSSQL xml est stocké dans UTF-16, nchar est stocké dans UCS-2
  • Je ne suis pas sûr de savoir si le classement est le bon terme, je veux dire par exemple si c'est à l'aide de "utf-8" ou "iso-8859-1" etc
  • un classement SQL Server est plus qu'un jeu de caractères. Il implique un ordre de tri et de la casse. Voir msdn.microsoft.com/en-us/library/ms187582.aspx
  • SQL Server ne prend pas en implicity utiliser l'utf-8. Pour 8 bits de données, il utilise une page de codes qu'il est déterminé par le classement en cours d'utilisation. Pour la 16 bits de données, il utilise UCS-2. Si une colonne est de 8 bits ou de 16 bits est déterminée par la colonne type de données, par exemple, de type varchar ou nvarchar.
  • Intéressant de noter que la deuxième version diffusée de la même réponse (avec une faute d'orthographe fonction, même!) est la réponse.
  • Il n'y a pas de différence d'encodage entre UTF-16 et UCS-2. La seule différence est que si les Paires de Substitution de l'UCS-2 / BMP Points de Code sont reconnus comme des Points de Code eux-mêmes (c'est à dire des Caractères Supplémentaires).

InformationsquelleAutor david99world | 2011-03-03
  1. 42

    Si vous avez besoin de connaître le classement par défaut d'une base de données nouvellement créée utilisation:

    SELECT SERVERPROPERTY('Collation')

    C'est le classement du serveur pour l'instance de SQL Server que vous êtes en cours d'exécution.

    • l'OP a demandé de codage de caractères, pas de classement.
    • classement détermine l'encodage dans SQL Server.
    • autant que je sache, sqlserver utilise UC2 pour l'unicode types de données, le classement de la valeur que vous obtenez avec SERVERPROPERTY conseils de la page de codes utilisés dans le non unicode types de données, mais vous devez regarder. (par exemple espagnol Moderne est Windows1252)
    • Est-ce à dire que je ne peut pas coller avec le standard varchar même en réglant la totalité de la base de données à un encodage Unicode? J'ai trouvé la non-Unicode à la recherche des classements. Je suis en train de penser comment MySQL t-il: Vous pouvez spécifier le jeu de caractères (sens de l'encodage) et le classement sur la base de données, la table et la colonne de niveau et n'ont pas besoin de ces choses étranges comme nvarchar et N'Text' avec tous ses problèmes de conversion.
    • la réponse courte est non. Mais la réponse est un peu plus compliqué. voir msdn.microsoft.com/en-us/library/ms143726.aspx et stackoverflow.com/questions/9756769/...
    • Correct, SQL Server ne permet pas de réglage VARCHAR colonnes à un encodage Unicode à l'instar de certains autres SGBDR ne. Et, NVARCHAR (ainsi que XML) de données n'a qu'un seul encodage: UTF-16 Little-Endian. La gestion par défaut, en termes de fonctions intégrées, bien que les données UTF-16 (c'est à dire lorsque vous n'utilisez pas un classement de fin de _SC) est à seulement interpréter correctement la première UCS-2 personnages, qui sont un sous-ensemble de l'UTF-16 caractères.

    InformationsquelleAutor ThomasMcLeod
  2. 31

    Codages

    SQL Server stocke les données Unicode (c'est à dire que ce qui est trouvé dans la XML et Npréfixé types) en UCS-2 ET UTF-16 (stockage est le même, UTF-16 ne prend en charge que les Caractères Supplémentaires correctement). Ce n'est pas configurable: il n'y a pas d'option pour utiliser UTF-8 ou UTF-32. Si oui ou non les fonctions intégrées peuvent gérer correctement les Caractères Supplémentaires, et si oui ou non ceux-ci sont triés et comparés correctement, dépend du Classement utilisé. Les anciens Classements assimiler tous les Personnages les uns avec les autres. À partir de SQL Server 2005, ils ont introduit la 90 série de Classements (ceux avec _90_ dans le nom) qui pourraient au moins faire une comparaison binaire sur les Caractères Supplémentaires de sorte que vous pouvez distinguer entre eux, même si ils n'ont pas de tri dans l'ordre souhaité. C'est aussi vrai pour les 100 série de Classements introduit dans SQL Server 2008. SQL Server 2012 a introduit les Classements avec des noms se terminant en _SC que non seulement le tri Supplémentaire correctement les Caractères, mais aussi permettre à des fonctions intégrées de les interpréter comme prévu (c'est à dire le traitement de la paire de substitution comme une seule entité). À partir de SQL Server 2017, tous les nouveaux Classements (le 140 série) implicitement en charge les Caractères Supplémentaires, donc il n'y a pas de nouveaux Classements avec des noms se terminant en _SC.

    De données Non-Unicode (c'est à dire que ce qui est trouvé dans la CHAR, VARCHAR, et TEXT types — mais ne pas utiliser de TEXT, utilisez VARCHAR(MAX) à la place) utilise une 8-bits (ASCII Étendu, DBCS, ou EBCDIC). Le jeu de caractères spécifique /codage est basé sur le Code de la Page, qui à son tour est basé sur le Classement d'une colonne, ou le Classement de la base de données actuelle pour les constantes et les variables, ou le Classement de l'Instance de la variable de curseur ou de noms et GOTO étiquettes, ou de ce qui est spécifié dans une COLLATE clause si l'une est utilisée.

    De voir comment les paramètres régionaux correspondent aux classements, découvrez:

    Pour voir la Page de codes associés à un Classement (c'est le jeu de caractères et n'affecte CHAR /VARCHAR /TEXT de données), exécutez la commande suivante:

    SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'CodePage' ) AS [CodePage];

    Pour voir le LCID (c'est à dire les paramètres régionaux associés à un Classement (ce qui affecte le tri & les règles de comparaison), exécutez la commande suivante:

    SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'LCID' ) AS [LCID];

    Pour afficher la liste des Classements disponibles, ainsi que leurs Lcid et des Pages de Code, exécutez:

    SELECT [name],
       COLLATIONPROPERTY( [name], 'LCID' ) AS [LCID],
       COLLATIONPROPERTY( [name], 'CodePage' ) AS [CodePage]
FROM sys.fn_helpcollations()
ORDER BY [name];

    Par défaut

    Avant de regarder le Serveur et la Base de données par défaut les Classements, il faut comprendre l'importance relative de ces valeurs par défaut.

    Le Serveur (Exemple, vraiment) Classement par défaut est utilisé comme valeur par défaut pour les nouvelles Bases de données (y compris les Bases de données système: master, model, msdb, et tempdb). Mais cela ne signifie pas que toute Base de données (autres que les 4 système DBs) est à l'aide de ce Classement. La Base de données de Classement par défaut peut être modifié à tout moment. Le Serveur de Classement par défaut, cependant, n'est pas si facile à changer. Le serveur/de l'Instance de Classement contrôles:

    • variable locale noms
    • CURSEUR noms
    • Étiquettes GOTO

    La Base de données de Classement par défaut est utilisé de deux manières:

    • comme valeur par défaut pour de nouvelles colonnes de la chaîne. Mais cela ne signifie pas que n'importe quelle chaîne de colonne est à l'aide de ce Classement. Le Classement d'une colonne peut être modifié à tout moment. Ici, sachant que la Base de données par défaut est important comme une indication de ce que les colonnes de la chaîne sont le plus probable pour.
    • que le Classement pour les opérations impliquant des littéraux de chaîne, des variables et des fonctions intégrées qui ne prennent pas de chaîne entrées, mais le produit d'une chaîne de sortie (c'est à dire IF (@InputParam = 'something') ). Ici, sachant que la Base de données par défaut est certainement important, car il régit la façon dont ces opérations vont se comporter.

    Le Classement de la colonne est spécifié dans le COLLATE clause au moment de la CREATE TABLE ou un ALTER TABLE {table_name} ALTER COLUMN, ou si non spécifié, prises à partir de la Base de données par défaut.

    Puisqu'il y a plusieurs couches ici, où un Classement peut être spécifié (Base de données par défaut /colonnes /littéraux & variables), le Classement est déterminé par La Priorité De Classement.

    Tout cela étant dit, la requête suivante affiche la valeur par défaut /paramètres actuels de l'OS, l'Instance SQL Server et la Base de données spécifiée:

    SELECT os_language_version,
       ---
       SERVERPROPERTY('LCID') AS 'Instance-LCID',
       SERVERPROPERTY('Collation') AS 'Instance-Collation',
       SERVERPROPERTY('ComparisonStyle') AS 'Instance-ComparisonStyle',
       SERVERPROPERTY('SqlSortOrder') AS 'Instance-SqlSortOrder',
       SERVERPROPERTY('SqlSortOrderName') AS 'Instance-SqlSortOrderName',
       SERVERPROPERTY('SqlCharSet') AS 'Instance-SqlCharSet',
       SERVERPROPERTY('SqlCharSetName') AS 'Instance-SqlCharSetName',
       ---
       DATABASEPROPERTYEX(N'{database_name}', 'LCID') AS 'Database-LCID',
       DATABASEPROPERTYEX(N'{database_name}', 'Collation') AS 'Database-Collation',
   DATABASEPROPERTYEX(N'{database_name}', 'ComparisonStyle') AS 'Database-ComparisonStyle',
       DATABASEPROPERTYEX(N'{database_name}', 'SQLSortOrder') AS 'Database-SQLSortOrder'
FROM   sys.dm_os_windows_info;

    Mise à JOUR 2018-10-02

    Alors que ce n'est pas une option viable encore, SQL Server 2019 introduit la prise en charge native pour l'UTF-8 dans VARCHAR /CHAR les types de données. Il y a actuellement trop de bugs avec elle pour lui pour être utilisés, mais s'ils sont fixes, alors c'est une option pour certains scénarios. Veuillez voir mon post, "Natif de l'UTF-8 est pris en charge dans SQL Server 2019: Sauveur ou Faux Prophète?", pour une analyse détaillée de cette nouvelle fonctionnalité.

    • Et en plus les valeurs par défaut ci-dessus, l'INSERTION en bloc, par défaut, interprète le fichier entrant comme encodé dans le système OEM. Vous devez spécifier la page de code dans votre AVEC des paramètres, comme, par exemple, si le texte entrants est ANSII: CODEPAGE = 'ACP'
    InformationsquelleAutor Solomon Rutzky
  3. 18

    Le codage de caractères par défaut pour une base de données SQL Server est iso_1, qui est la norme ISO 8859-1. Notez que le codage des caractères dépend du type de données d'une colonne. Vous pouvez obtenir une idée de ce que les encodages de caractères sont utilisés pour les colonnes dans une base de données ainsi que les classements à l'aide de ce SQL:

    select data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name, count(*) count
from information_schema.columns
group by data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name;

    Si c'est à l'aide de la valeur par défaut, la character_set_name devrait être iso_1 pour le char et varchar types de données. Depuis nchar et nvarchar stocker des données Unicode dans l'UCS-2, le character_set_name pour les types de données UNICODE.

    • Ce n'est pas strictement exact. le codage de caractères par défaut dépend de la langue de l'OS au moment de l'installation de SQL Server.
    InformationsquelleAutor Rob at TVSeries.com
  4. 15

    SELECT DATABASEPROPERTYEX('DBName', 'Collation') SQLCollation;

    Où DBName est votre nom de base de données.

    • L'encodage (comme par OP question) et le classement ne sont pas synonymes.
    InformationsquelleAutor JNK
  5. 0

    Je pense que c'est digne d'une autre réponse: bien que l'unicode en interne les données sont stockées en tant que UTF-16 dans Sql Server, c'est le Petit-Boutiste de la saveur, si vous êtes à l'appel de la base de données à partir d'un système externe, vous avez probablement besoin de spécifier l'encodage UTF-16LE.

    InformationsquelleAutor Integrating Stuff