Partager via

Pages de codes

  • Article

La plupart des applications écrites aujourd’hui gèrent principalement les données de caractères comme 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 code. 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 peuvent ne pas le faire.)

Note

Les nouvelles applications Windows doivent utiliser Unicode pour éviter les incohérences des pages de code variées et pour 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 » sur le Centre de développement Microsoft Go Global Developer Center fournit des descriptions complètes 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 les 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.

Note

À l’origine, la page de codes Windows 1252, la page de codes couramment utilisée pour l’anglais et d’autres langues européennes occidentales, était basée sur un projet d’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 la finale de la norme, et n’est pas exactement la même que 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 basé sur les 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 les conventions de 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 possède toujours une page de codes Windows active. Toutes les versions ANSI des fonctions API utiliser la page de codes actuellement active.

Les pages de codes fabricant d’équipement d’origine (OEM) sont des pages de codes pour lesquelles les valeurs non ASCII représentent des caractères de dessin de trait et de ponctuation. Ces pages de codes ont été utilisées à l’origine 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 par 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 par 0xff, varient entre les jeux de caractères. Chaque jeu de caractères comprend différents caractères spéciaux, 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 aux États-Unis.

En plus des pages de codes Windows et OEM, vos applications peuvent utiliser des pages de code non natives. Voici des exemples de pages de codes EBCDIC et Macintosh.

Deux encodages d’Unicode (UTF-7 et UTF-8) sont implémentés en tant que pages de code. Comme d’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 à octet unique (SBCS) ou des pages de jeu de caractères à deux octets (DBCS). Dans les pages SBCS, chaque octet encode directement un caractère unique, afin 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 et les valeurs similaires). Les pages de codes DBCS sont utilisées pour les langues telles que le japonais et le chinois. Dans une telle page de codes, certains caractères ont des encodages à deux octets avec certaines valeurs d’octets (toujours des valeurs supérieures à 127) servant de « octets de prospect ». Au lieu d’encoder des caractères dans leur propre droit, les octets de prospect peuvent être mappés à un caractère uniquement conjointement avec un « octet de fin ».

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 différents caractères, mais aucune page de codes ne prend en charge l’étendue complète des caractères fournis par Unicode. Chaque page de codes SBCS/DBCS prend en charge un sous-ensemble différent, différemment encodé.

Note

Les données converties d’une page de codes SBCS ou DBCS vers une autre sont sujettes à une altération, 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 soumises à une perte de données, car une page de codes donnée peut ne pas être en mesure de représenter chaque caractère utilisé dans ces données Unicode particulières.

 

En plus des pages de codes SBCS et DBCS, vos applications ont disponible les 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 dépasse les encodages à deux octets de certains caractères. UTF-7 et UTF-8 utilisent une approche similaire pour encoder Unicode en fonction d’un octet 7 bits et 8 bits, respectivement. Pour plus d’informations, consultez Unicode .

Plusieurs fonctions Unicode et jeu de caractères permettent à vos applications de gérer les 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 aucune entrée correspondante dans la page de codes.

Une application peut utiliser les fonctions MultiByteToWideChar et WideCharToMultiByte pour effectuer une conversion entre des chaînes basées sur des pages de codes Windows et des chaînes Unicode. Bien que leurs noms font référence à « MultiByte », ces fonctions fonctionnent également bien avec les pages de codes de jeu de caractères SBCS, DBCS et multioctets.

Note

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 codes 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.

jeux de caractères