BlueTemplar Posté(e) le 3 mars 2018 Partager Posté(e) le 3 mars 2018 Ceci est en fait une page wiki GitLab interne à destination d'un groupe de travail, formatée en Markdown. (il y a t'il un moyen de le convertir automatiquement dans l'encodage du forum?) Je me suis dit que ces informations pourraient être intéressantes à d'autres personnes. (Par contre soyez indulgents s'il vous plaît, ce n'est que la version 0.2.) # TL;DR (*Too Long ; Didn't Read*) (Pré-Introduction) Imaginez le raisonnement suivant que vous pourriez vous faire : "Le [Zen de Python (PEP20)](https://openclassrooms.com/courses/manipulez-des-donnees-avec-python-1/devenez-zen-avec-la-pep-20) dit : 1.) Le beau est préférable au laid. 7.) La lisibilité compte. Les deux premières phrases (passé l'introduction) de [PEP 8 — the Style Guide for Python Code](https://pep8.org/), insistent sur la lisibilité du code, qui est lu beaucoup plus souvent qu'écrit." "Je bosse (par exemple) avec des unités du système international, où la lettre grecque mu : "µ" désigne les micro-mètres/litres/etc. " "Et depuis Python 3.x(?*TODO*), non seulement les fichiers .py sont en Unicode, et il gère les chaînes de caractères en Unicode par défaut, mais en plus les noms de variables peuvent être en toute sorte de caractères Unicode (en dehors de l'ASCII) !" "Alors je me dis : "Pourquoi ne pas directement mettre µ dans une variable, par exemple "size_µm" ? C'est quand même plus clair et beau que "size_um" et plus court que "size_micrometers" ! " "En plus ce symbole "µ" est directement sur mon clavier, à côté de la touche "Entrée", et est d'ailleurs bien plus accessible par SHIFT+* que les les "{[@]}" qui demandent Ctrl+Alt+ ou AltGr+ !" "Et je pourrais même copier-copier sur la Toile et dans LaTeX sans avoir besoin de passer par des balises!" ... Sauf que, en pratique ça ne se révèle pas DU TOUT aussi simple ! Pour comprendre pourquoi, suivez avec moi la folle (enfin, pas trop quand même...) histoire des encodages texte ! TODO: "mètre" : "éèà" encore mieux comme exemple que µ?) AZERTY? : SHIFT+*=µ (plus facile que les "{[@]}" qui démandent Ctrl+Alt+ ou AltGr+ !) Python 3 : unicode par défaut PEPXXX? & Python 3.x? : unicode identifiers # Introduction En apprenant que de Python2 à Python3, le format par défaut des fichiers .py (ce qui est potentiellement *différent* du **traitement** des *chaînes de caractères!*) est passé de ASCII à ~~Unicode~~ UTF-8, je me suis demandé quelles en étaient les implications... Notamment, ne serait-ce pas possible de directement écrire des symboles mathématiques et physiques dans les commentaires... #ε₀=1⁄μ₀c² F⋅m⁻¹ (1) Et pourquoi pas avoir directement des fonctions et des variables utilisant des symboles de maths et de physique? εₒ=1/(μₒ*c**2) (2) ou bien même (3) ```python import numpy as np def √(x): return np.sqrt(x) class float: def __init__(self, x = 0.0): self.x = x def __str__(self): return "({0})".format(self.x) def __square__(self): # __square__ étant un éventuel opérateur post-fixé écrit x² xx = self.x*self.x return float(xx) d = √(x² + y²) print(d) ``` (µ et ² sont d'ailleurs présents sur certains clavier "français") Et d'ailleurs, la (1) et la (2) marchent très bien dans Python 3.6 (au moins, 3.0 au plus) ! Je m'imaginais déjà pouvoir copier-coller ce genre de formules n'importe ou sur la Toile et dans TeX! Mais non seulement la (3) ne marche pas - parce que ² (et √?) iraient mieux comme opérateurs à part entière, et l'ajout d'opérateurs personnalisés dans Python, surtout post-fixés [n'est pas prévu au moins avant la version 4 ou 5](TODO:source), - mais en plus même les moteurs de TeX où Unicode est endémique, tels LuaTeX et XeTeX ont du mal à les afficher ! (est-ce une simple histoire de police par défaut n'ayant pas les glyphes requis, ou alors c'est dû à autre chose? (Windows?)) Un des problèmes essentiels est que l'histoire des encodages a été longue et tortueuse, et du coup, même quand Unicode essaye de s'imposer, on n'est en fait toujours pas tiré d'affaire ! # ~~Au commencement il fut l'ASCII !!~~ Après des décennies, l'informatique s'est standardisée sur l'ASCII : un encodage à 7 bits, rentrant dans un seul octet et pouvant donc prendre les valeurs : décimales : 0d : 0 à 127 binaires : 0b : _000 0000 à _111 1111 hexadécimales : 0x : 00 à 7F [Liste](http://www.madore.org/~david/computers/unicode/cstab.html) : ``` 0 1 2 3 4 5 6 7 8 9 a b c d e f 0x0 nul stx sot etx eot enq ack bel bs ht lf vt ff cr so si 0x1 dle dc1 dc2 dc3 dc4 nak syn etb can em sub esc fs gs rs us 0x2 sp ! " # $ % & ' ( ) * + , - . / 0x3 0 1 2 3 4 5 6 7 8 9 : ; < = > ? 0x4 @ A B C D E F G H I J K L M N O 0x5 P Q R S T U V W X Y Z [ \ ] ^ _ 0x6 ` a b c d e f g h i j k l m n o 0x7 p q r s t u v w x y z { | } ~ del 0 1 2 3 4 5 6 7 8 9 a b c d e f ``` *(TODO : explication des codes de contrôle 0x00 à 0x1F)* Le protocole de transfert de méls SMTP *(Simple Mail Transfer Protocol)* l'utilise toujours exclusivement *(ou presque? TODO : "SMTPUTF8")*. *(TODO : multiplets 7-bits (septiplets?), de SMTP, byte=multiplet, "word", base64, quoted-printable...)* C'était plutôt suffisant pour l'anglo-américain et d'autres caractères, [dont de contrôle](TODO), mais pas pour les autres langues comme le français, qui était quant même bien désemparé sans les caractères tel le "é" ou le "à" ! Les ordinateurs ayant tendance à travailler avec des octets [*TODO:pourquoi?*], et au fil des années le poids des données devenant de moins en moins cher, un bit a été rajouté, doublant le nombre de caractères pouvant être utilisés : décimales : 0d : 0 à 2555 binaires : 0b : 0000 0000 à 1111 1111 hexadécimales : 0h : 00 à FF Malheureusement (il s'est passé la même chose qu'avant la standardisation de l'ASCII?) [chacun a voulu y aller à sa sauce](http://www.iana.org/assignments/character-sets/character-sets.xhtml), et ce fut le bazar, "standardisé" sous les normes ISO-8859-dd voir la liste des encodages non-Unicode de caractères dans un navigateur ou dans les paramètres régionales de Windows. Nous intéressent particulièrement : ISO-8859-1 nommée de préférence latin1 : *(TODO?: différence entre ISO 8859-1 et ISO-8859-1 ?)* ``` 01 2 3 4 5 6 7 8 9 a b c d e f 0x8 pad hop bph nbh ind nel ssa esa hts htj vts pld plu ri ss2 ss3 0x9 dcs pu1 pu2 sts cch mw spa epa sos sgci sci csi st osc pm apc 0xa nbsp ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ shy ® ¯ 0xb ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿ 0xc À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï 0xd Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß 0xe à á â ã ä å æ ç è é ê ë ì í î ï 0xf ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ 0 1 2 3 4 5 6 7 8 9 a b c d e f ``` il y a eu aussi : ISO-8859-15 nommée de préférence latin9 : (une sorte de "mise à jour" de latin1 ) **(à ne pas confondre avec ISO-8859-9=latin5=turkish≠windows-1254 !)** ``` Position 0xA4 0xA6 0xA8 0xB4 0xB8 0xBC 0xBD 0xBE 8859-1 ¤ ¦ ¨ ´ ¸ ¼ ½ ¾ 8859-15 € Š š Ž ž Œ œ Ÿ ``` Mais c'est windows-1252 (finalisé pour Windows 98) qui a fini par s'imposer , aussi surnommé "ANSI" *("ansinew" dans LaTeX ?)* : (remplaçant les codes de contrôle 0h80-0h9f finalement peu utilisés par d'autres caractères qui semblaient plus "utiles", et ayant donc tous ceux de latin1 ET de latin9) ``` 0 1 2 3 4 5 6 7 8 9 a b c d e f 0x8 € XX ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ XX Ž XX 0x9 XX ‘ ’ “ ” • – — ˜ ™ š › œ XX ž Ÿ 0 1 2 3 4 5 6 7 8 9 a b c d e f ``` *(TODO:conversion windows-1252/latin9?) 81, 8D, 8F, 90, et 9D sont soit **non affectés**, soit sont considères comme codes de contrôle de latin1 : respectivement hop, ri, ss3, dcs et st *(TODO : qu'est ce qu'ils font?)* *(TODO : attention aux erreurs possibles dans un cas ou dans l'autre?)* windows-1252 est souvent appelé par abus, [voire "standardisé" comme par exemple dans HTML5, en tant que "ISO-8859-1"(=latin1), (voire même en tant que "ascii"!)](https://encoding.spec.whatwg.org/#names-and-labels), probablement parce que les logiciels modernes (surtout les navigateurs? qu'en est-il des terminaux *nix?) auront tendance à automatiquement interpréter les codes de contrôle 0h80-0h9f de ISO-8859-1=latin1 comme les caractères de windows-1252. *(TODO : exceptions à cette règle?)* *(TODO?: windows code pages, DOS=OEM=IBM code page)* *(TODO : W3C et WHATWG)* Évidemment, le problème se pose quand un texte encodé comme latin9 est lu comme du windows-1252 ou du latin1, par exemple : "1œuf = 1€" en latin9 est encodé en la séquence d'octets : 0x : 31 BD 75 66 20 3D 20 31 A4 cette même séquence d'octets donne : en latin1 : "1½uf = 1¤" * (¤ symbole monétaire, TODO? : remplacements ¤<=>$<=>£<=>€ ?)* en windows-1252 : "1¼uf = 1¢" Dans les deux cas, 0xBD et 0xA4 posent problème. *(TODO : J'obtiens "1�uf = 1�" en windows-1252 sur https://dencode.com/en/string/hex ??)* *NB : Il y aurait eu un problème similaire à latin1/latin9 avant la standardisation de l'ascii?* # **TODO : Chapitres Unicode, YAML, (Lua/Xe)(La)Tex** Lien vers le commentaire Partager sur d’autres sites More sharing options...
foetus Posté(e) le 3 mars 2018 Partager Posté(e) le 3 mars 2018 Pour précisions : Cela s'appelle MBCS (Multi Byte Character Set) qui sont des "code pages" qui permettent de remplir les 127 valeurs vacantes de l'ASCII. Mais pas seulement, c'est un encodage soit sur 1 octet soit sur 2 octets comme le Shift-JIS ANSI c'est un terme Microsoft pour définir le "code page" par défaut de son Windows. En France, ANSI c'est le latin-9. Au Japon, ANSI c'est sûrement le Shift-JIS. Et pour l'anecdote, cette connerie de ligne de commandes Microsoft, utilise / utilisait par défaut un code page OEM. C'est pour cette raison que si son programme sort de l'Unicode il faut changer par 65001 (UTF-8) ou 1200/ 1201 (UTF-16) (Et il existe aussi l'UTF-32 avec 12000/ 12001) Et il faut parler du BOM "Byte Order Marker" (<- lien Wiki anglais) ... ce mal-aimé que Linux chie dessus Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.