Programmazione sul lato server con Unicode
Data aggiornamento: 17 luglio 2006
Affinché un database supporti il formato Unicode, è necessario definire interazioni client che supportano Unicode, nonché utilizzare i tipi di dati nchar, nvarchar e nvarchar(max) per definire l'archiviazione Unicode. Per definire interazioni client che supportano Unicode, eseguire le operazioni seguenti sul lato server del database:
- Sostituire i tipi di dati non Unicode con tipi di dati Unicode nelle colonne delle tabelle e nelle operazioni CONVERT() e CAST().
- Sostituire le funzioni ASCII() e CHAR() con le funzioni Unicode equivalenti UNICODE() e NCHAR().
- Definire variabili e parametri di stored procedure e trigger in Unicode.
- Anteporre alle costanti stringa di caratteri Unicode la lettera N.
Utilizzo di UNICODE(), NCHAR() e altre funzioni
Poiché la funzione ASCII() restituisce il codice carattere non Unicode del carattere passato, è necessario utilizzare la funzione equivalente UNICODE() per le stringhe Unicode, così come si utilizzerebbe la funzione ASCII per le stringhe non Unicode. Lo stesso vale per la funzione CHAR; l'equivalente Unicode è NCHAR.
Poiché la funzione SOUNDEX() è definita sulla base delle regole fonetiche inglesi, non è significativa nelle stringhe Unicode, a meno che la stringa non contenga solo i caratteri dell'alfabeto latino dalla A alla Z e dalla a alla z.
Le funzioni ASCII, CHAR e SOUNDEX possono essere passate come parametri Unicode, ma tali argomenti vengono implicitamente convertiti in stringhe non Unicode. Ciò potrebbe causare la perdita di caratteri Unicode prima dell'elaborazione, perché per definizione tali funzioni vengono applicate a stringhe non Unicode.
Oltre alle funzioni UNICODE() e NCHAR(), le funzioni di modifica delle stringhe seguenti supportano Unicode, se possibile: CHARINDEX(), LEFT(), LEN(), UPPER(), LOWER(), LTRIM(), RTRIM(), PATINDEX(), REPLACE(), QUOTENAME(), REPLICATE(), REVERSE(), STUFF(), SUBSTRING() e UNICODE(). Queste funzioni accettano argomenti Unicode, rispettano il limite di 2 byte per carattere delle stringhe Unicode e utilizzano le regole di ordinamento Unicode per il confronto delle stringhe quando i parametri di input sono Unicode.
Definizione dei parametri nelle stored procedure
La definizione dei parametri con un tipo di dati Unicode garantisce che l'input o le richieste client vengano implicitamente convertite in Unicode sul server e non vengano danneggiate durante il processo. Se il parametro è specificato come parametro di output, un tipo di dati Unicode contribuisce inoltre a ridurre il rischio di danneggiamento durante il reinvio al client.
Nella stored procedure seguente la variabile viene dichiarata come tipo di dati Unicode.
CREATE PROCEDURE Product_Info
@name nvarchar(40)
AS
SELECT p.ListPrice, v.Name
FROM Production.Product p
INNER JOIN Purchasing.ProductVendor pv
ON p.ProductID = pv.ProductID
INNER JOIN Purchasing.Vendor v
ON pv.VendorID = v.VendorID
WHERE p.Name = @name;
Utilizzo del prefisso N
Le costanti stringa Unicode incluse nel codice eseguito sul server, ad esempio in stored procedure e trigger, devono essere precedute dalla lettera maiuscola N. Ciò è necessario anche se la colonna a cui viene fatto riferimento è già definita come Unicode. Senza il prefisso N, la stringa viene convertita nella tabella codici predefinita del database ed è possibile che alcuni caratteri non vengano riconosciuti.
La stored procedure creata nell'esempio precedente può ad esempio essere eseguita sul server nel modo seguente:
EXECUTE Product_Info @name = N'Chain'
La necessità di utilizzare il prefisso N vale sia per le costanti stringa provenienti dal server sia per quelle inviate dal client.
Vedere anche
Concetti
Programmazione sul lato client con Unicode
Guida in linea e informazioni
Cronologia modifiche
| Versione | Cronologia |
|---|---|
17 luglio 2006 |
|