Gestione della conversione dei dati tra un server Unicode e un client non Unicode
In questo argomento viene descritto come salvaguardare l'integrità dei dati di tipo carattere quando il formato di archiviazione dei dati sul lato server è Unicode, ma l'applicazione sul lato che interagisce con i dati utilizza una tabella codici specifica.
Input dei dati
Quando il client invia dati non Unicode da archiviare sul server in formato Unicode, i dati inviati da qualsiasi client con qualsiasi tabella codici verranno archiviati correttamente in presenza di una delle condizioni seguenti:
Le stringhe di caratteri vengono inviate al server come parametri di una chiamata di procedura remota (Remote Procedure Call, RPC).
Le costanti stringa sono precedute dalla lettera maiuscola N. Tale requisito è necessario anche se l'applicazione sul lato client riconosce il formato Unicode. In assenza del prefisso N, SQL Server convertirà la stringa nella tabella codici corrispondente alle regole di confronto predefinite del database. Tutti i caratteri non trovati nella tabella codici andranno persi.
Recupero dei dati
Se l'applicazione client non supporta il formato Unicode e recupera i dati in buffer non Unicode, un client potrà solo recuperare o modificare i dati rappresentabili dalla tabella codici del computer client. In questo modo i caratteri ASCII verranno sempre recuperati, in quanto la rappresentazione di tali caratteri è identica in tutte le tabelle codici, mentre il recupero dei dati non ASCII dipenderà dalla conversione tra tabelle codici.
Si supponga, ad esempio, di disporre di un'applicazione eseguita attualmente solo negli Stati Uniti, ma distribuita in Giappone. Poiché il database SQL Server riconosce il formato Unicode, è possibile archiviare nelle stesse tabelle sia il testo in inglese che quello in giapponese, anche se l'applicazione non è stata ancora modificata in modo da gestire il testo in formato Unicode. Fino a quando l'applicazione è conforme a una delle due opzioni descritte in precedenza, gli utenti giapponesi potranno utilizzare l'applicazione non Unicode per immettere e recuperare dati in giapponese, mentre quelli statunitensi potranno immettere e recuperare dati in inglese. Tutti i dati di entrambi i set di utenti verranno archiviati senza alterazioni nella stessa colonna del database e rappresentati in formato Unicode. In questa situazione è possibile distribuire un'applicazione che supporta il formato Unicode e genera report riferiti al set di dati completo. Gli utenti statunitensi non potranno tuttavia visualizzare le righe in giapponese, perché l'applicazione non è in grado di visualizzare caratteri non esistenti nella relativa tabella codici, ovvero la 1252.
Questa situazione potrebbe risultare comunque accettabile se i due gruppi di utenti non devono visualizzare i record reciproci. Se invece un utente deve poter visualizzare o modificare record contenenti testo non rappresentabile con un'unica tabella codici, l'unica alternativa consiste nel modificare l'applicazione in modo da includere il supporto per il formato Unicode.
Applicazioni basate sul Web
Se il programma sul lato client è basato sul Web e si connette a una pagina Active Server Pages (ASP), sono disponibili specifiche dei metadati sia nella pagina HTML sul lato client che nella pagina ASP sul lato server. Tali specifiche sono necessarie per indicare il numero di stringhe di caratteri da convertire tra il server, il motore ASP e il browser client.
Nella pagina HTML sul lato client l'attributo META deve specificare che è necessario utilizzare un codice CHARSET per convertire i dati del set di caratteri nello schema di codifica del client. Nella pagina HTML seguente, ad esempio, specificando big5 come codice CHARSET si indica al client di convertire i dati di tipo carattere nella tabella codici 950 (cinese tradizionale).
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=big5">
<!--
-->
</HEAD>
<BODY>
<!--
body
-->
</BODY>
</HTML>
Nella pagina ASP sul lato server è necessario indicare all'applicazione Web ASP la tabella codici utilizzata dal browser client. In tal caso è possibile specificare la proprietà Session.CodePage o la direttiva @CodePage. Questi metodi consentiranno di gestire la conversione dei dati dal server al client, nonché entrambe le richieste GET e POST del client. Negli esempi seguenti vengono utilizzati entrambi i metodi per specificare la conversione nella e dalla tabella codici del client, ovvero 950 (cinese tradizionale).
<%@ Language=VBScript codepage=950 %>
<% Session.CodePage=950 %>
Non dimenticare, infine, di aggiungere la lettera N come prefisso di tutti valori letterali stringa.