Gestion de la conversion de données entre un serveur Unicode et un client non-Unicode
Cette rubrique décrit comment préserver l'intégrité des données de type caractère lorsque le stockage de données côté serveur est de type Unicode, alors que l'application côté client qui interagit avec ces données utilise une page de codes spécifique.
Saisie de données
Lorsque des données non-Unicode sont envoyées du client vers le serveur au format Unicode pour y être stockées, elles seront stockées correctement, quel que soit le client et quelle que soit la page de codes qu'il utilise, si au moins une des conditions suivantes est vérifiée :
Les chaînes de caractères sont envoyées au serveur sous la forme de paramètres d'un appel de procédure distante (RPC).
Les constantes de chaînes sont précédées par la lettre N majuscule. Ceci est obligatoire, que l'application côté client soit ou non compatible avec Unicode. Sans ce préfixe N, SQL Server convertit la chaîne selon la page de codes correspondant au classement par défaut de la base de données. Tous les caractères absents de cette page de codes sont alors perdus.
Récupération de données
Si l'application cliente ne prend pas en charge Unicode et récupère les données dans des tampons non-Unicode, elle ne pourra récupérer ou modifier que les données pouvant être représentées par la page de codes de l'ordinateur client. En d'autres termes, les caractères ASCII seront toujours récupérés, car leur représentation est la même dans toutes les pages de codes, mais pour les données non-ASCII, tout dépend de la conversion de la page de codes de départ à celle de destination.
Par exemple, imaginons une application exécutée seulement aux États-Unis, mais déployée au Japon. Dans la mesure où la base de données SQL Server est compatible avec Unicode, du texte anglais et japonais peut être stocké dans les mêmes tables, bien que l'application n'ait pas encore été modifiée pour le gérer en tant que texte Unicode. Les utilisateurs japonais peuvent utiliser l'application non-Unicode pour entrer et récupérer des données en japonais à condition qu'elle soit compatible avec l'une de ces deux options. De même, les utilisateurs américains peuvent saisir et extraire des données en anglais. Toutes les données des deux ensembles d'utilisateurs demeurent intactes et sont stockées dans la même colonne de la base de données, et elles sont représentées comme des données Unicode. Dans pareille situation, il est possible de déployer une application Unicode qui génère des rapports couvrant l'ensemble du dataset. Cependant, les utilisateurs anglais ne verront pas les lignes en japonais, car l'application n'est pas en mesure d'afficher les caractères n'existant pas dans leur page de codes (1252).
Un tel scénario peut être acceptable s'il n'est pas nécessaire que les deux groupes d'utilisateurs consultent mutuellement leurs enregistrements. Si un utilisateur doit pouvoir afficher ou modifier des enregistrements comportant du texte qui ne peut être représenté par une page de codes donnée, la seule option consiste à modifier l'application pour qu'elle prenne en charge Unicode.
Applications Web
Si le programme client est une application Web ou s'il se connecte à une page ASP (Active Server Pages), des spécifications de métadonnées s'appliquent tant à la page HTML côté client qu'à la page ASP côté serveur. Ces spécifications sont nécessaires pour indiquer la manière dont les chaînes de caractères doivent être converties entre le serveur, le moteur ASP et le navigateur client.
Dans la page HTML côté client, l'attribut META doit spécifier que le dataset de caractères doit être converti vers le modèle d'encodage du client au moyen d'un code CHARSET. Par exemple, la page HTML suivante indique au client de convertir les données de caractères vers la page de codes 950 (Chinois traditionnel) en spécifiant big5 en tant que code CHARSET.
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=big5">
<!--
-->
</HEAD>
<BODY>
<!--
body
-->
</BODY>
</HTML>
Dans la page ASP côté serveur, vous devez indiquer à l'application Web ASP la page de codes utilisée par le navigateur client. Vous pouvez définir la propriété Session.CodePage ou la directive @CodePage. Ces méthodes gèrent la conversion de données du serveur au client ainsi que les demandes client GET et POST. Dans les exemples suivants, les deux méthodes sont utilisées pour indiquer la conversion dans les deux directions pour la page de codes du client, qui est 950 (Chinois traditionnel).
<%@ Language=VBScript codepage=950 %>
<% Session.CodePage=950 %>
Enfin, n'oubliez pas de faire précéder tous les littéraux de chaîne par la lettre N.