Supporto Unicode e delle regole di confronto
Si applica a: 
SQL Server Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Piattaforma di strumenti analitici (PDW) Endpoint di analisi SQL in Microsoft Fabric Warehouse in Microsoft Fabric
Le regole di confronto in SQL Server offrono regole di ordinamento e proprietà di distinzione tra maiuscole e minuscole e tra caratteri accentati e non accentati per i dati. Le regole di confronto usate con dati di tipo carattere, quali char e varchar, definiscono la tabella codici e i caratteri corrispondenti che possono essere rappresentati per quel tipo di dati.
Sia che si installi una nuova istanza di SQL Server, si ripristini il backup di un database o si stabiliscano connessioni tra database server e client, è importante comprendere i requisiti delle impostazioni locali, l'ordinamento e la modalità di distinzione tra maiuscole e minuscole e tra caratteri accentati e non accentati dei dati da usare. Per visualizzare l'elenco delle regole di confronto disponibili nell'istanza di SQL Server, vedere sys.fn_helpcollations (Transact-SQL).
Quando si selezionano le regole di confronto per un server, un database, una colonna o un'espressione, vengono assegnate determinate caratteristiche ai dati. Queste caratteristiche influiscono sui risultati di molte operazioni eseguite nel database. Ad esempio, quando viene costruita una query tramite ORDER BY, l'ordinamento del set di risultati può dipendere dalle regole di confronto applicate al database o specificate in una clausola COLLATE al livello di espressione della query.
Per usare in modo ottimale il supporto delle regole di confronto di SQL Server, si dovrebbe approfondire la conoscenza dei termini specificati in questo articolo e di come si correlano alle caratteristiche dei dati.
Termini delle regole di confronto
Regole di confronto
Le regole di confronto specificano gli schemi di bit che rappresentano i diversi caratteri in un set di dati. Le regole di confronto determinano inoltre le regole in base alle quali i dati vengono ordinati e confrontati. SQL Server supporta l'archiviazione di oggetti con regole di confronto diverse in un singolo database. Per le colonne non Unicode, l'impostazione delle regole di confronto specifica la tabella codici dei dati e i caratteri che possono essere rappresentati. Per i dati spostati tra colonne non Unicode, è necessaria la conversione dalla tabella codici di origine a quella di destinazione.
I risultati di un'istruzione Transact-SQL possono variare quando l'istruzione viene eseguita nel contesto di database diversi che usano impostazioni diverse per le regole di confronto. Se possibile, usare regole di confronto standardizzate per l'organizzazione. In questo modo, non è necessario specificare le regole di confronto in ogni carattere o espressione Unicode. Se è necessario usare oggetti con impostazioni diverse per tabelle codici e regole di confronto, codificare le query in modo da considerare la precedenza delle regole di confronto. Per altre informazioni, vedere Precedenza delle regole di confronto (Transact-SQL).
Alle regole di confronto sono associate le opzioni seguenti: distinzione tra maiuscole e minuscole, distinzione tra caratteri accentati e non accentati, distinzione dei caratteri Kana, distinzione di larghezza e distinzione dei selettori di variazione. SQL Server 2019 (15.x) introduce un'opzione aggiuntiva per la codifica UTF-8.
È possibile specificare queste opzioni aggiungendole al nome delle regole di confronto. Ad esempio, le regole di confronto Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 prevedono distinzione tra lettere maiuscole e minuscole, distinzione tra caratteri accentati e non accentati, distinzione dei caratteri Kana, distinzione di larghezza e codifica UTF-8. Sempre a titolo di esempio, le regole di confronto Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS prevedono le opzioni seguenti: nessuna distinzione tra lettere maiuscole e minuscole, nessuna distinzione tra caratteri accentati e non accentati, distinzione dei caratteri Kana, distinzione di larghezza, distinzione dei selettori di variazione e usano la codifica non Unicode.
Il comportamento associato a queste opzioni è descritto nella tabella seguente:
| Opzione | Descrizione |
|---|---|
| Distinzione maiuscole/minuscole (_CS) | Opera una distinzione tra lettere maiuscole e minuscole. Se questa opzione è selezionata, le lettere minuscole precedono le versioni maiuscole corrispondenti nell'ordinamento. Se questa opzione non è selezionata, le regole di confronto non fanno distinzione tra maiuscole e minuscole. Ovvero, in SQL Server non viene operata una distinzione tra lettere maiuscole e minuscole, che vengono considerate identiche ai fini dell'ordinamento. È possibile selezionare in modo esplicito l'esclusione della distinzione tra maiuscole e minuscole specificando _CI. |
| Distinzione caratteri accentati/non accentati (_AS) | Opera una distinzione tra caratteri accentati e non accentati. Il carattere "a", ad esempio, non viene considerato uguale ad "ấ". Se questa opzione non è selezionata, le regole di confronto non fanno distinzione tra caratteri accentati e non accentati. Ovvero, in SQL Server non viene opera una distinzione tra caratteri accentati e non accentati, che vengono considerati identici ai fini dell'ordinamento. È possibile selezionare in modo esplicito l'esclusione della distinzione tra caratteri accentati e non accentati specificando _AI. |
| Distinzione Kana (_KS) | Opera una distinzione tra i due tipi di caratteri Kana giapponesi: Hiragana e Katakana. Se questa opzione non è selezionata, le regole di confronto non fanno distinzione tra caratteri Kana. Ovvero, in SQL Server i caratteri Hiragana e Katakana vengono considerati identici ai fini dell'ordinamento. Omettere questa opzione è il solo metodo per specificare di non effettuare la distinzione Kana. |
| Distinzione larghezza (_WS) | Opera una distinzione tra caratteri a larghezza intera e caratteri a metà larghezza. Se questa opzione non viene selezionata, SQL Server considera identiche le rappresentazioni con caratteri a larghezza intera e a metà larghezza dello stesso carattere ai fini dell'ordinamento. Omettere questa opzione è il solo metodo per specificare di non effettuare la distinzione larghezza. |
| Distinzione dei selettori di variazione (_VSS) | Opera una distinzione tra vari selettori di variazione di simboli ideografici nelle regole di confronto giapponesi Japanese_Bushu_Kakusu_140 e Japanese_XJIS_140 introdotte in SQL Server 2017 (14.x). Una sequenza di variazione è costituita da un carattere di base e da un selettore di variazione. Se questa opzione _VSS option non è selezionata, le regole di confronto non fanno distinzione tra selettori di variazione e il selettore di variazione non viene considerato nel confronto. In altri termini, SQL Server considera identici, ai fini dell'ordinamento, i caratteri basati sullo stesso carattere con diversi selettori di variazione. Per altre informazioni, vedere il database delle variazioni dei simboli ideografici Unicode. Le regole di confronto con distinzione tra selettori di variazione (_VSS) non sono supportate negli indici di ricerca full-text. Questi indici supportano solo le opzioni Distinzione caratteri accentati/non accentati (_AS), Distinzione Kana (_KS) e Distinzione larghezza (_WS). I motori di CLR e XML in SQL Server non supportano i selettori di variazione (_VSS). |
| Binario (_BIN)1 | Ordina e confronta i dati nelle tabelle di SQL Server in base agli schemi di bit definiti per ogni carattere. L'ordinamento binario prevede la distinzione tra lettere maiuscole e minuscole e tra caratteri accentati e non accentati e rappresenta inoltre il tipo di ordinamento più rapido. Per altre informazioni, vedere la sezione Regole di confronto binarie in questo articolo. |
| Punto di codice binario (_BIN2)1 | Ordina e confronta i dati nelle tabelle di SQL Server in base ai punti di codice Unicode per i dati Unicode. Per i dati non Unicode, il punto di codice binario usa confronti identici a quelli per gli ordinamenti binari. Il vantaggio di usare un ordinamento con punto di codice binario è rappresentato dal fatto che non è necessario alcun riordinamento dei dati nelle applicazioni che confrontano i dati ordinati di SQL Server. Di conseguenza, l'ordinamento con punto di codice binario consente di semplificare lo sviluppo delle applicazioni e di ottenere un possibile miglioramento delle prestazioni. Per altre informazioni, vedere la sezione Regole di confronto binarie in questo articolo. |
| UTF-8 (_UTF8) | Abilita l'archiviazione dei dati con codifica UTF-8 in SQL Server. Se questa opzione non è selezionata, SQL Server usa il formato di codifica non Unicode predefinito per i tipi di dati applicabili. Per altre informazioni, vedere la sezione Supporto di UTF-8 in questo articolo. |
1 Se si seleziona Binario o Punto di codice binario, le opzioni Distinzione maiuscole/minuscole (_CS), Distinzione caratteri accentati/non accentati (_AS), Distinzione Kana (_KS) e Distinzione larghezza (_WS) non sono disponibili.
Esempi di opzioni per le regole di confronto
Le regole di confronto sono costituite da una serie di suffissi che definiscono la distinzione tra lettere maiuscole e minuscole, tra caratteri accentati e non accentati, della larghezza o dei caratteri Kana. Gli esempi seguenti descrivono i tipi di ordinamento delle varie combinazioni di suffissi.
| Suffisso delle regole di confronto di Windows | Descrizione dell'ordinamento |
|---|---|
| _BIN1 | Ordinamento binario |
| _BIN21, 2 | Ordinamento con punto di codice binario |
| _CI_AI2 | Senza distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CI_AI_KS2 | Senza distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CI_AI_KS_WS2 | Senza distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, con distinzione di larghezza |
| _CI_AI_WS2 | Senza distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, con distinzione di larghezza |
| _CI_AS2 | Senza distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CI_AS_KS2 | Senza distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CI_AS_KS_WS2 | Senza distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, con distinzione di larghezza |
| _CI_AS_WS2 | Senza distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, con distinzione di larghezza |
| _CS_AI2 | Con distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CS_AI_KS2 | Con distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CS_AI_KS_WS2 | Con distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, con distinzione di larghezza |
| _CS_AI_WS2 | Con distinzione tra lettere maiuscole e minuscole, senza distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, con distinzione di larghezza |
| _CS_AS2 | Con distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CS_AS_KS2 | Con distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, senza distinzione di larghezza |
| _CS_AS_KS_WS2 | Con distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, con distinzione dei caratteri Kana, con distinzione di larghezza |
| _CS_AS_WS2 | Con distinzione tra lettere maiuscole e minuscole, con distinzione tra caratteri accentati e non accentati, senza distinzione dei caratteri Kana, con distinzione di larghezza |
1 Se si seleziona Binario o Punto di codice binario, le opzioni Distinzione maiuscole/minuscole (_CS), Distinzione caratteri accentati/non accentati (_AS), Distinzione Kana (_KS) e Distinzione larghezza (_WS) non sono disponibili.
2 L'aggiunta dell'opzione UTF-8 (_UTF8) consente la codifica dei dati Unicode con UTF-8. Per altre informazioni, vedere la sezione Supporto di UTF-8 in questo articolo.
Set di regole di confronto
SQL Server supporta i set di regole di confronto seguenti:
Regole di confronto di Windows
Le regole di confronto di Windows definiscono regole per l'archiviazione dei dati di tipo carattere basate sulle impostazioni locali del sistema Windows associate. Per le regole di confronto di Windows, è possibile implementare un confronto dei dati non Unicode mediante lo stesso algoritmo dei dati Unicode. Le regole di confronto di base di Windows specificano l'alfabeto o la lingua da usare quando viene applicato l'ordinamento del dizionario. Le regole specificano anche la tabella codici usata per l'archiviazione di dati di tipo carattere non Unicode. Sia l'ordinamento Unicode che quello non Unicode sono compatibili con i confronti di stringhe di una versione specifica di Windows. In questo modo viene garantita la coerenza tra i tipi di dati in SQL Server e gli sviluppatori possono ordinare le stringhe all'interno delle applicazioni mediante le stesse regole usate da SQL Server. Per altre informazioni, vedere Windows_collation_name (Transact-SQL).
Regole di confronto binarie
Le regole di confronto binarie ordinano i dati in base alla sequenza di valori codificati definiti dalle impostazioni locali e dal tipo di dati. Supportano la distinzione tra maiuscole e minuscole. In SQL Server le regole di confronto binarie definiscono le impostazioni locali e la tabella codici ANSI usata. In questo modo viene applicato un ordinamento binario. Grazie alla loro semplicità, le regole di confronto binarie consentono di migliorare le prestazioni dell'applicazione. Per i tipi di dati non Unicode, il confronto dei dati è basato sui punti di codice definiti nella tabella codici ANSI. Per i tipi di dati Unicode, il confronto dei dati è basato sui punti di codice Unicode. Per le regole di confronto binarie nei tipi di dati Unicode, le impostazioni locali non vengono considerate ai fini dell'ordinamento dei dati. Ad esempio, l'uso di Latin1_General_BIN e Japanese_BIN su dati Unicode restituisce risultati di ordinamento identici. Per altre informazioni, vedere Windows_collation_name (Transact-SQL).
In SQL Server esistono due tipi di regole di confronto binarie:
Le regole di confronto BIN precedenti, che eseguono un confronto tra punti di codice incompleto per i dati Unicode. Tali regole di confronto binarie legacy eseguono il confronto del primo carattere come WCHAR e quindi un confronto byte per byte. Nelle regole di confronto BIN solo il primo carattere viene ordinato in base al punto di codice e i restanti caratteri vengono ordinati in base ai relativi valori di byte.
Le regole di confronto BIN2 più recenti, che implementano un confronto tra punti di codice puro. Nelle regole di confronto BIN2 tutti i caratteri vengono ordinati in base ai relativi punti di codice. Poiché la piattaforma Intel ha un'architettura little endian, i caratteri di codice Unicode vengono sempre archiviati con i byte scambiati.
Regole di confronto di SQL Server
Le regole di confronto SQL Server (SQL_*) garantiscono la compatibilità di ordinamento con le versioni precedenti di SQL Server. Le regole di ordinamento del dizionario per i dati non Unicode sono incompatibili con qualsiasi routine di ordinamento fornita dai sistemi operativi Windows. Tuttavia l'ordinamento dei dati Unicode è compatibile con una versione specifica di regole di ordinamento di Windows. Dato che le regole di confronto di SQL Server differiscono per i dati non Unicode e i dati Unicode, confrontando gli stessi dati vengono visualizzati risultati diversi, a seconda del tipo di dati sottostante.
Ad esempio, se si usano le regole di confronto SQL SQL_Latin1_General_CP1_CI_AS, la stringa non Unicode 'a-c' è minore della stringa 'ab' perché il segno meno (-) viene ordinato come carattere separato che precede b. Tuttavia, se si convertono queste stringhe in Unicode e si esegue lo stesso confronto, la stringa Unicode N'a-c' viene considerata maggiore di N'ab', perché le regole di ordinamento Unicode usano un ordinamento di parole che ignora il segno meno.
Per altre informazioni, vedere Nome delle regole di confronto di SQL Server (Transact-SQL).
Durante l'installazione di SQL Server, l'impostazione di installazione predefinita per le regole di confronto è determinata dalle impostazioni locali del sistema operativo. È possibile modificare le regole di confronto a livello di server durante l'installazione oppure modificando le impostazioni locali del sistema operativo prima dell'installazione. Per motivi di compatibilità con le versioni precedenti, le regole di confronto predefinite sono impostate sulla versione disponibile meno recente associata a impostazioni locali specifiche. Non sempre, quindi, si tratta delle regole di confronto consigliate. Per sfruttare tutti i vantaggi delle funzionalità di SQL Server, modificare le impostazioni di installazione predefinite per usare le regole di confronto di Windows. Ad esempio, per le impostazioni locali del sistema operativo "Inglese (Stati Uniti)" (tabella codici 1252), le regole di confronto predefinite durante l'installazione sono impostate su SQL_Latin1_General_CP1_CI_AS ed è possibile modificare l'impostazione scegliendo la controparte di Windows più simile, Latin1_General_100_CI_AS_SC.
Nota
Quando si aggiorna un'istanza in lingua inglese di SQL Server, è possibile specificare le regole di confronto di SQL Server (SQL_*) per assicurare la compatibilità con le istanze esistenti di SQL Server. Poiché le regole di confronto predefinite per un'istanza di SQL Server vengono definite durante la configurazione, è importante specificare attentamente le impostazioni delle regole di confronto quando le condizioni riportate di seguito sono vere:
- Il codice dell'applicazione dipende dal comportamento di regole di confronto di SQL Server precedenti.
- È necessario archiviare dati di tipo carattere in più lingue.
Livelli delle regole di confronto
L'impostazione delle regole di confronto è supportata ai seguenti livelli di un'istanza di SQL Server:
- Regole di confronto a livello di server
- Regole di confronto a livello di database
- Regole di confronto a livello di colonna
- Regole di confronto a livello di espressione
Regole di confronto a livello di server
Le regole di confronto del server predefinite vengono determinate durante l'installazione di SQL Server e diventano le regole predefinite per i database di sistema e per tutti i database utente.
La tabella seguente illustra le designazioni delle regole di confronto predefinite determinate dalle impostazioni locali del sistema operativo, inclusi i relativi identificatori delle impostazioni locali (LCID) di Windows e SQL:
| Impostazioni locali di Windows | Identificatore delle impostazioni locali (LCID) di Windows | LCID SQL | Regole di confronto predefinite |
|---|---|---|---|
| Afrikaans (Sud Africa) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| Albanese (Albania) | 0x041c | 0x041c | Albanian_CI_AS |
| Alsaziano (Francia) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| Amarico (Etiopia) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| Arabo (Algeria) | 0x1401 | 0x0401 | Arabic_CI_AS |
| Arabo (Bahrein) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| Arabo (Egitto) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| Arabo (Iraq) | 0x0801 | 0x0401 | Arabic_CI_AS |
| Arabo (Giordania) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| Arabo (Kuwait) | 0x3401 | 0x0401 | Arabic_CI_AS |
| Arabo (Libano) | 0x3001 | 0x0401 | Arabic_CI_AS |
| Arabo (Libia) | 0x1001 | 0x0401 | Arabic_CI_AS |
| Arabo (Marocco) | 0x1801 | 0x0401 | Arabic_CI_AS |
| Arabo (Oman) | 0x2001 | 0x0401 | Arabic_CI_AS |
| Arabo (Qatar) | 0x4001 | 0x0401 | Arabic_CI_AS |
| Arabo (Arabia Saudita) | 0x0401 | 0x0401 | Arabic_CI_AS |
| Arabo (Siria) | 0x2801 | 0x0401 | Arabic_CI_AS |
| Arabo (Tunisia) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| Arabo (Emirati Arabi Uniti) | 0x3801 | 0x0401 | Arabic_CI_AS |
| Arabo (Yemen) | 0x2401 | 0x0401 | Arabic_CI_AS |
| Armeno (Armenia) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| Assamese (India) | 0x044d | 0x044d | Non disponibile a livello di server |
| Azerbaigiano (Azerbaigian, alfabeto cirillico) | 0x082c | 0x082c | Deprecato, non disponibile a livello di server |
| Azerbaigiano (Azerbaigian, alfabeto latino) | 0x042c | 0x042c | Deprecato, non disponibile a livello di server |
| Baschiro (Russia) | 0x046d | 0x046d | Latin1_General_CI_AI |
| Basco (Province basche) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| Bielorusso (Bielorussia) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| Bengalese (Bangladesh) | 0x0845 | 0x0445 | Non disponibile a livello di server |
| Bengalese (India) | 0x0445 | 0x0439 | Non disponibile a livello di server |
| Bosniaco (Bosnia ed Erzegovina, alfabeto cirillico) | 0x201a | 0x201a | Latin1_General_CI_AI |
| Bosniaco (Bosnia ed Erzegovina, alfabeto latino) | 0x141a | 0x141a | Latin1_General_CI_AI |
| Bretone (Francia) | 0x047e | 0x047e | Latin1_General_CI_AI |
| Bulgaro (Bulgaria) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| Catalano (Catalogna) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| Cinese (Hong Kong - R.A.S., Repubblica popolare cinese) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Cinese (RAS di Macao) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| Cinese (RAS di Macao) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| Cinese (RPC) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| Cinese (RPC) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Cinese (Singapore) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| Cinese (Singapore) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| Cinese (Taiwan) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| Cinese (Taiwan) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| Corso (Francia) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| Croato (Bosnia ed Erzegovina, alfabeto latino) | 0x101a | 0x041a | Croatian_CI_AS |
| Croato (Croazia) | 0x041a | 0x041a | Croatian_CI_AS |
| Ceco (Repubblica Ceca) | 0x0405 | 0x0405 | Czech_CI_AS |
| Danese (Danimarca) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| Dari (Afghanistan) | 0x048c | 0x048c | Latin1_General_CI_AI |
| Divehi (Maldive) | 0x0465 | 0x0465 | Non disponibile a livello di server |
| Olandese (Belgio) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| Olandese (Paesi Bassi) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Australia) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Belize) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Canada) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Caraibi) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| Inglese (India) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Irlanda) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Giamaica) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Malaysia) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Nuova Zelanda) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Filippine) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Singapore) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Sud Africa) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Trinidad e Tobago) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Regno Unito) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| Inglese (Stati Uniti) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| Inglese (Zimbabwe) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| Estone (Estonia) | 0x0425 | 0x0425 | Estonian_CI_AS |
| Faroese (Fær Øer) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| Filippino (Filippine) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| Finlandese (Finlandia) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| Francese (Belgio) | 0x080c | 0x040c | French_CI_AS |
| Francese (Canada) | 0x0c0c | 0x040c | French_CI_AS |
| Francese (Francia) | 0x040c | 0x040c | French_CI_AS |
| Francese (Lussemburgo) | 0x140c | 0x040c | French_CI_AS |
| Francese (Monaco) | 0x180c | 0x040c | French_CI_AS |
| Francese (Svizzera) | 0x100c | 0x040c | French_CI_AS |
| Frisone (Paesi Bassi) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| Galiziano | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| Georgiano (Georgia) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| Georgiano (Georgia) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| Tedesco - ordinamento alfabetico telefonico (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| Tedesco (Austria) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| Tedesco (Germania) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| Tedesco (Liechtenstein) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| Tedesco (Lussemburgo) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| Tedesco (Svizzera) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| Greco (Grecia) | 0x0408 | 0x0408 | Greek_CI_AS |
| Groenlandese (Groenlandia) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| Gujarati (India) | 0x0447 | 0x0439 | Non disponibile a livello di server |
| Hausa (Nigeria, alfabeto latino) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| Ebraico (Israele) | 0x040d | 0x040d | Hebrew_CI_AS |
| Hindi (India) | 0x0439 | 0x0439 | Non disponibile a livello di server |
| Ungherese (Ungheria) | 0x040e | 0x040e | Hungarian_CI_AS |
| Ungherese (ordinamento tecnico) | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| Islandese (Islanda) | 0x040f | 0x040f | Icelandic_CI_AS |
| Igbo (Nigeria) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| Indonesiano (Indonesia) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (Canada, alfabeto latino) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| Inuktitut (alfabeto sillabico) Canada | 0x045d | 0x045d | Latin1_General_CI_AI |
| Irlandese (Irlanda) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| Italiano (Italia) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| Italiano (Svizzera) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| Giapponese (Giappone XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| Giapponese (Giappone) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| Kannada (India) | 0x044b | 0x0439 | Non disponibile a livello di server |
| Kazaco (Kazakstan) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| Khmer (Cambogia) | 0x0453 | 0x0453 | Non disponibile a livello di server |
| Quiché (Guatemala) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| Kinyarwanda (Ruanda) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| Konkani (India) | 0x0457 | 0x0439 | Non disponibile a livello di server |
| Coreano (ordinamento dizionario coreano) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| Kirghiso (Kirghizistan) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| Lao (Repubblica popolare democratica del Laos) | 0x0454 | 0x0454 | Non disponibile a livello di server |
| Lettone (Lettonia) | 0x0426 | 0x0426 | Latvian_CI_AS |
| Lituano (Lituania) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| Basso sorabo (Germania) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| Lussemburghese (Lussemburgo) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| Macedone (Macedonia del Nord) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| Malese (Brunei Darussalam) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| Malese (Malaysia) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| Malayalam (India) | 0x044c | 0x0439 | Non disponibile a livello di server |
| Maltese (Malta) | 0x043a | 0x043a | Latin1_General_CI_AI |
| Maori (Nuova Zelanda) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| Mapudungun (Cile) | 0x047a | 0x047a | Latin1_General_CI_AI |
| Marathi (India) | 0x044e | 0x0439 | Non disponibile a livello di server |
| Mohawk (Canada) | 0x047c | 0x047c | Latin1_General_CI_AI |
| Mongolo (Mongolia) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| Mongolo (RPC) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| Nepalese (Nepal) | 0x0461 | 0x0461 | Non disponibile a livello di server |
| Norvegese (Bokmål, Norvegia) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| Norvegese (Nynorsk, Norvegia) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| Occitano (Francia) | 0x0482 | 0x040c | French_CI_AS |
| Odia (India) | 0x0448 | 0x0439 | Non disponibile a livello di server |
| Pashto (Afghanistan) | 0x0463 | 0x0463 | Non disponibile a livello di server |
| Persiano (Iran) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| Polacco (Polonia) | 0x0415 | 0x0415 | Polish_CI_AS |
| Portoghese (Brasile) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| Portoghese (Portogallo) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| Punjabi (India) | 0x0446 | 0x0439 | Non disponibile a livello di server |
| Quechua (Bolivia) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Ecuador) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| Quechua (Perù) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| Romeno (Romania) | 0x0418 | 0x0418 | Romanian_CI_AS |
| Romancio (Svizzera) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| Russo (Russia) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| Sacha (Russia) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| Sami (Inari, Finlandia) | 0x243b | 0x083b | Latin1_General_CI_AI |
| Sami (Lule, Norvegia) | 0x103b | 0x043b | Latin1_General_CI_AI |
| Sami (Lule, Svezia) | 0x143b | 0x083b | Latin1_General_CI_AI |
| Sami (settentrionale, Finlandia) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| Sami (settentrionale, Norvegia) | 0x043b | 0x043b | Latin1_General_CI_AI |
| Sami (settentrionale, Svezia) | 0x083b | 0x083b | Latin1_General_CI_AI |
| Sami (Skolt, Finlandia) | 0x203b | 0x083b | Latin1_General_CI_AI |
| Sami (meridionale, Norvegia) | 0x183b | 0x043b | Latin1_General_CI_AI |
| Sami (meridionale, Svezia) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| Sanscrito (India) | 0x044f | 0x0439 | Non disponibile a livello di server |
| Serbo (Bosnia ed Erzegovina, alfabeto cirillico) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbo (Bosnia ed Erzegovina, alfabeto latino) | 0x181a | 0x081a | Latin1_General_CI_AI |
| Serbo (Serbia, alfabeto cirillico) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| Serbo (Serbia, alfabeto latino) | 0x081a | 0x081a | Latin1_General_CI_AI |
| Sotho del nord/Sotho settentrionale (Sudafrica) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| SeTswana/Tswana (Sudafrica) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| Singalese (Sri Lanka) | 0x045b | 0x0439 | Non disponibile a livello di server |
| Slovacco (Slovacchia) | 0x041b | 0x041b | Slovak_CI_AS |
| Sloveno (Slovenia) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| Spagnolo (Argentina) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Bolivia) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Cile) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Colombia) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Costa Rica) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Repubblica Dominicana) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Ecuador) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (El Salvador) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Guatemala) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Honduras) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Messico) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Nicaragua) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Panama) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Paraguay) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Perù) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Porto Rico) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Spagna) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Spagna, ordinamento tradizionale) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| Spagnolo (Stati Uniti) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| Spagnolo (Uruguay) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| Spagnolo (Venezuela) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| Swahili (Kenya) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| Svedese (Finlandia) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| Svedese (Svezia) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| Siriano (Siria) | 0x045a | 0x045a | Non disponibile a livello di server |
| Tagico (Tajikistan) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| Tamazight (Algeria, alfabeto latino) | 0x085f | 0x085f | Latin1_General_CI_AI |
| Tamil (India) | 0x0449 | 0x0439 | Non disponibile a livello di server |
| Tartaro (Russia) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| Telugu (India) | 0x044a | 0x0439 | Non disponibile a livello di server |
| Thai (Tailandia) | 0x041e | 0x041e | Thai_CI_AS |
| Tibetano (RPC) | 0x0451 | 0x0451 | Non disponibile a livello di server |
| Turco (Turchia) | 0x041f | 0x041f | Turkish_CI_AS |
| Turcomanno (Turkmenistan) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| Uiguro (RPC) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| Ucraino (Ucraina) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| Alto sorabo (Germania) | 0x042e | 0x042e | Latin1_General_CI_AI |
| Urdu (Pakistan) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| Uzbeco (Uzbekistan, alfabeto cirillico) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| Uzbeco (Uzbekistan, alfabeto latino) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| Vietnamita (Vietnam) | 0x042a | 0x042a | Vietnamese_CI_AS |
| Gallese (Regno Unito) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| Wolof (Senegal) | 0x0488 | 0x040c | French_CI_AS |
| Xhosa/isiXhosa (Sudafrica) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| Yi (RPC) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| Yoruba (Nigeria) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| Zulu/isiZulu (Sudafrica) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
Una volta che le regole di confronto sono state assegnate al server, è possibile modificarle solo esportando tutti i dati e gli oggetti di database, ricostruendo il database master e importando tutti i dati e gli oggetti di database. Anziché modificare le regole di confronto predefinite di un'istanza di SQL Server, è possibile specificare quelle desiderate quando si creano nuovi database o colonne di database.
Per eseguire una query sulle regole di confronto del server per un'istanza di SQL Server, usare la funzione SERVERPROPERTY:
SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));
Per eseguire una query sul server per tutte le regole di confronto disponibili, usare la funzione predefinita fn_helpcollations() seguente:
SELECT * FROM sys.fn_helpcollations();
Regole di confronto nel database SQL di Azure
Non è possibile modificare o impostare le regole di confronto del server logico in database SQL di Azure, ma è possibile configurare quelle di ogni database sia per i dati sia per il catalogo. Le regole di confronto del catalogo determinano le regole di confronto per i metadati di sistema, ad esempio gli identificatori di oggetto. Entrambe le regole di confronto possono essere specificate in modo indipendente quando si crea il database nel portale di Azure, in T-SQL con CREATE DATABASE, in PowerShell con New-AzSqlDatabase.
Regole di confronto in Istanza gestita di SQL di Azure
È possibile specificare regole di confronto a livello di server in Istanza gestita di database SQL di Azure durante la creazione dell'istanza, ma non è possibile cambiarle in seguito.
Per altre informazioni, vedere Impostare o modificare le regole di confronto del server.
Regole di confronto a livello di database
Quando si crea o si modifica un database, è possibile usare la clausola COLLATE dell'istruzione CREATE DATABASE o ALTER DATABASE per specificare le regole di confronto predefinite del database. Se non viene specificata alcuna regola di confronto, al database vengono assegnate le regole di confronto del server.
Non è possibile modificare le regole di confronto dei database di sistema a meno che non vengano modificate per il server.
- In SQL Server e Istanza gestita di SQL di Azure, le regole di confronto del database vengono usate per tutti i metadati nel database e rappresentano l'impostazione predefinita per tutte le colonne stringa, gli oggetti temporanei, i nomi di variabili e qualsiasi altra stringa usata nel database.
- Nel database SQL di Azure non sono presenti regole di confronto del server, pertanto ogni database ha regole di confronto per i dati e regole di confronto per il catalogo. CATALOG_COLLATION viene usato per tutti i metadati nel database e le regole di confronto rappresentano l'impostazione predefinita per tutte le colonne stringa, gli oggetti temporanei, i nomi di variabili e qualsiasi altra stringa usata nel database. CATALOG_COLLATION viene impostato al momento della creazione e non può essere modificato.
Quando le regole di confronto di un database utente vengono modificate, è possibile che si verifichino conflitti tra le regole di confronto quando vengono eseguite query nelle tabelle temporanee di accesso al database. Le tabelle temporanee sono sempre archiviate nel database di sistema tempdb, che usa le regole di confronto per l'istanza. L'esecuzione di query di confronto dei dati di tipo carattere tra database utente e tempdb potrebbe non riuscire se le regole di confronto causano un conflitto nella valutazione dei dati di tipo carattere. È possibile risolvere il problema specificando la clausola COLLATE nella query. Per altre informazioni, vedere COLLATE (Transact-SQL).
È possibile modificare le regole di confronto di un database utente usando un'istruzione ALTER DATABASE simile al seguente esempio di codice:
ALTER DATABASE myDB COLLATE Greek_CS_AI;
Importante
Le modifiche apportate alle regole di confronto a livello di database non influiscono sulle regole di confronto a livello di colonna o di espressione. Non influiscono sui dati nelle colonne esistenti.
È possibile recuperare le regole di confronto correnti di un database usando un'istruzione simile al seguente esempio di codice:
SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));
Regole di confronto a livello di colonna
Quando una tabella viene creata o modificata, è possibile specificare regole di confronto per ciascuna colonna di stringhe di caratteri usando la clausola COLLATE. Se non si specificano regole di confronto, alla colonna verranno assegnate le regole di confronto predefinite del database.
È possibile modificare le regole di confronto di una colonna usando un'istruzione ALTER TABLE simile al seguente esempio di codice:
ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI;
Regole di confronto a livello di espressione
Le regole di confronto a livello di espressione vengono impostate al momento dell'esecuzione di un'istruzione e interessano la modalità di restituzione di un set di risultati. In questo modo i risultati dell'ordinamento di ORDER BY possono essere specifici delle impostazioni locali. Per implementare regole di confronto a livello di espressione, usare una clausola COLLATE simile al seguente esempio di codice:
SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;
Impostazioni locali
Le impostazioni locali rappresentano un set di informazioni associate a un paese o a una lingua. Queste informazioni possono includere il nome e l'identificatore della lingua parlata, l'alfabeto usato per la scrittura della lingua e le convenzioni culturali. Le regole di confronto possono essere associate a uno o più set di impostazioni locali. Per altre informazioni, vedere ID delle impostazioni locali assegnati da Microsoft.
Tabella codici
Una tabella codici è un set ordinato di caratteri di uno script specifico nel quale a ogni carattere viene associato un indice numerico o un valore punto di codice. Per tabella codici di Windows si intende in genere un set di caratteri o charset. Queste tabelle vengono usate per supportare i set di caratteri e i layout di tastiera impiegati per le diverse impostazioni locali di Windows.
Ordinamento
L'ordinamento specifica il modo in cui vengono ordinati i valori dei dati. L'ordine influisce sui risultati del confronto dei dati stessi. I dati vengono ordinati tramite regole di confronto e possono essere ottimizzati tramite indici.
Supporto Unicode
Unicode è uno standard per il mapping dei punti di codice ai caratteri. Dato che è progettato per supportare tutti i caratteri di tutte le lingue del mondo, non sono necessarie tabelle codici diverse per gestire set di caratteri diversi.
Nozioni fondamentali su Unicode
L'archiviazione di dati in lingue diverse all'interno di un singolo database presenta difficoltà di gestione se si usano solo tabelle codici e dati di tipo carattere. È anche difficile trovare una singola tabella codici per il database che contenga tutti i caratteri necessari specifici della lingua. È inoltre difficile garantire che i caratteri speciali letti o aggiornati da una varietà di client che eseguono tabelle codici diverse vengano convertiti correttamente. È consigliabile che i database che supportano client internazionali usino sempre tipi di dati Unicode invece di tipi di dati non Unicode.
Si consideri, ad esempio, un database di clienti dell'America del Nord per cui è necessario gestire tre lingue principali:
- Nomi e indirizzi in spagnolo per il Messico
- Nomi e indirizzi in francese per il Quebec
- Nomi e indirizzi in inglese per il resto del Canada e gli Stati Uniti
Se si usano solo tabelle codici e colonne di tipo carattere, è necessario assicurarsi che il database sia installato con una tabella codici in grado di gestire i caratteri delle tre lingue. È anche necessario garantire che i caratteri di una qualsiasi delle lingue vengano convertiti correttamente quando sono letti dai client che eseguono una tabella codici di un'altra lingua.
Nota
Le tabelle codici usate da un client vengono determinate in base alle impostazioni del sistema operativo. Per impostare le tabelle codici del client nel sistema operativo Windows usare l'opzione Impostazioni internazionali del Pannello di controllo.
È difficile selezionare una tabella codici per i dati di tipo carattere in grado di supportare tutti i caratteri necessari per gli utenti di tutto il mondo. Il modo più semplice per gestire dati di tipo carattere in database internazionali consiste nell'usare sempre un tipo di dati che supporta Unicode.
Tipi di dati Unicode
Se vengono archiviati dati di tipo carattere che riflettono più lingue in SQL Server (SQL Server 2005 (9.x) e versioni successive), usare tipi di dati Unicode (nchar, nvarchar e ntext) anziché tipi di dati non Unicode (char, varchar e text).
Nota
Per i tipi di dati Unicode, il motore di database può rappresentare un massimo di 65.536 caratteri con UCS-2 o l'intera gamma Unicode (1.114.112 caratteri), se vengono usati caratteri supplementari. Per altre informazioni sull'abilitazione dei caratteri supplementari, vedere Caratteri supplementari.
In alternativa, a partire da SQL Server 2019 (15.x), se si usano regole di confronto abilitate per UTF-8 (_UTF8) i tipi di dati in precedenza non Unicode (char e varchar) diventano tipi di dati Unicode che usano la codifica UTF-8. SQL Server 2019 (15.x) non modifica il comportamento dei tipi di dati Unicode esistenti in precedenza (nchar, nvarchar e ntext), che continuano a usare la codifica UCS-2 o UTF-16. Per altre informazioni, vedere Differenze nell'archiviazione tra UTF-8 e UTF-16.
Considerazioni su Unicode
Ai tipi di dati non Unicode sono associate numerose limitazioni, perché nei computer non Unicode è disponibile una sola tabella codici. Usando Unicode è possibile ottenere prestazioni migliori, in quanto richiede un minor numero di conversioni tramite la tabella codici. Le regole di confronto Unicode devono essere selezionate singolarmente a livello di database, di colonna o di espressione perché non sono supportate a livello di server.
Quando si spostano dati da un server a un client, le regole di confronto del server potrebbero non essere riconosciute dai driver client meno recenti. Questa situazione può verificarsi quando si spostano dati da un server Unicode a un client non Unicode. La migliore opzione potrebbe consistere nell'aggiornare il sistema operativo client affinché vengano aggiornate le regole di confronto del sistema sottostanti. Se nel client è installato il software client del database, è possibile applicare un aggiornamento dei servizi a tale software.
Suggerimento
È anche possibile tentare di usare regole di confronto diverse per i dati nel server. Scegliere regole di confronto con mapping a una tabella codici nel client.
Per usare le regole di confronto UTF-16 disponibili in SQL Server (SQL Server 2012 (11.x) e versioni successive) e migliorare la ricerca e l'ordinamento di alcuni caratteri Unicode (solo regole di confronto Windows), è possibile selezionare una delle regole di confronto dei caratteri supplementari (_SC) o una delle regole di confronto versione 140.
Per usare le regole di confronto UTF-8 disponibili in SQL Server 2019 (15.x) e migliorare la ricerca e l'ordinamento di alcuni caratteri Unicode (solo regole di confronto Windows), è necessario selezionare le regole di confronto abilitate per la codifica UTF-8 (_UTF8).
Il flag UTF8 può essere applicato a:
- Regole di confronto linguistiche che supportano già caratteri supplementari (_SC) o riconoscono la distinzione tra selettori di variazione (_VSS)
- Regole di confronto binarie BIN2
Il flag UTF8 non può essere applicato a:
- Regole di confronto linguistiche che non supportano caratteri supplementari (_SC) o non riconoscono la distinzione tra selettori di variazione (_VSS)
- Le regole di confronto binarie BIN
- Le regole di confronto SQL_*
Per valutare i problemi relativi all'utilizzo di tipi di dati Unicode o non Unicode, è necessario eseguire il test dello scenario per verificare le differenze di prestazioni nell'ambiente specifico. È consigliabile standardizzare le regole di confronto usate nei sistemi presenti nell'ambito dell'organizzazione e distribuire server e client Unicode laddove possibile.
In molti casi SQL Server interagisce con altri server o client e l'organizzazione può usare più standard di accesso ai dati tra applicazioni e istanze del server. I client SQL Server sono principalmente di due tipi:
- Client Unicode che usano OLE DB e ODBC (Open Database Connectivity) versione 3.7 o successive.
- Client non Unicode che usano DB-Library e ODBC versione 3.6 o precedenti.
Nella tabella seguente sono riportate informazioni sull'uso di dati multilingue con diverse combinazioni di server Unicode e non Unicode:
| Server | Client | Vantaggi o limitazioni |
|---|---|---|
| Unicode | Unicode | Visto che i dati Unicode vengono usati in tutto il sistema, questo scenario offre prestazioni ottimali e la migliore protezione da eventuali danni ai dati recuperati. Si applica ad ADO (ActiveX Data Objects), OLE DB e ODBC versione 3.7 o successive. |
| Unicode | Non Unicode | In questo scenario, in particolare con le connessioni tra un server che esegue un sistema operativo più recente e un client in cui è in esecuzione una versione precedente di SQL Server o un sistema operativo meno recente, possono riscontrarsi limitazioni o errori quando si spostano i dati in un computer client. Per convertire i dati si tenta il mapping tra i dati Unicode presenti nel server e una tabella codici corrispondente nel client non Unicode. |
| Non Unicode | Unicode | Non si tratta di una configurazione ideale per l'uso di dati multilingue. Non è possibile scrivere dati Unicode nel server non Unicode e potrebbero verificarsi problemi all'invio dei dati ai server che non rientrano nella tabella codici del server. |
| Non Unicode | Non Unicode | Si tratta di uno scenario che presenta numerose limitazioni per i dati multilingue. È possibile usare solo una tabella codici. |
Caratteri supplementari
L'Unicode Consortium assegna a ogni carattere un punto di codice univoco, che corrisponde a un valore nell'intervallo 000000-10FFFF. I caratteri usati più di frequente hanno valori dei punti di codice nell'intervallo 000000-00FFFF (65.536 caratteri), compresi in una parola a 8 bit o a 16 bit in memoria e su disco. Questo intervallo viene in genere designato come Basic Multilingual Plane (BMP).
L'Unicode Consortium ha tuttavia stabilito 16 "piani" aggiuntivi di caratteri, ognuno con le stesse dimensioni di BMP. Questa definizione offre a Unicode la possibilità di rappresentare 1.114.112 caratteri (ovvero, 216 * 17 caratteri) nell'intervallo di punti di codice 000000-10FFFF. I caratteri con valore di punto di codice maggiore di 00FFFF richiedono da due a quattro parole a 8 bit consecutive (UTF-8) o due parole a 16 bit consecutive (UTF-16). Questi caratteri posizionati oltre BMP sono denominati caratteri supplementari e le parole a 8 bit o a 16 bit consecutive aggiuntive sono denominate coppie di surrogati. Per altre informazioni su caratteri supplementari, surrogati e coppie di surrogati, vedere lo standard Unicode.
SQL Server fornisce tipi di dati come nchar e nvarchar per archiviare i dati Unicode nell'intervallo BMP (000000-00FFFF), che viene codificato dal motore di database tramite UCS-2.
In SQL Server 2012 (11.x) è stata introdotta una nuova famiglia di regole di confronto per caratteri supplementari (_SC) che è possibile usare con i tipi di dati nchar, nvarchar e sql_variant per rappresentare l'intera gamma di caratteri Unicode (000000–10FFFF). Ad esempio: Latin1_General_100_CI_AS_SC o, se si usano regole di confronto per il giapponese, Japanese_Bushu_Kakusu_100_CI_AS_SC.
SQL Server 2019 (15.x) estende il supporto dei caratteri supplementari ai tipi di dati char e varchar con le nuove regole di confronto abilitate per UTF-8 (_UTF8). Questi tipi di dati sono inoltre in grado di rappresentare l'intera gamma di caratteri Unicode.
Nota
A partire da SQL Server 2017 (14.x), tutte le nuove regole di confronto supportano automaticamente i caratteri supplementari.
Se si utilizzano caratteri supplementari:
I caratteri supplementari possono essere usati in operazioni di ordinamento e confronto solo con le versioni delle regole di confronto 90 o successive.
Tutte le regole di confronto versione 100 supportano l'ordinamento linguistico con caratteri supplementari.
L'uso dei caratteri supplementari in metadati, ad esempio in nomi di oggetti di database, non è supportato.
Il flag SC può essere applicato a:
- Regole di confronto versione 90
- Regole di confronto versione 100
Il flag SC non può essere applicato a:
- Regole di confronto di Windows senza versione, versione 80
- Regole di confronto binarie BIN o BIN2
- Regole di confronto di SQL*
- Regole di confronto versione 140 (non devono necessariamente avere il flag SC perché supportano già i caratteri supplementari)
Nella tabella seguente viene confrontato il comportamento di alcune funzioni per i valori stringa e di alcuni operatori di stringa quando vengono usati caratteri supplementari con e senza regole di confronto che supportano caratteri complementari:
| Funzione di stringa o operatore | Con regole di confronto che supportano caratteri complementari | Senza regole di confronto che supportano caratteri complementari |
|---|---|---|
| CHARINDEX LEN PATINDEX |
La coppia di surrogati UTF-16 viene conteggiata come singolo punto di codice. | La coppia di surrogati UTF-16 viene conteggiata come due punti di codice. |
| LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF |
Queste funzioni considerano ogni coppia di surrogati un singolo punto di codice e funzionano come previsto. | Queste funzioni potrebbero dividere qualsiasi coppia di surrogati e provocare risultati imprevisti. |
| NCHAR | Restituisce il carattere corrispondente al valore del punto di codice Unicode specificato nell'intervallo 0-0x10FFFF. Se il valore specificato è incluso nell'intervallo 0-0xFFFF, viene restituito un carattere. Per valori superiori, viene restituito il surrogato corrispondente. | Un valore maggiore di 0xFFFF restituisce NULL anziché il surrogato corrispondente. |
| UNICODE | Restituisce un punto di codice UTF-16 nell'intervallo 0-0x10FFFF. | Restituisce un punto di codice UCS-2 nell'intervallo 0-0xFFFF. |
| Carattere jolly per corrispondenze di singoli caratteri Carattere jolly per la mancata corrispondenza dei caratteri |
Sono supportati caratteri supplementari per tutte le operazioni con caratteri jolly. | Non sono supportati caratteri supplementari per queste operazioni con caratteri jolly. Sono supportati altri operatori jolly. |
Supporto GB18030
GB18030 è uno standard separato usato nella Repubblica popolare cinese per la codifica dei caratteri cinesi. In GB18030, i caratteri possono essere di 1, 2 o 4 byte di lunghezza. SQL Server offre supporto per i caratteri con codifica GB18030 consentendone il riconoscimento al momento dell'ingresso nel server da un'applicazione client e la conversione e archiviazione come caratteri Unicode a livello nativo. Dopo essere stati archiviati nel server, questi caratteri vengono trattati come caratteri Unicode in tutte le operazioni successive.
È possibile usare una qualsiasi regola di confronto cinese, preferibilmente la versione 100 più recente. Tutte le regole di confronto di livello 100 supportano l'ordinamento linguistico con caratteri GB18030. Se nei dati sono inclusi caratteri supplementari (coppie di surrogati), è possibile usare le regole di confronto SC disponibili in SQL Server per migliorare la ricerca e l'ordinamento.
Nota
Assicurarsi che gli strumenti client, come SQL Server Management Studio, usino il tipo di carattere Dengxian per visualizzare correttamente le stringhe contenenti caratteri con codifica GB18030.
Supporto di lingue con alfabeti non latini
In SQL Server può essere supportata l'immissione, l'archiviazione, la modifica e la visualizzazione di lingue con alfabeti non latini. Le lingue con alfabeti non latini includono i siti seguenti:
- Lingue che presentano una combinazione di testo scritto sia da destra verso sinistra sia da sinistra verso destra, ad esempio una combinazione di testo in arabo e inglese.
- Lingue i cui caratteri assumono una forma diversa a seconda della posizione oppure combinati con altri caratteri, ad esempio arabi, indiani e thai.
- Lingue, come il thai, che richiedono dizionari interni per il riconoscimento delle parole in quanto non vi sono interruzioni tra loro.
Le applicazioni di database che interagiscono con SQL Server devono usare controlli che supportano le lingue con alfabeti non latini. I form standard di Windows creati in codice gestito sono abilitati per le lingue con alfabeti non latini.
Regole di confronto giapponesi aggiunte in SQL Server 2017 (14.x)
A partire da SQL Server 2017 (14.x), sono supportate nuove famiglie di regole di confronto per il giapponese, con permutazioni di varie opzioni (_CS, _AS, _KS, _WS e _VSS), nonché _BIN e _BIN2.
Per elencare queste regole di confronto, è possibile eseguire una query nel motore di database di SQL Server:
SELECT name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
Tutte le nuove regole di confronto supportano in modo predefinito i caratteri supplementari. Per nessuna nuova regola di confronto 140 esiste o è necessario il flag SC.
Queste regole di confronto sono supportate negli indici del motore di database, nelle tabelle ottimizzate per la memoria, negli indici columnstore e nei moduli compilati in modo nativo.
Supporto UTF-8
In SQL Server 2019 (15.x) viene introdotto il supporto completo per la codifica dei caratteri di grande diffusione UTF-8 come codifica di importazione o esportazione e come regola di confronto di livello database o colonna per i dati di tipo stringa. La codifica UTF-8 è consentita nei tipi di dati char e varchar ed è abilitata quando si crea o si modifica la regola di confronto di un oggetto convertendola in una regola di confronto che ha il suffisso UTF8. Un esempio è la modifica di LATIN1_GENERAL_100_CI_AS_SC in LATIN1_GENERAL_100_CI_AS_SC_UTF8.
UTF-8 è disponibile solo per le regole di confronto di Windows che supportano i caratteri supplementari. Questa funzionalità è stata introdotta in SQL Server 2012 (11.x). I tipi di dati nchar e nvarchar consentono solo la codifica UCS-2 o UTF-16 e rimangono invariati.
Database SQL di Azure e Istanza gestita di SQL di Azure supportano la codifica UTF-8 a livello di database e di colonna, mentre Istanza gestita di SQL supporta questa funzionalità anche a livello di server.
Differenze nell'archiviazione tra UTF-8 e UTF-16
L'Unicode Consortium assegna a ogni carattere un punto di codice univoco, che corrisponde a un valore nell'intervallo 000000-10FFFF. Con SQL Server 2019 (15.x), sono disponibili entrambe le codifiche UTF-8 e UTF-16 per rappresentare l'intera gamma:
- Con la codifica UTF-8, i caratteri nell'intervallo ASCII (000000-00007F) richiedono 1 byte, i punti di codice nell'intervallo 000080-0007FF richiedono 2 byte, i punti di codice nell'intervallo 000800-00FFFF richiedono 3 byte e i punti di codice nell'intervallo 0010000-0010FFFF richiedono 4 byte.
- Con la codifica UTF-16, i punti di codice nell'intervallo 000000-00FFFF richiedono 2 byte e i punti di codice nell'intervallo 0010000-0010FFFF richiedono 4 byte.
Nella tabella seguente sono elencati i byte per l'archiviazione della codifica per ogni intervallo di caratteri e tipo di codifica:
| Intervallo di codici (esadecimale) | Intervallo di codici (decimale) | Byte per l'archiviazione 1 con UTF-8 | Byte per l'archiviazione 1 con UTF-16 |
|---|---|---|---|
| 000000–00007F | 0–127 | 1 | 2 |
| 000080–00009F 0000A0–0003FF 000400–0007FF |
128–159 160–1.023 1.024–2.047 |
2 | 2 |
| 000800–003FFF 004000–00FFFF |
2.048–16.383 16.384–65.535 |
3 | 2 |
| 010000–03FFFF2 040000–10FFFF2 |
65,536–262,1432 262.144–1.114.1112 |
4 | 4 |
1 I byte per l'archiviazione si riferiscono alla lunghezza in byte con codifica, non alle dimensioni di archiviazione su disco del tipo di dati. Per altre informazioni sulle dimensioni di archiviazione su disco, vedere nchar e nvarchar e char e varchar.
2 Intervallo di punti di codice per caratteri supplementari.
Suggerimento
Si pensa comunemente che in CHAR(n) e VARCHAR(n) o in NCHAR(n) e NVARCHAR(n) l'elemento n definisca il numero di caratteri. Questo è dovuto al fatto che nell'esempio di una colonna CHAR(10) è possibile archiviare 10 caratteri ASCII nell'intervallo 0-127 usando regole di confronto come Latin1_General_100_CI_AI, perché ogni carattere in questo intervallo usa solo 1 byte.
Tuttavia, in CHAR(n) e VARCHAR(n) l'elemento n definisce le dimensioni della stringa in byte (0-8.000), mentre in NCHAR(n) e NVARCHAR(n) l'elemento n definisce le dimensioni della stringa in coppie di byte (0-4.000). n non definisce mai il numero di caratteri che è possibile archiviare,
Come visto in precedenza, a seconda del set di caratteri in uso, la scelta della codifica Unicode e del tipo di dati appropriati potrebbe offrire importanti risparmi di risorse di archiviazione o al contrario incrementare il footprint della memoria. Ad esempio se si usa una regola di confronto in caratteri latini con supporto UTF-8, come Latin1_General_100_CI_AI_SC_UTF8, una colonna CHAR(10) archivia 10 byte e può contenere 10 caratteri ASCII nell'intervallo 0-127. Ma può contenere solo cinque caratteri nell'intervallo 128-2047 e solo tre caratteri nell'intervallo 2048-65535. Tuttavia, dato che una colonna NCHAR(10) archivia 10 coppie di byte (20 byte), può ospitare 10 caratteri nell'intervallo 0-65535.
Prima di scegliere se usare la codifica UTF-8 o UTF-16 per un database o una colonna, considerare la distribuzione dei dati di tipo stringa che verranno archiviati:
- Se sono principalmente nell'intervallo ASCII 0-127 (ad esempio, per la lingua inglese), ogni carattere richiede 1 byte con UTF-8 e 2 byte con UTF-16. L'uso di UTF-8 offre vantaggi in termini di archiviazione. Se si cambia il tipo di dati di una colonna esistente con caratteri ASCII nell'intervallo 0-127 da
NCHAR(10)aCHAR(10)usando una regola di confronto con supporto UTF-8, i requisiti di archiviazione vengono ridotti del 50%. Questa riduzione deriva dal fatto cheNCHAR(10)richiede 20 byte per l'archiviazione, in confronto aCHAR(10)che richiede solo 10 byte per la rappresentazione della stessa stringa Unicode. - Oltre l'intervallo ASCII, quasi tutti gli script basati sull'alfabeto latino, greco, cirillico, copto, armeno, ebraico, arabo, siriaco, tāna e N'Ko richiedono 2 byte per carattere sia in UTF-8 che in UTF-16. In questi casi non vi sono differenze significative a livello di archiviazione per i tipi di dati simili (ad esempio, tra l'uso di char o nchar).
- Se si tratta principalmente di alfabeti dell'Asia orientale (ad esempio, coreano, cinese e giapponese), ogni carattere richiede 3 byte con UTF-8 e 2 byte con UTF-16. L'uso di UTF-16 offre vantaggi in termini di archiviazione.
- I caratteri nell'intervallo 010000-10FFFF richiedono 4 byte sia in UTF-8 che in UTF-16. In questi casi non vi sono differenze di archiviazione per i tipi di dati simili (ad esempio, tra l'uso di char o nchar).
Per altre considerazioni, vedere Scrittura di istruzioni Transact-SQL internazionali.
Conversione a UTF-8
Dato che in CHAR (n) e VARCHAR (n) o in NCHAR (n) e NVARCHAR (n) il segnaposto n definisce le dimensioni di archiviazione in byte e non il numero di caratteri che è possibile archiviare, è importante determinare le dimensioni del tipo di dati in cui è necessario eseguire la conversione, per evitare il troncamento dei dati.
Si consideri ad esempio una colonna definita come NVARCHAR(100) che archivia 180 byte di caratteri giapponesi. In questo esempio i dati della colonna sono attualmente codificati con UCS-2 o UTF-16, che usa 2 byte per carattere. La conversione del tipo di colonna in VARCHAR(200) non è sufficiente per impedire il troncamento dei dati, perché il nuovo tipo di dati può archiviare solo 200 byte, ma i caratteri giapponesi richiedono 3 byte quando sono codificati in UTF-8. Pertanto la colonna deve essere definita come VARCHAR(270) per evitare la perdita di dati a causa del troncamento.
Di conseguenza è necessario conoscere in anticipo le dimensioni in byte previste per la definizione della colonna, prima di convertire i dati esistenti in UTF-8 e modificare di conseguenza le nuove dimensioni del tipo di dati. Vedere lo script Transact-SQL o il notebook SQL in Data Samples GitHub, che usa la funzione DATALENGTH e l'istruzione COLLATE per determinare i requisiti di lunghezza dati corretti per le operazioni di conversione UTF-8 in un database esistente.
Per modificare le regole di confronto e il tipo di dati delle colonne in una tabella esistente, usare uno dei metodi descritti in Impostare o modificare le regole di confronto delle colonne.
Per modificare le regole di confronto del database consentendo a nuovi oggetti di ereditarle per impostazione predefinita o per modificare le regole di confronto del server consentendo ai nuovi database di ereditare le regole di confronto di sistema per impostazione predefinita, vedere la sezione Attività correlate di questo articolo.
Attività correlate
| Attività | Articolo |
|---|---|
| Viene descritto come impostare o modificare le regole di confronto dell'istanza di SQL Server. La modifica delle regole di confronto del server non comporta la modifica delle regole di confronto dei database esistenti. | Impostazione o modifica di regole di confronto del server |
| Viene descritto come impostare o modificare le regole di confronto di un database utente. La modifica delle regole di confronto di un database non comporta la modifica delle regole di confronto delle colonne di tabella esistenti. | Impostare o modificare le regole di confronto del database |
| Viene descritto come impostare o modificare le regole di confronto di una colonna nel database | Impostare o modificare le regole di confronto delle colonne |
| Viene descritto come restituire informazioni sulle regole di confronto a livello di server, di database o di colonna | Visualizzazione di informazioni sulle regole di confronto |
| Viene descritto come scrivere istruzioni Transact-SQL più portabili da un linguaggio a un altro o in grado di supportare più linguaggi con maggiore facilità | Scrittura di istruzioni Transact-SQL internazionali |
| Viene descritto come modificare la lingua dei messaggi di errore e le preferenze di utilizzo e visualizzazione dei dati di tipo data, ora e valuta. | Impostazione di una lingua di sessione |
Contenuto correlato
Per altre informazioni, vedere i seguenti contenuti correlati:
- SQL Server Best Practices Collation Change (Procedure consigliate di SQL Server: modifica delle regole di confronto)
- Usare il formato carattere Unicode per importare o esportare dati (SQL Server)
- Scrittura di istruzioni Transact-SQL internazionali
- Procedure consigliate di SQL Server: migrazione a Unicode (non più aggiornato)
- Unicode Consortium
- Standard Unicode
- Supporto UTF-8 in OLE DB Driver per SQL Server
- Nome delle regole di confronto di SQL Server (Transact-SQL)
- Windows_collation_name (Transact-SQL)
- Introduzione al supporto di UTF-8 per SQL Server
- COLLATE (Transact-SQL)
- Precedenza delle regole di confronto