SQL Server: imposta set di caratteri (non fascicolazione)

Question

Come si imposta il set di caratteri predefinito per i campi durante la creazione di tabelle in SQL Server? In MySQL uno fa questo:

CREATE TABLE tableName (
    name VARCHAR(128) CHARACTER SET utf8 
) DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci; 

Nota che ho impostato il set di caratteri due volte qui. È ridondante, ho aggiunto entrambi i modi solo per dimostrare.

Ho impostato le regole di confronto anche per dimostrare che le regole di confronto sono qualcosa di diverso. Sono non chiedendo informazioni sull'impostazione delle regole di confronto. Mostquestions chiedendo informazioni sui set di caratteri e le codifiche in SQL Server viene risposto con fascicolazione, che è non la stessa cosa.

Answer 1

As stated in BOL

Ogni confronto SQL Server specifica tre proprietà:

• L'ordinamento da utilizzare per tipi di dati Unicode (nchar, nvarchar e ntext). Un ordinamento definisce la sequenza in cui i caratteri sono ordinati e il modo in cui i caratteri vengono valutati nelle operazioni di confronto.
• L'ordinamento da utilizzare per tipi di dati di caratteri non Unicode (char, varchar e testo).
• La tabella codici utilizzata per memorizzare i dati dei caratteri non Unicode.

La citazione di cui sopra è da 2000 documenti. See also this 2008 link. Anche il seguito lo dimostra.

DECLARE @T TABLE 
(
    code TINYINT PRIMARY KEY, 
    Arabic_CS_AS CHAR(1) COLLATE Arabic_CS_AS NULL, 
    Cyrillic_General_CS_AS CHAR(1) COLLATE Cyrillic_General_CS_AS NULL, 
    Latin1_General_CS_AS CHAR(1) COLLATE Latin1_General_CS_AS NULL 
); 

INSERT INTO @T(code) VALUES (200),(201),(202),(203),(204),(205) 

UPDATE @T 
    SET Arabic_CS_AS=CAST(code AS BINARY(1)), 
     Cyrillic_General_CS_AS=CAST(code AS BINARY(1)), 
     Latin1_General_CS_AS=CAST(code AS BINARY(1)) 

SELECT * 
FROM @T 

Risultati

code Arabic_CS_AS Cyrillic_General_CS_AS Latin1_General_CS_AS 
---- ------------ ---------------------- -------------------- 
200 ب   И      È 
201 ة   Й      É 
202 ت   К      Ê 
203 ث   Л      Ë 
204 ج   М      Ì 
205 ح   Н      Í 

Answer 2

Ad ampliare @ risposta di Martin:

Come si imposta un "set di caratteri" in SQL Server dipende dal tipo di dati che si sta utilizzando. Se si sta utilizzando:

• NVARCHAR, NCHAR, e NTEXT (NTEXT è deprecata e non dovrebbe essere usato come di SQL Server 2005) utilizzano tutti il ​​set di caratteri Unicode e questo non può essere modificato. Questi tipi di dati sono tutti codificati come UTF-16 LE (Little Endian) – una codifica a 16 bit con ciascun "carattere" di 2 o 4 byte – e anche questo non può essere modificato. Per questi tipi di dati, le regole di confronto utilizzate riguardano solo le impostazioni locali (come determinato dal LCID del confronto) che determina l'insieme di regole utilizzate per l'ordinamento e il confronto.

• XML, come i tipi N -prefixed, utilizza il set di caratteri Unicode ed è codificato come UTF-16 LE (Little Endian), e nessuno di questi possono essere cambiati. Ma a differenza degli altri tipi di dati stringa, non vi è alcuna Fascicolazione associata ai dati XML in quanto non può essere ordinata o confrontata (almeno non senza prima convertirla in NVARCHAR(MAX) [preferito] o VARCHAR(MAX)).

• VARCHAR, CHAR e TEXT (TEXT è obsoleto e non deve essere utilizzato come di SQL Server 2005) sono tutte le codifiche a 8 bit con ogni "carattere" essere 1 o 2 byte. Il set di caratteri è determinato dalla Pagina codice associata a ogni fascicolazione. Le regole di ordinamento e confronto dipendono dal tipo di regole di confronto utilizzato:

  • SQL regole di confronto del server: Questi tutti hanno nomi che iniziano con SQL_ e sono stati deprecati dalla SQL Server 2000, anche se sono (purtroppo) ancora in largo uso oggi . Questi utilizzano semplici regole indicate come il numero "Ordine ordinamento SQL Server" come trovato nel campo description restituito da sys.fn_helpcollations().
  • Windows Collations: tutti hanno nomi che fanno non iniziano con SQL_. Queste regole di confronto consentono ai dati di stringa non Unicode di utilizzare le regole di ordinamento e confronto Unicode indicate dal LCID del confronto.

Detto questo, per scoprire quale set di caratteri (per CHAR, VARCHAR, e TEXT – cioè non Unicode – dati) è in uso, eseguire la seguente query e prestare la massima attenzione al CodePage campo. Il campo LCID indica il locale utilizzato per l'ordinamento e le regole di confronto per i N -prefixed – cioè Unicode – tipi così come i tipi non Unicode se utilizzando un Windows regole di confronto:

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

Gli ID codice pagina essere tradotto in qualcosa di più significativo tramite la pagina MSDN per Code Page Identifiers.

---

Per quanto riguarda la risposta di Martin del comment su @ O.P.:

E 'un peccato che hanno scelto il fuorviante/incompleta termine "collazione" che si riferisce chiaramente alla Ordinamento: raccogliere definizione.

Se è vero che Microsoft avrebbe potuto fare meglio quando si sceglie un nome, c'è purtroppo un generale, la confusione a livello di settore su termini come "codifica", "set di caratteri", "raccolta", etc. L'uso (o l'uso improprio) di Microsoft di "Collation" ha semplicemente contribuito alla confusione di massa. Ma questa confusione è evidente anche in MySQL come mostrato in questa domanda, dato che "utf8" è specificatamente non un set di caratteri ;-).

UTF-8 è una delle numerose codifiche per il set di caratteri Unicode. UTF-16 e UTF-32 sono le altre due codifiche. Tutte e tre queste codifiche rappresentano esattamente lo stesso set di caratteri Unicode, solo in modi diversi. Guardando l'elenco dei set di caratteri MySQL – 11.1.10 Supported Character Sets and Collations – i set di caratteri "ucs2", "utf8", "utf8mb4", "utf16", "utf16le", "utf32" non sono in realtà set di caratteri, di per sé, ma varie rappresentazioni del Set di caratteri Unicode. Ma, data la sovrapposizione tra i concetti di "set di caratteri" e "codifica", sarebbe difficile non avere questa confusione.La pagina 11.1.10.1 Unicode Character Sets indica che i set di caratteri "utf8mb4", "utf16", "utf16le" e "utf32" sono i set di caratteri Unicode completi mentre "ucs2" e "utf8" sono sottoinsiemi del set di caratteri Unicode, in particolare il primo codice 65.536 punti (aka Basic Plilingual Plane (BMP)).

Per maggiori informazioni riguardo delle regole di confronto tra i vari RDBMS di, si prega di vedere la mia risposta alla seguente domanda sulla DBA.StackExchange:

Does any DBMS have a collation that is both case-sensitive and accent-insensitive?