Evitare la modifica del codice con Microsoft SQL Server e Unicode

Question

Come si fa in modo che il server MSSQL accetti i dati Unicode per impostazione predefinita in una colonna VARCHAR o NVARCHAR?

So che puoi farlo posizionando una N davanti alla stringa da inserire nel campo ma a onestamente questo sembra un po 'arcaico nel 2008 e in particolare con l'utilizzo di SQL Server 2005.

Answer 1

La sintassi N è il modo in cui si specifica una stringa unicode letterale in SQL Server.

N'Unicode string'
'ANSI string'

Quando possibile, SQL Server eseguirà automaticamente la conversione tra i due, utilizzando le regole di confronto di una colonna o le regole di confronto del database.

Quindi, se i letterali delle stringhe in realtà non contengono caratteri unicode, non è necessario specificare il prefisso N .

Ma se i letterali delle stringhe contengono contengono caratteri unicode, è necessario utilizzare il prefisso N .

Answer 2

Se si tratta di un'applicazione Web, è possibile che il server Web utilizzi UTF8 come codifica predefinita. In questo modo tutti i dati avanti e indietro nel browser sarebbero UTF8 che possono essere inseriti nei campi VARCHAR. UTF8 è un buon modo per far sì che le applicazioni che non sono a conoscenza di Unicode possano gestirlo.

Answer 3

Hanno davvero bisogno di un modo per disattivare la necessità del prefisso N ''. & Quot; è necessario per la retrocompatibilità " l'argomento non ha alcun senso per me - certo, rendi quel comportamento predefinito per le vecchie app, ma fornisci un'opzione per me per attivare le stringhe Unicode per impostazione predefinita (cioè, non è richiesto il prefisso N ''). Sto scoprendo che devo andare e pasticciare con ampie aree della mia app per adattarsi a Unicode su SQL Server quando questo NON è un problema in Oracle e Postgresql. Dai, Microsoft!

Answer 4

Sebbene sia possibile archiviare semplicemente il contenuto UTF8 in un campo VARCHAR nel server MSSQL fino a quando non viene eseguita la traduzione dei set di caratteri, è necessario tenere presente che:

1. Nessuno strumento di gestione / reportistica / dati al di fuori della tua applicazione sarà in grado di comprendere i tuoi caratteri non inglesi.

2. La gestione specifica della lingua come l'ordinamento di un elenco di nomi potrebbe non essere eseguita nell'ordine accettabile per ogni lingua.

3. Deve fare attenzione al troncamento dei dati. Troncare di solito un carattere UTF8 multi-byte provoca normalmente il danneggiamento dei dati per il personaggio coinvolto. Dovresti sempre rifiutare l'input se supera la lunghezza del campo.

4. Potrebbe non essere facile come pensi di disabilitare la traduzione dei set di caratteri. Anche se la spegni nel driver del client, in alcuni casi può comunque essere sostituita se c'è una differenza locale significativa tra client e RDBMS codepage utilizzato che porta immediatamente alla corruzione dei dati.

5. Se pensi che questo sia tutto, dovrai preoccuparti del tuo inganno.

In sintesi, mentre potresti essere tentato di seguire questa strada, non è una buona idea. È necessario modificare il codice quando si passa a più byte.