it-swarm.it

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

Non riesco a trovare le opzioni direttamente per impostare UTF-8 rellated Collations/Charsets in SQL Server 2005/2008, lo stesso che è 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

16
mKorbel

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

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

Si noti che questo ha richiesto da MS su Connect e c'è un vecchio articolo KB . E alcune informazioni anche su questo blog

13
gbn

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 tipo di dati nvarchar.

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

2
Guffa

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 significa no significa che dovresti. Ci sono alcuni svantaggi nell'uso di UTF-8, come ad esempio:

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

Ciò a cui si riduce davvero è questo: UTF-8 è un progetto di formato di archiviazione per abilitare i sistemi a 8 bit (che erano tipicamente progettati intorno a ASCII e ASCII Esteso - Pagine di codici) per utilizzare Unicode senza interrompere nulla o richiedere alcuna modifica dei file esistenti al fine di mantenere le cose in esecuzione. UTF-8 è meraviglioso per i file system e la rete, ma i dati memorizzati dentro Nessuno dei due è SQL Server. Il fatto che i dati risultino solo principalmente (o interamente) all'interno dello standard ASCII richiede meno spazio degli stessi dati quando memorizzato come UTF-16/NVARCHAR è un effetto collaterale. Certo, è un effetto collaterale che può rivelarsi utile, ma quella decisione deve essere presa da qualcuno che capisca entrambi i dati e le conseguenze/gli svantaggi di questa decisione. Questa è no una funzione 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 NVARCHAR tipi di dati (per tabelle, variabili, parametri, ecc.) o per aggiungere il prefisso letterale a 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 non validi i dati esistenti. 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 che Unicode funzioni senza usare NVARCHAR o maiuscole con lettere "N" con prefisso, allora l'unico altro scenario in cui UTF-8 è un vantaggio è se hai MOLTO principalmente standard ASCII dati che devono consentire i caratteri Unicode e stai usando NVARCHAR(MAX) (il che significa che la compressione dei dati non funzionerà), e la tabella viene aggiornata frequentemente (quindi l'indice Columnstore in cluster probabilmente non sarà di grande aiuto).

Per i dettagli completi, vedere il mio post:

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

1
Solomon Rutzky

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

0
Halim