Quelle est la différence exacte entre Windows-1252 (1/3/4) et ISO-8859-1?
Nous hébergeons PHP applications sur une installation LAMP basée sur Debian. Tout est tout à fait correct - performances, administration et gestion. Cependant, étant un développeur quelque peu nouveau (nous sommes toujours au lycée), nous 'ai rencontré quelques problèmes avec le codage des caractères pour les jeux de caractères occidentaux.
Après avoir fait beaucoup de recherches, je suis arrivé à la conclusion que les informations en ligne sont quelque peu déroutantes. Il s'agit de Windows-1252 étant ANSI et totalement compatible ISO-8859-1.
Quoi qu'il en soit, quelle est la différence entre Windows-1252 (1/3/4) et ISO-8859-1? Et où ANSI intervient-il de toute façon?
Quel encodage devrions-nous utiliser sur nos serveurs (et stations de travail) Debian afin de garantir que les clients obtiennent toutes les informations de la manière voulue et que nous ne perdons aucun caractère en cours de route?
Je voudrais répondre à cela d'une manière plus semblable à celle du Web et afin d'y répondre, nous avons donc besoin d'un peu d'histoire. Joel Spolsky a écrit un très bon article d'introduction sur le minimum absolu que chaque développeur devrait connaître sur le codage de caractères Unicode. Soyez indulgent avec moi car cela va être en quelque sorte une réponse looong. :)
Comme histoire, je vais pointer quelques citations à partir de là: (Merci beaucoup Joel! :))
Les seuls caractères qui importaient étaient de bonnes vieilles lettres anglaises non accentuées, et nous avions un code pour eux appelé ASCII qui était capable de représenter chaque caractère en utilisant un nombre compris entre 32 et 127. L'espace était de 32, le la lettre "A" était de 65, etc. Cela pouvait être stocké en 7 bits. La plupart des ordinateurs à cette époque utilisaient des octets de 8 bits, donc non seulement vous pouviez stocker tous les caractères ASCII, mais vous aviez beaucoup à épargner, que, si vous étiez méchant, vous pouviez l'utiliser à vos propres fins détournées.
Et tout allait bien, en supposant que vous étiez anglophone. Parce que les octets peuvent contenir jusqu'à huit bits, beaucoup de gens ont pensé: "ça alors, nous pouvons utiliser les codes 128-255 à nos propres fins". Le problème était que beaucoup de gens avaient cette idée en même temps, et ils avaient leurs propres idées de ce qui devrait aller où dans l'espace de 128 à 255.
Alors maintenant, les "jeux de caractères OEM" étaient distribués avec les PC et ils étaient toujours tous différents et incompatibles. Et à notre étonnement contemporain - tout allait bien! Ils n'avaient pas accès à Internet et les gens échangeaient rarement des fichiers entre des systèmes avec des paramètres régionaux différents.
Joel continue en disant:
En fait, dès que les gens ont commencé à acheter des PC en dehors de l'Amérique, toutes sortes de jeux de caractères OEM différents ont été imaginés, qui utilisaient tous les 128 premiers caractères à leurs propres fins. Finalement, cet OEM gratuit a été codifié dans la norme ANSI. Dans la norme ANSI, tout le monde était d'accord sur ce qu'il fallait faire en dessous de 128, ce qui était à peu près la même chose qu'en ASCII, mais il y avait beaucoup de façons différentes de gérer les caractères à partir de 128 et plus, selon l'endroit où vous habitiez. Ces différents systèmes ont été appelés pages de codes .
Et c'est ainsi que les "pages de code Windows" sont nées, finalement. Ils étaient en fait "parentés" par les pages de codes DOS. Et puis Unicode est né! :) et TF-8 est "un autre système pour stocker votre chaîne de points de code Unicode" et en fait "chaque point de code de 0-127 est stocké dans un seul octet" et est le même que - ASCII . Je n'entrerai pas dans plus de détails sur Unicode et UTF-8, mais vous devriez lire sur le BOM , Endianness et - Encodage des caractères en général.
Sur "la conspiration ANSI", Microsoft admet en fait le mauvais étiquetage de Windows-1252 dans un glossaire des termes :
Le soi-disant jeu de caractères Windows (WinLatin1, ou la page de codes Windows 1252, pour être exact) utilise certaines de ces positions pour les caractères imprimables. Ainsi, le jeu de caractères Windows n'est PAS identique à ISO 8859-1. Le jeu de caractères Windows est souvent appelé "jeu de caractères ANSI", mais il est GRAVEMENT TROMPEUR. Il n'a PAS été approuvé par l'ANSI.
Ainsi, ANSI lors de la référence aux jeux de caractères Windows n'est pas certifié ANSI ! :)
Comme l'a souligné Jukka (les crédits vous reviennent pour la bonne réponse)
Windows-1252 ISO Latin 1, également connu sous le nom de codage de caractères ISO-8859-1, de sorte que la plage de codes 0x80 à 0x9F est réservée aux caractères de contrôle dans ISO-8859-1 (appelés contrôles C1), tandis que dans Windows -1252, certains codes y sont attribués à des caractères imprimables (principalement des caractères de ponctuation), d'autres ne sont pas définis.
Cependant, mon opinion personnelle et ma compréhension technique est que Windows-1252 et ISO-8859-1 NE SONT PAS DES CODAGES WEB ! :) Donc:
Pour les pages Web, veuillez utiliser UTF-8 comme encodage pour le contenu. Stockez donc les données au format UTF-8 et "crachez-les" avec en-tête HTTP :
Content-Type: text/html; charset=utf-8.Il y a aussi une chose appelée méta-balise de type de contenu HTML:
<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8">Maintenant, ce que les navigateurs font réellement lorsqu'ils rencontrent cette balise, c'est qu'ils recommencent depuis le début du document HTML afin de pouvoir réinterpréter le document dans l'encodage déclaré. Cela ne devrait se produire que s'il n'y a pas d'en-tête "Content-type".Utilisez d'autres encodages spécifiques si les utilisateurs de votre système ont besoin de fichiers générés à partir de celui-ci. Par exemple, certains utilisateurs occidentaux peuvent avoir besoin de fichiers générés par Excel ou CSV dans Windows-1252. Si tel est le cas, encodez le texte dans cet environnement local, puis stockez-le sur le fs et servez-le en tant que fichier téléchargeable.
Il y a une autre chose à savoir dans la conception de HTTP : Le mécanisme de distribution de codage de contenu devrait fonctionner comme ceci.
I. Le client demande une page Web dans un type de contenu et des encodages spécifiques via: le 'Accept' et le 'Accept-Charset' en-têtes de requête .
II. Ensuite, le serveur (ou l'application Web) renvoie le contenu transcodé à cet encodage et à ce jeu de caractères.
Ce n'est pas le cas dans la plupart des applications Web modernes. Que se passe-t-il réellement si les applications Web servent (forcent le client) du contenu en UTF-8. Et cela fonctionne parce que les navigateurs interprètent les documents reçus en fonction des en-têtes de réponse et non de ce qu'ils attendaient réellement.
Nous devrions tous passer en Unicode, alors s'il vous plaît, s'il vous plaît, veuillez utiliser UTF-8 pour distribuer votre contenu chaque fois que cela est possible et surtout applicable. Ou bien les anciens d'Internet vous hantera! :)
P.S. D'autres articles intéressants sur l'utilisation des caractères MS Windows dans les pages Web peuvent être trouvés ici et ici .
La référence la plus fiable à la signification des noms de codage de caractères est le registre IANA Jeux de caractères .
Windows-1252 est communément appelé Windows Latin 1 ou Windows West European ou quelque chose comme ça. Il diffère de ISO Latin 1, également connu sous le nom de codage de caractères ISO-8859-1, de sorte que la plage de codes 0x80 à 0x9F est réservée aux caractères de contrôle dans ISO-8859-1 (appelés contrôles C1), tandis que dans Windows -1252, certains codes y sont attribués à des caractères imprimables (principalement des caractères de ponctuation), d'autres ne sont pas définis.
ANSI vient ici comme un terme impropre. Microsoft a déjà soumis Windows-1252 à l'American National Standards Institute (ANSI) pour adoption en tant que norme; la proposition a été rejetée, mais Microsoft appelle toujours leur code "ANSI". Pour plus de confusion, ils peuvent utiliser "ANSI" pour différents encodages (en gros, "l'encodage 8 bits natif" d'une installation Windows).
Dans le contexte Web, déclarer ISO-8859-1 sera considéré comme si vous aviez déclaré Windows-1252. La raison en est que les contrôles C1 ne sont pas utilisés ou utiles sur le Web, alors que les caractères ajoutés sont souvent utilisés, même sur des pages mal étiquetées ISO-8859-1. Donc, en pratique, peu importe celui que vous déclarez.
Certains navigateurs peuvent encore interpréter les données comme ISO-8859-1 s'ils le déclarent, mais ils doivent être très rares (le dernier dont je me souvienne avoir vu était une version de Opera il y a environ dix ans) ).
Vous ne décrivez pas les problèmes que vous avez rencontrés. La cause la plus courante des problèmes semble être que les données sont en fait encodées en UTF-8 mais déclarées ISO-8859-1 (ou Windows-1252), ou vice versa. Cela devient un vrai problème pour les auteurs de pages Web si un serveur force un Content-Type en-tête déclarant un codage de caractères et celui-ci ne peut pas être traité dans leur environnement de création (ou ne sait pas comment faire).
ANSI (Windows-1252) dans les pays avec un alphabet anglais/latin, par ex. Royaume-Uni/États-Unis/France/Allemagne et autres, fait référence à l'encodage Windows-1252. https://web.archive.org/web/20170916200715/http://www.Microsoft.com:80/resources/msdn/goglobal/default.mspx
Windows-1252. et ISO-8859-1 sont très similaires. Ils ne diffèrent que par 32 caractères.
Dans Windows-1252, les caractères de 128 à 159 sont utilisés pour certains caractères utiles tels que le symbole de l'euro.
Dans ISO-8859-1, ces caractères sont mappés pour contrôler des caractères inutiles en HTML.
__ donc une suggestion alors voyez si 128 est le symbole de l'euro .. si c'est c'est Windows 1252. __
Les codes de 128 à 159 ne sont pas utilisés dans ISO-8859-1, mais de nombreux navigateurs affichent les caractères du jeu de caractères Windows-1252) au lieu de rien.
Ces 2 liens les listent tous les deux.
http://www.w3schools.com/charsets/ref_html_ansi.asp
http://www.w3schools.com/charsets/ref_html_8859.asp
Certains commentaires ont été très utiles et j'ai modifié mon message en conséquence en fonction d'eux.
Chenfeng fait remarquer que sous Windows, "ANSI" fait référence à la page de codes système spécifiée par les paramètres régionaux, quels qu'ils soient (arabe/chinois/cyrillique/vietnamien/...). Il ne fait pas [nécessairement] référence à Windows-1252. Vous pouvez tester cela en modifiant vos paramètres régionaux, puis utilisez notepad.exe pour enregistrer un fichier texte dans "ANSI". Selon cette documentation MS, il existe 14 pages de codes "ANSI" différentes https://docs.Microsoft.com/en-us/windows/desktop/intl/code-page-identifiers
Wernfriend souligne https://web.archive.org/web/20170916200715/http://www.Microsoft.com:80/resources/msdn/goglobal/default.mspx et cette page de codes des États-Unis 437 est la "page de codes OEM" (voir la colonne OEM) et la page de codes OEM est celle utilisée par l'invite cmd. Et il souligne/suggère, montrant à partir de cette page Web, que dans de nombreux pays qui ne parlent pas l'alphabet latin/latin, ansi n'est pas Windows 1252. Je remarque que, par exemple, l'hébreu ansi utilise 1255. (la page de code hébreu OEM est 862).
Ce tableau donne un aperçu des différences. Il affiche tous les caractères définis dans Windows-1252 mais non disponibles dans ISO-8859-1/ISO-8859-15:
│ …0 │ …1 │ …2 │ …3 │ …4 │ …5 │ …6 │ …7 │ …8 │ …9 │ …A │ …B │ …C │ …D │ …E │ …F │
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
8… │ € │ │ ‚ │ ƒ │ „ │ … │ † │ ‡ │ ˆ │ ‰ │ Š │ ‹ │ Œ │ │ Ž │ │
Unicode │ 20AC │ │ 201A │ 0192 │ 201E │ 2026 │ 2020 │ 2021 │ 02C6 │ 2030 │ 0160 │ 2039 │ 0152 │ │ 017D │ │
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
9… │ │ ‘ │ ’ │ “ │ ” │ • │ – │ — │ ˜ │ ™ │ š │ › │ œ │ │ ž │ Ÿ │
Unicode │ │ 2018 │ 2019 │ 201C │ 201D │ 2022 │ 2013 │ 2014 │ 02DC │ 2122 │ 0161 │ 203A │ 0153 │ │ 017E │ 0178 │
Contrairement à la plage Windows-1252, 0x80… 0x9F est utilisé pour Codes de contrôle dans ISO-8859-1.
Ce tableau montre les différences entre Windows-1252, ISO-8859-1 et ISO-8859-15
Character │ € │ Š │ š │ Ž │ ž │ Œ │ œ │ Ÿ │ ¤ │ ¦ │ ¨ │ ´ │ ¸ │ ¼ │ ½ │ ¾ │
───────────────────────────────────────────────────────────────────────────────────────────────────────
ISO 8859-1 │ – │ – │ – │ – │ – │ – │ – │ – │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │
ISO 8859-15 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │ – │ – │ – │ – │ – │ – │ – │ – │
Windows-1252 │ 80 │ 8A │ 9A │ 8E │ 9E │ 8C │ 9C │ 9F │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │
Unicode │ 20AC │ 160 │ 161 │ 17D │ 17E │ 152 │ 153 │ 178 │ A4 │ A6 │ A8 │ B4 │ B8 │ BC │ BD │ BE │