Perché è necessario inserire N prima delle stringhe in Microsoft SQL Server?

NVarchar è usato per Unicode. Se il tuo database non memorizza dati multilingue puoi continuare a utilizzare Varchar. Ad esempio: N'abc' converte semplicemente la tua stringa in unicode.

Per impostazione predefinita, SQL server utilizza i Windows-1252 codici per msdn.microsoft.com/en-us/library/ms176089%28v=sql.105%29.aspx">varchar. Contiene la maggior parte dei caratteri per le lingue basate sul latino (inglese, tedesco, francese, ecc.), Ma non contiene caratteri per le lingue non basate su latino (polacco, russo, ecc.). Come dichiarato da @Pieter B, nvarchar viene utilizzato per risolvere questo problema perché è per Unicode che contiene quei caratteri mancanti. Questo ha un costo, ci vuole il doppio dello spazio per memorizzare nvarchar di varchar.

L'inserimento di N davanti alla stringa garantisce che i caratteri vengano convertiti in Unicode prima di essere inseriti in una colonna nvarchar. La maggior parte delle volte starai bene con N, ma non lo consiglierei. È molto meglio prevenire che curare.

Perché MS SQL Server ha scarso supporto per UTF-8 rispetto ad altri RDBMS.

MS SQL Server segue la convenzione, utilizzata all'interno di Windows stesso, che le stringhe "strette" ( char in C ++, CHAR o VARCHAR in SQL) sono encoded in una" code page "legacy. Il problema con le code page è che hanno un numero limitato di caratteri (la maggior parte sono codifiche a byte singolo, che limita il repertorio a 256 caratteri) e sono progettati attorno a una singola lingua (o gruppo di lingue con alfabeti simili). Ciò rende difficile l'archiviazione di dati multilingue. Ad esempio, non puoi memorizzare sia i dati russi che quelli ebraici perché il russo utilizza la codepage 1251 e l'ebraico utilizza la tabella codici 1255 .

Unicode risolve questo problema utilizzando un singolo set di caratteri codificati giganti con spazio per più di un milione di caratteri, sufficiente per rappresenta ogni lingua del mondo. Esistono diversi schemi di codifica Unicode; Microsoft preferisce utilizzare UTF-16 , per ragioni storiche . Poiché UTF-16 rappresenta le stringhe come una sequenza di unità di codice a 16 bit invece del tradizionale 8 bit, è necessario un tipo di carattere separato. In MSVC ++, questo è wchar_t . E in MS SQL, è NCHAR o NVARCHAR . N è l'acronimo di "national" , che mi sembra al contrario perché Unicode riguarda < em> inter -nazionalizzazione, ma questa è la terminologia ISO.

Altre implementazioni SQL ti consentono di memorizzare il testo UTF-8 in una colonna VARCHAR . UTF-8 è una codifica a lunghezza variabile (1-4 byte per carattere) ottimizzata per il caso in cui i dati sono prevalentemente nell'intervallo Latino di base (che sono rappresentati come lo stesso 1 byte per carattere come ASCII), ma può rappresentare qualsiasi carattere Unicode. Così eviterai il problema "doppio di spazio" menzionato da bwalk2895.

Purtroppo, MS SQL Server non supporta UTF-8% diVARCHAR , quindi devi utilizzare UTF -16 invece (e spreca spazio per il testo ASCII), usa una codepage non Unicode (e perdi la capacità di rappresentare caratteri stranieri), o memorizza UTF-8 in una colonna BINARY (e risolvi problemi come SQL funzioni stringa non funzionano correttamente o devono visualizzare i dati come dump esadecimale nel gestore DB della GUI) .