Fascicolazione / set di caratteri UTF-8 di SQL Server 2005/2008

16

Non riesco a trovare le opzioni direttamente da impostare in modo UTF-8correlato Collations/Charsetsin SQL Server 2005/2008, come è possibile impostare in un altro motore SQL, ma in SQL Server 2005/2008 ci sono solo regole di confronto latino e SQL.

C'è qualche opzione per forzare / installare queste regole di confronto / set di caratteri nel motore di SQL Server (per entrambe le versioni) 2005/2008 sul sistema operativo Win2008

— mKorbel
fonte

13

No, non c'è. SQL Server non supporta UTF-8.

Devi definire le tue colonne come nvarchar / nchar se vuoi dati unicode. Nota, SQL Server internamente lo memorizza come UCS-2.

Si noti che ciò è stato richiesto da MS su Connect e che esiste un articolo KB precedente . E alcune informazioni anche su questo blog

— GBN
fonte

6

inoltre, se stai eseguendo una corrispondenza di testo su un nvarchar con caratteri stranieri, devi abbinare una stringa formattata con una N prima della stringa (ad esempio N'ο Nκονόμον ').

— sweckeck

Questo comportamento è cambiato in una recente versione di SQL Server?

— Seiyria,

@Seiyria: no, stesso comportamento

— gbn

Chiunque trovi la strada per questa risposta, vai alla pagina MS Connect e vota per favore che MS supporta UTF-8 su SQL Server. Grazie: D

— Darcy Thomas

@DarcyThomas Questo sta diventando realtà in SQL Server 2019, anche se non è ancora qualcosa che si dovrebbe usare a meno che non ne abbiano un esplicito bisogno. Si prega di consultare la mia risposta per i dettagli.

— Solomon Rutzky

2

Non è possibile installare UTF-8 come set di caratteri perché non è un set di caratteri, è una codifica.

Se si desidera memorizzare il testo Unicode, utilizzare il nvarchartipo di dati.

Se si desidera memorizzare il testo codificato utilizzando UTF-8, lo si memorizza come dati binari ( varbinary).

— Guffa
fonte

1

A partire da SQL Server 2019 (attualmente in versione beta / "Community Tech Preview"), esiste un supporto nativo per UTF-8 tramite una nuova serie di regole di confronto UTF-8. TUTTAVIA, avere la possibilità di usare UTF-8 non significa che dovresti. Ci sono alcuni svantaggi nell'uso di UTF-8, come ad esempio:

Solo i primi 128 punti di codice sono 1 byte (ovvero il set ASCII standard a 7 bit)
I successivi quasi 2000 punti di codice sono 2 byte, quindi nessun risparmio di spazio su UTF-16 / NVARCHAR
I rimanenti 63k punti di codice nel BMP (ovvero l'intervallo U + 0800 - U + FFFF) sono tutti e 3 byte, quindi 1 byte più grande dello stesso carattere in UTF-16 / NVARCHAR.
Basta affermarlo: i caratteri supplementari sono 4 byte in entrambe le codifiche, quindi nessuna differenza di spazio lì
Mentre potresti risparmiare spazio usando UTF-8, ci sono ottime possibilità che tu possa fare un colpo sulle prestazioni per farlo.

Ciò che si riduce davvero a questo è: UTF-8 è un progetto di formato di archiviazione che consente ai sistemi a 8 bit (che erano in genere progettati attorno a ASCII e ASCII Extended - Code Pages) di utilizzare Unicode senza interrompere nulla o richiedere alcuna modifica di esistenti file per mantenere le cose in esecuzione. UTF-8 è meraviglioso per i file system e la rete, ma i dati archiviati in SQL Server non lo sono. Il fatto che i dati che si trovano per lo più (o interamente) all'interno dell'intervallo ASCII standard richiede meno spazio rispetto agli stessi dati se archiviati come UTF-16 / NVARCHARè un effetto collaterale. Certo, è un effetto collaterale che può rivelarsi utile, ma quella decisione deve essere presa da qualcuno che comprenda sia i dati sia le conseguenze / gli svantaggi di questa decisione. Questo ènon una funzionalità per uso generale.

Inoltre, il caso d'uso principale per UTF-8 (in SQL Server) è per il codice dell'app che già utilizza UTF-8, possibilmente già con un altro RDBMS che lo supporta, e non c'è desiderio o capacità di aggiornare il codice dell'app / schema DB per utilizzare NVARCHARtipi di dati (per tabelle, variabili, parametri, ecc.) o per aggiungere il valore letterale stringa con una "N" maiuscola. L'obiettivo è lo stesso del motivo per UTF-8 esistente: abilitare il codice dell'app per utilizzare Unicode senza modificare la struttura generale o rendere i dati esistenti non validi. Se questo descrive la tua situazione, usa UTF-8, ma tieni presente che ci sono ancora alcuni bug / problemi.

Se non hai un'esigenza esplicita di far funzionare Unicode senza usare NVARCHARletterali di stringa con prefisso "N" maiuscoli, l'unico altro scenario in cui UTF-8 è un vantaggio è se hai MOLTO di dati ASCII principalmente standard che devono consentire Caratteri Unicode e tu stai usando NVARCHAR(MAX)(il che significa che la compressione dei dati non funzionerà) e la tabella viene aggiornata frequentemente (quindi l'indice Columnstore Clustered probabilmente non sarà veramente d'aiuto).

Per i dettagli completi, vedere il mio post:

Supporto nativo UTF-8 in SQL Server 2019: Salvatore o Falso profeta?

— Solomon Rutzky
fonte

0

Nel mio caso, ho dovuto mostrare caratteri arabi e il mio database di sviluppo era nel 2014, qui le cose hanno funzionato bene. Qui, nelle query ho potuto vedere i caratteri arabi e la mia collation era SQL_Latin1_General_CP1256_CI_AS

Ma la mia produzione era in SQL Server 2008 e alla fine non supportava il set di caratteri UTF-8. Qui, ho potuto vedere tutto ??????????? poiché UTF-8 non è supportato in SQL 2008.

Tutto quello che ho fatto è stato modificare tutto varchar in nvarchar e ho potuto vedere correttamente il carattere arabo. Inoltre cambio il confronto del mio database 2008 in SQL_Latin1_General_CP1256_CI_AS

— Halim
fonte