Pages de codes
La plupart des applications écrites aujourd’hui gèrent les données de caractères principalement en Unicode, à l’aide de l’encodage UTF-16. Toutefois, de nombreuses applications héritées continuent d’utiliser des jeux de caractères basés sur des pages de codes. Même les nouvelles applications doivent parfois fonctionner avec des pages de code, souvent pour l’une des raisons suivantes :
- Pour communiquer avec les applications héritées.
- Pour communiquer avec des serveurs de messagerie et d’actualités plus anciens, qui peuvent ne pas toujours prendre en charge Unicode.
- Pour communiquer avec la console Windows à des fins héritées. (La console prend en charge Unicode, mais certains outils d’application en ligne de commande hérités ne le peuvent pas.)
Notes
Les nouvelles applications Windows doivent utiliser Unicode pour éviter les incohérences des pages de codes variées et faciliter la localisation.
Chaque page de codes est représentée par un identificateur de page de codes, par exemple, 1252, et est gérée par les fonctions d’API Unicode et de jeu de caractères. Pour obtenir la liste des identificateurs de page de codes pris en charge, consultez Identificateurs de page de codes. La référence « Pages de code » dans le Centre de développement global Microsoft Go fournit une description complète de nombreuses pages de codes.
Les pages de codes Windows, communément appelées « pages de codes ANSI », sont des pages de codes pour lesquelles des valeurs non ASCII (valeurs supérieures à 127) représentent des caractères internationaux. Ces pages de codes sont utilisées en mode natif dans Windows Me et sont également disponibles sur Windows NT et versions ultérieures.
Notes
À l’origine, la page de codes Windows 1252, la page de codes couramment utilisée pour l’anglais et d’autres langues d’Europe occidentale, était basée sur un brouillon de l’American National Standards Institute (ANSI). Ce brouillon est finalement devenu ISO 8859-1, mais la page de codes Windows 1252 a été implémentée avant que la norme ne devienne définitive, et n’est pas exactement identique à iso 8859-1.
De nombreuses fonctions d’API Windows ont des versions « A » (ANSI) et « W » (large, Unicode). La version « A » gère le texte en fonction des pages de codes Windows, tandis que la version « W » gère le texte Unicode. Consultez Types de données Windows pour les chaînes et conventions pour les prototypes de fonction.
Les pages de codes Windows sont également parfois appelées « pages de codes actives » ou « pages de codes actives système ». Un système d’exploitation Windows a toujours une page de codes Windows active. Toutes les versions ANSI des fonctions d’API utilisent la page de codes actuellement active.
Les pages de codes OEM (Original Equipment Manufacturer) sont des pages de codes pour lesquelles les valeurs non-ASCII représentent des caractères de dessin et de ponctuation. Ces pages de codes étaient initialement utilisées pour MS-DOS et sont toujours utilisées pour les applications console. Ils sont également utilisés pour les noms de fichiers non étendus dans les systèmes de fichiers FAT12, FAT16 et FAT32, comme décrit dans Jeux de caractères utilisés dans les noms de fichiers. La page de codes OEM habituelle pour l’anglais est la page de codes 437.
Pour les pages de codes Windows et les pages de codes OEM, les valeurs de code 0x00 via 0x7F correspondent au jeu de caractères ASCII 7 bits. Les valeurs de code 0x00 via 0x19 et 0x7F représentent toujours des caractères de contrôle standardisés et 0x20 par 0x7E représentent des caractères affichables standardisés. Les caractères représentés par les codes restants, 0x80 0xff, varient d’un jeu de caractères à l’autre. Chaque jeu de caractères comprend des caractères spéciaux différents, généralement personnalisés pour une langue ou un groupe de langues. La page de codes Windows 1252 et la page de codes OEM 437 sont généralement utilisées dans le États-Unis.
En plus des pages de codes Windows et OEM, vos applications peuvent utiliser des pages de codes non natives. Par exemple, les pages de codes EBCDIC et Macintosh.
Deux encodages Unicode (UTF-7 et UTF-8) sont implémentés en tant que pages de codes. Comme les autres pages de codes, chaque page est connue par un identificateur numérique et peut être gérée avec la plupart des mêmes fonctions d’API Unicode et de jeu de caractères.
Les pages de code peuvent être des pages de jeu de caractères codés sur un octet (SBCS) ou des pages de jeu de caractères codés sur deux octets (DBCS). Dans les pages SBCS, chaque octet encode directement un seul caractère, de sorte qu’il soit possible de représenter exactement 256 caractères distincts (y compris les caractères de contrôle, les lettres, les chiffres, la ponctuation, les symboles, etc.). Les pages de codes DBCS sont utilisées pour des langues telles que le japonais et le chinois. Dans une telle page de codes, certains caractères ont des encodages de deux octets avec certaines valeurs d’octet (toujours supérieures à 127) servant d'« octets principaux ». Au lieu d’encoder des caractères à part entière, les octets de prospect peuvent être mappés à un caractère uniquement conjointement avec un « octet de piste ».
Certains protocoles hérités nécessitent l’utilisation de pages de codes SBCS et DBCS. Chaque page de codes SBCS/DBCS prend en charge des caractères différents, mais aucune page de codes ne prend en charge la totalité des caractères fournis par Unicode. Chaque page de codes SBCS/DBCS prend en charge un sous-ensemble différent, encodé différemment.
Notes
Les données converties d’une page de codes SBCS ou DBCS en une autre sont susceptibles d’être endommagées, car la même valeur de données sur différentes pages de codes peut encoder un caractère différent. Les données converties d’Unicode en SBCS ou DBCS sont sujettes à une perte de données, car une page de codes donnée peut ne pas être en mesure de représenter tous les caractères utilisés dans ces données Unicode particulières.
En plus des pages de codes SBCS et DBCS, vos applications disposent des pages de codes de jeu de caractères multioctets 52936, 54936, 51949 et 5022x, qui utilisent une approche similaire à celle d’un DBCS. Toutefois, une page de codes de jeu de caractères multioctets va au-delà des encodages de deux octets de certains caractères. UTF-7 et UTF-8 utilisent une approche similaire pour encoder Unicode sur la base d’octets 7 bits et 8 bits, respectivement. Pour plus d’informations, consultez Unicode.
Plusieurs fonctions Unicode et de jeu de caractères permettent à vos applications de gérer des pages de code. Une application peut utiliser les fonctions GetCPInfo et GetCPInfoEx pour obtenir des informations sur une page de codes. Ces informations incluent le caractère par défaut utilisé lorsqu’un caractère d’une chaîne convertie n’a pas d’entrée correspondante dans la page de codes.
Une application peut utiliser les fonctions MultiByteToWideChar et WideCharToMultiByte pour convertir des chaînes basées sur des pages de codes Windows et des chaînes Unicode. Bien que leurs noms fassent référence à « MultiByte », ces fonctions fonctionnent également bien avec les pages de codes SBCS, DBCS et multioctets de jeu de caractères.
Notes
WideCharToMultiByte peut perdre certaines données si la page de codes fournie ne peut pas représenter tous les caractères d’une chaîne Unicode.
Votre application peut effectuer une conversion entre les pages de codes Windows et les pages de code OEM à l’aide des fonctions de bibliothèque de runtime C standard. Toutefois, l’utilisation de ces fonctions présente un risque de perte de données, car les caractères qui peuvent être représentés par chaque page de codes ne correspondent pas exactement.
Vos applications peuvent également appeler la fonction GetACP . Cette fonction récupère l’identificateur de la page de codes Windows (ANSI) actuelle.
Rubriques connexes