Windows-1252

Windows-1252 ou CP-1252 ( page de codes Windows 1252) est un codage de caractères sur un octet hérité qui est utilisé par défaut (comme « page de codes ANSI ») dans Microsoft Windows dans les Amériques , en Europe occidentale , en Océanie et dans une grande partie de l'Afrique .

Initialement identique à la norme ISO 8859-1 , elle a commencé à diverger à partir de Windows 2.0 en ajoutant des caractères supplémentaires dans la plage 0x80 à 0x9F ( hex ) (les normes ISO réservent cette plage aux codes de contrôle C1 ). Parmi les caractères supplémentaires notables, citons les guillemets bouclés et tous les caractères imprimables de la norme ISO 8859-15 .

Français Il s'agit du codage de caractères mono-octet le plus utilisé au monde. Bien que presque tous les sites Web utilisent désormais le codage de caractères multi-octets UTF-8 , en décembre 2024, 1,1 % des sites Web ont déclaré ISO 8859-1 qui est traité comme Windows-1252 par tous les navigateurs modernes (comme l'exige la norme HTML5 ), plus 0,3 % ont déclaré directement Windows-1252, pour un total de 1,4 %. Certains pays ou langues affichent une utilisation plus élevée que la moyenne mondiale, en 2024 au Brésil selon l'utilisation des sites Web, l'utilisation est de 2,9 %, et en Allemagne de 2,5 % (il s'agit des sommes des déclarations ISO-8859-1 et CP-1252).

Il est connu de Windows sous le numéro de page de codes 1252 et sous le nom approuvé par l' IANA « windows-1252 ».

Historiquement, l'expression « page de codes ANSI » était utilisée dans Windows pour désigner les codages non DOS ; l'intention était que la plupart d'entre eux soient des normes ANSI telles que ISO-8859-1 . Même si Windows-1252 a été la première et de loin la plus populaire page de codes nommée ainsi dans le jargon Microsoft Windows, la page de codes n'a jamais été une norme ANSI. Microsoft explique : « Le terme ANSI utilisé pour désigner les pages de codes Windows est une référence historique, mais il s'agit aujourd'hui d'une appellation erronée qui persiste dans la communauté Windows. »

LaTeX peut saisir Windows-1252 en utilisant inputenc.sty avec le paramètre ansinew (et plus récemment cp1252 ).

IBM utilise la page de codes 1252 ( CCSID 1252 et CCSID étendu avec le signe euro 5348) pour Windows-1252.

Il est appelé « WE8MSWIN1252 » par Oracle Database .

• La première version de la page de codes a été utilisée dans Microsoft Windows 1.0 . Elle correspondait à la norme ISO-8859-1 (y compris les points de code 0xD7 et 0xF7 non définis, car ils n'étaient pas dans la norme à l'époque).
• La deuxième version de la page de codes a été introduite dans Microsoft Windows 2.0 . Dans cette version, les points de code 0xD7, 0xF7, 0x91 et 0x92 sont définis.
• La troisième version de la page de code a été introduite dans Microsoft Windows 3.1 . Elle définissait tous les points de code utilisés dans la version finale, à l'exception du signe euro et de la paire de caractères Z et caron .
• La version finale (présentée ci-dessous) a été introduite dans Microsoft Windows 98 .

À partir des années 1990, de nombreux produits Microsoft capables de produire du HTML incluaient des caractères exclusifs à Windows-1252, mais marquaient le codage comme ISO-8859-1, ASCII ou non déclaré. Les caractères exclusifs à Windows-1252 s'affichaient de manière incorrecte sur les systèmes d'exploitation non Windows (souvent sous forme de points d'interrogation). En particulier, les guillemets typographiques (variantes bouclées des apostrophes droites standard et des guillemets en US-ASCII) étaient couramment utilisés dans les fichiers produits dans les applications Windows telles que Microsoft Word en raison de la fonction de guillemets intelligents , qui peut convertir automatiquement les apostrophes droites et les guillemets en variantes bouclées. Pour résoudre ce problème, en 2000, la plupart des navigateurs Web et des clients de messagerie électronique traitaient les jeux de caractères ISO-8859-1 et US-ASCII comme Windows-1252 — ce comportement est désormais requis par la spécification HTML5. Les jeux de caractères non déclarés dans HTML sont également supposés être Windows-1252.

Bien que Windows NT prenne en charge Unicode et tente d'encourager les programmes à l'utiliser, il ne fournit que les unités de code 16 bits UCS-2 / UTF-16 , malgré la prise en charge existante d'autres codages de caractères multioctets. Comme de nombreuses applications préfèrent utiliser des chaînes de 8 bits, Windows-1252 est resté le codage le plus populaire sur Windows même après avoir ajouté la prise en charge de l'UTF-16. La prise en charge d'Unicode dans Windows s'est améliorée au fil du temps, la prise en charge de l'UTF-8 étant disponible à partir de Windows 10 .

Le tableau suivant présente Windows-1252. Les différences par rapport à la norme ISO-8859-1 ont le numéro de point de code Unicode sous le caractère, basé sur le mappage Unicode.org de Windows-1252 avec « best fit ». Une info-bulle, généralement disponible uniquement lorsque l'on pointe vers la droite immédiate du caractère, affiche le nom du point de code Unicode et le code Alt décimal .

D'après les informations figurant sur les sites Web de Microsoft et du Consortium Unicode, les positions 81, 8D, 8F, 90 et 9D ne sont pas utilisées. Cependant, l'API Windows MultiByteToWideCharles associe aux codes de contrôle C1 correspondants . Le mappage « le mieux adapté » documente également ce comportement.

Le système d'exploitation OS/2 prend en charge un codage appelé Page de codes 1004 ( CCSID 1004) ou « Windows Extended ». Cela correspond principalement à la page de codes 1252, à l'exception de certains caractères de contrôle C0 remplacés par des caractères diacritiques .

Il existe une page de codes étendue graphique 1252 rarement utilisée, mais utile, où les codes 0x00 à 0x1f permettent de dessiner des boîtes comme dans des applications telles que MSDOS Edit et Codeview. L'une des applications qui utilisaient cette page de codes était un utilitaire d'image de disque d'installation/récupération d'Intel Corporation datant de mi/fin 1995. Ces programmes ont été écrits pour ses machines P6 User Test Program (exemple américain ). Il était utilisé exclusivement dans sa région EMEA (Europe, Moyen-Orient et Afrique). Au fil du temps, les programmes ont été modifiés pour utiliser la page de codes 850 .

Chaque appareil Palm OS prend en charge une seule langue et un seul codage de caractères, en fonction de ses paramètres régionaux.

Pour les langues telles que l'anglais et le français, Palm OS utilise un codage de caractères personnalisé basé sur Windows-1252. Pour le japonais, il utilise à la place un codage de caractères multi-octets basé sur la page de codes 932. Quel que soit le paramètre régional du système, tous les caractères compris entre 0x00 et 0x7F sont garantis identiques, à l'exception de 0x5D qui est le signe Yen en japonais et une barre oblique inverse sur tous les autres.

Palm OS 3.1 a introduit plusieurs modifications dans le codage des caractères pour mieux s'aligner sur Windows-1252 :

• Les glyphes spéciaux Palm OS « raccourci » (0x9D) et « commande » (0x9E) ont été copiés vers 0x16 et 0x17, pour garantir qu'ils se trouvent dans la plage garantie d'être cohérente entre les paramètres régionaux. À partir de Palm OS 3.3, 0x16 et 0x17 sont les seuls points de code pour ces caractères, laissant 0x9D et 0x9E indéfinis.
• L' espace numérique (0x80) et les points de suspension horizontaux (0x85) ont été copiés vers 0x19 et 0x18 (respectivement), afin de garantir qu'ils se trouvaient dans la plage garantie d'être cohérente entre les paramètres régionaux.
• Le signe Euro a été ajouté à 0x80, remplaçant ce qui était auparavant l'espace numérique.
• Les couleurs des cartes à jouer ont été copiées dans la police Symbol 9, bien que leurs points de code d'origine restent valables.

Ce qui suit est la variante de Windows-1252 utilisée par Palm OS 3.3 et les versions ultérieures pour l'anglais et plusieurs autres paramètres régionaux. Python lui donne l' palmosétiquette, la décrivant comme l'encodage pour Palm OS 3.5. Les différences avec Windows-1252 ont leur point de code Unicode.